Omówienie natywnego procesu płatności

Aby umożliwić użytkownikom dokonanie zakupu, musisz wdrożyć integrację natywnego procesu płatności. Wymaga to utworzenia standardowego interfejsu REST API, który umożliwi Google zautomatyzowane zarządzanie procesem płatności za pomocą Twoich serwerów. Ta metoda zapewnia użytkownikom największą wygodę. Początkowo Google będzie renderować interfejs kupującego, ale w przyszłości planujemy obsługę bardziej aktywnych interakcji.

Proces płatności

Integracja natywna wymaga utworzenia interfejsu API REST, który Google może wywoływać w celu tworzenia sesji płatności i zarządzania nimi.

Ogólny proces wygląda tak:

  1. Budowanie sesji płatności: użytkownik i opcjonalnie agent są w pętli dodawania elementów do sesji.
  2. Przekazanie do interfejsu Google: gdy użytkownik zdecyduje się na płatność, agent (jeśli jest zaangażowany) przekazuje kontrolę do interfejsu Google (przekazując dane sesji płatności).
  3. Ręczne płatności: użytkownik wchodzi w interakcję tylko z interfejsem Google, aby podać poufne dane dotyczące realizacji zamówienia i płatności oraz przesłać zamówienie. Agent nie jest zaangażowany w tę część, co zapewnia determinizm.
  4. Zakończenie i zwrot: w interfejsie Google wyświetla się strona z podziękowaniem, która potwierdza zamówienie. Opcjonalnie użytkownik może zostać przekierowany z powrotem do agenta, który mógł już otrzymać powiadomienie o zakończonym zakupie.

Cykl życia stanu sesji płatności

W miarę przechodzenia użytkownika przez proces płatności musisz aktualizować sesję płatności status, aby odzwierciedlała jej bieżący stan. Sesja przechodzi przez następujący cykl życia:

  • incomplete: początkowy stan sesji po jej utworzeniu. Oznacza to, że brakuje obowiązkowych informacji (takich jak metody dostawy, podatki lub dane użytkownika) albo nie zostały one obliczone.
  • ready_for_payment: stan, który należy zastosować po tym, jak użytkownik zaktualizuje adres dostawy, a Ty obliczysz opcje dostawy i sumy, ale przed sfinalizowaniem instrumentu płatniczego.
  • ready_for_complete: stan, który ma być używany podczas wypełniania obiektu pełnej płatności, gdy instrument płatniczy zostanie wybrany, a wszystkie szczegóły zamówienia zostaną zweryfikowane.
  • completed: ostateczny stan zwracany po pomyślnym przetworzeniu płatności i złożeniu zamówienia.
  • canceled: stan zwracany, jeśli sesja płatności została przerwana.
  • error: stan zwracany, gdy nieodwracalny błąd logiki biznesowej uniemożliwia płatność. Ten stan jest dostępny w UCP w wersji 2026-04-08 i nowszych.

Proces płatności za wiele produktów:

Google obsługuje teraz wiele różnych elementów zamówienia w ramach jednej sesji płatności. Ogólny proces wygląda tak:

  1. Użytkownik rozpoczyna proces płatności w interfejsie obsługującym UCP (np. klikając „Kup teraz” przy produkcie).
  2. Wywoływane jest połączenie POST /checkout-sessions, które obejmuje wszystkie odrębne elementy w tablicy line_items. Tablica line_items będzie zawierać osobny obiekt dla każdego unikalnego produktu, który jest kupowany.
  3. Użytkownik może zaktualizować instrument płatniczy, szczegóły realizacji lub zastosować rabaty za pomocą wywołań PUT /checkout-sessions/{id}.
  4. Gdy użytkownik kliknie przycisk „Zapłać za pomocą GPay”, nastąpi wywołanie funkcji POST /checkout-sessions/{id}/complete.

Uwierzytelnianie

Szczegółowe informacje o zabezpieczaniu punktów końcowych interfejsu Native Checkout API, w tym obsługiwanych metodach uwierzytelniania, takich jak klucze interfejsu API i OAuth 2.0, znajdziesz w przewodniku Uwierzytelnianie i bezpieczeństwo.

Narzędzia dla programistów

Aby ułatwić Ci wdrożenie interfejsu Native Checkout API, w repozytorium Universal Commerce Protocol w GitHubie znajdziesz te materiały:

  • Repozytorium GitHub UCP: zapoznaj się z głównym repozytorium, w którym znajdziesz kompleksową dokumentację, specyfikacje i zasoby społeczności.
  • Pakiety SDK: używaj pakietów SDK, aby przyspieszyć integrację. Dostępne są pakiety SDK dla poszczególnych języków, w tym:

  • Testy zgodności: sprawdzanie punktów końcowych interfejsu API pod kątem specyfikacji UCP za pomocą zestawu testów zgodności.

    Dzięki temu Twoja implementacja będzie spełniać wymagane standardy i zachowania.

Zdecydowanie zalecamy korzystanie z tych narzędzi, aby usprawnić proces tworzenia i testowania.

Docelowe poziomy usług

Do punktów końcowych interfejsu Native Checkout REST API mają zastosowanie te docelowe poziomy usług. Firmy integrujące się z Google powinny spełniać te wymagania dotyczące wydajności i dostępności interfejsu API.

Punkt końcowy Dostępność Czas oczekiwania (50 centyl) Czas oczekiwania (95 centyl)
POST /checkout-sessions (Utwórz) >= 95% <= 1 sekunda <= 4 sekundy
PUT /checkout-sessions/{id} (aktualizacja) >= 95% <= 1 sekunda <= 5 sekund
POST /checkout-sessions/{id}/complete (zakończono) >= 95% <= 6 sekund <= 10 sekund

50-ty percentyl opóźnienia oznacza, że co najmniej 50% żądań powinno zostać zrealizowanych w tym czasie. 95 centyl czasu oczekiwania oznacza, że co najmniej 95% żądań powinno zostać zrealizowanych w tym czasie.

Dalsze kroki

Wyświetl ładunki interfejsu API płatności i szczegóły techniczne implementacji w przypadku Twojej wersji UCP:

Jeśli integrujesz się jako zewnętrzny usługodawca, przejdź do sekcji Konfiguracja usługi płatności UCP, aby hostować profile sprzedawców i skonfigurować uzgadnianie relacji między kontami.

Wstecz
Cykl życia zamówienia (po zakupie)
Dalej
Kody błędów