Omówienie natywnego procesu płatności

Aby umożliwić użytkownikom dokonywanie zakupów, musisz zaimplementować integrację z natywnym procesem płatności. Wymaga to utworzenia standardowego interfejsu API REST, który umożliwi Google zautomatyzowane zarządzanie procesem płatności na Twoich serwerach. Ta metoda zapewnia użytkownikom najbardziej płynne działanie. Początkowo Google będzie renderować interfejs użytkownika dla kupującego, ale w przyszłości planuje obsługę bardziej zaawansowanych funkcji.

Proces płatności

Integracja natywna wymaga utworzenia interfejsu API RESTful, 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. Tworzenie sesji płatności: użytkownik i opcjonalnie agent dodają produkty do sesji.
  2. Przekazanie do interfejsu Google: gdy użytkownik zdecyduje się na dokonanie zakupu, agent (jeśli jest zaangażowany) przekazuje kontrolę do interfejsu Google (przekazując dane sesji płatności).
  3. Ręczne dokonywanie płatności: użytkownik wchodzi w interakcję tylko z interfejsem Google, aby podać poufne informacje o realizacji zamówienia i płatności oraz przesłać zamówienie. Agent nie jest zaangażowany w tę część procesu, co zapewnia determinizm.
  4. Zakończenie i powrót: interfejs Google wyświetla stronę „Dziękujemy” potwierdzającą 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ę jak użytkownik przechodzi 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: stan początkowy po utworzeniu sesji. Wskazuje, ż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órego należy użyć po tym, jak użytkownik zaktualizuje adres dostawy i obliczysz opcje dostawy oraz kwoty, ale zanim zostanie sfinalizowana forma płatności.
  • ready_for_complete: stan, którego należy użyć podczas pełnego uzupełniania obiektu płatności, gdy forma płatności zostanie wybrana i wszystkie szczegóły zamówienia zostaną zweryfikowane.
  • completed: stan końcowy zwracany po pomyślnym przetworzeniu płatności i złożeniu zamówienia.
  • canceled: stan zwracany, jeśli sesja płatności zostanie przerwana.
  • error: stan zwracany, jeśli nieodwracalny błąd logiki biznesowej uniemożliwia dokonanie płatności. Ten stan jest dostępny w UCP w wersji 2026-04-08 i nowszej.

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

Google obsługuje teraz wiele różnych pozycji w 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 polecenie POST /checkout-sessions, które zawiera wszystkie różne produkty w tablicy line_items. Tablica line_items będzie zawierać osobny obiekt dla każdego unikalnego produktu, za który ma zostać dokonana płatność.
  3. Użytkownik może zaktualizować formę płatności, szczegóły realizacji zamówienia lub zastosować rabaty za pomocą wywołań PUT /checkout-sessions/{id}.
  4. Gdy użytkownik kliknie przycisk „Zapłać za pomocą Google Pay”, zostanie wywołane polecenie POST /checkout-sessions/{id}/complete.

Uwierzytelnianie

Szczegółowe informacje o zabezpieczaniu punktów końcowych interfejsu Native Checkout API, w tym o 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 implementację interfejsu Native Checkout API, w repozytorium Universal Commerce Protocol na GitHubie znajdziesz te materiały:

  • Repozytorium UCP na GitHubie: znajdziesz tu główne repozytorium z obszerną dokumentacją, specyfikacjami i zasobami społeczności.
  • Pakiety SDK: używaj pakietów SDK, aby przyspieszyć integrację. Dostępne są pakiety SDK w różnych językach, m.in.:

  • Testy zgodności: sprawdzaj punkty końcowe interfejsu API pod kątem zgodności ze specyfikacją UCP za pomocą pakietu testów zgodności .

    Pomaga to zapewnić, że Twoja implementacja 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 (SLO): Firmy integrujące się z Google powinny spełniać te cele w zakresie skutecznoś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} (Aktualizuj) >= 95% <= 1 sekunda <= 5 sekund
POST /checkout-sessions/{id}/complete (Zakończ) >= 95% <= 6 sekund <= 10 sekund

50 centyl czasu oczekiwania 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 implementacji technicznej dla swojej wersji UCP:

Wstecz
Authentication
Dalej
Cykl życia zamówienia (po zakupie)