Czy Twój checkout jest gotowy na płatności AI (Google Pay UCP)?
Praktyczny, bezkodowy framework, jak przygotować checkout na płatności AI i Google Pay UCP: czytelne dane produktu, bezpieczna rezerwacja/wycena, płatność serwer-do-serwera oraz audyt i limity.
Najważniejsze wnioski
- Uczyń ofertę jednoznaczną dla maszyn: nazwa, cena, dostępność, dostawa, zwroty.
- Dodaj quote/hold i idempotencję (unikalny numer operacji) przeciw duplikatom.
- Ustal płatność serwer-do-serwera z SCA i tokenizacją, plus jasne fallbacki.
- Prowadź audyt działań agenta, limity i ścieżki eskalacji.
Agenci zakupowi AI (programy, które same porównują oferty i składają zamówienia) wchodzą do e‑commerce. Media branżowe piszą, że Google Pay pracuje nad UCP. Co to znaczy dla Twojego checkoutu (ostatniego kroku zakupu)? Oto prosty plan bez kodu: dane, rezerwacja, płatność i audyt.
O co chodzi w płatnościach AI i Google Pay UCP?
Agent zakupowy AI to program, który w imieniu klienta porównuje oferty i składa zamówienie. Działa jak bardzo sprytny asystent, tylko w pełni automatycznie. Według doniesień branżowych Google Pay pracuje nad UCP (Universal Commerce Protocol) – sposobem uzgadniania danych i płatności między sklepem a takim agentem. Publiczne szczegóły są ograniczone, ale kierunek jest jasny.
Znaczy to tyle: część zakupów zrobi nie człowiek patrzący na ładną stronę, ale oprogramowanie czytające konkretne pola. Twój checkout (ostatni krok zakupu) musi więc być zrozumiały dla maszyny, przewidywalny i bezpieczny. Wniosek: minimum klikania, maksimum pewności transakcji.
Krok 1: Oferta czytelna dla agenta – dane, cena, dostępność
Agent nie ogląda strony. On czyta dane. Uporządkuj ofertę tak, by podstawowe informacje były jednoznaczne i zawsze w tym samym miejscu.
Zadbaj o jedno źródło prawdy. Najprościej: feed produktowy – prosta lista produktów w pliku lub linku, aktualizowana cyklicznie (np. co godzinę). Na stronie możesz też dodać opisy w schema.org (to etykiety w kodzie, które opisują produkt). Wniosek: im mniej niedomówień w danych, tym większa szansa, że agent bez pytania dokończy zakup.
- nazwa produktu i SKU (wewnętrzny kod jak numer katalogowy)
- cena brutto i waluta
- dostępność: liczba sztuk lub status typu na stanie/na zamówienie
- czas i koszt dostawy oraz metody wysyłki
- warianty (rozmiar, kolor) i ewentualne zamienniki
- warunki zwrotu i gwarancji (w punktach) oraz link do regulaminu sklepu/polityki zwrotów/poufności danych (RODO)
Krok 2: Uzgodnienie ceny i rezerwacja – quote/hold i idempotencja
Przed płatnością agent powinien dostać quote (tymczasową wycenę ważną X minut) oraz hold (krótką rezerwację towaru lub środków). To jak kartka „zarezerwowane” na krześle: nikt go w tym czasie nie zajmie.
Kluczowa jest idempotencja: każda operacja ma unikalny numer, jak paragon. Gdy zostanie wysłana dwa razy, sklep uzna ją za tę samą i nie policzy podwójnie. To chroni przed duplikatami, gdy agent ponowi próbę. Wniosek: spisz te reguły i uzgodnij je z zespołem oraz dostawcą płatności – to zwykle ustawienia, nie kod.
- czas ważności wyceny (np. 10–15 minut)
- ile sztuk i na jak długo rezerwujesz (hold)
- unikalny numer operacji w każdym kroku (quote, hold, zakup)
- limity dzienne/kwotowe na jednego agenta lub domenę
- co robisz, gdy towar się skończy (alternatywa lub anulacja)
Krok 3: Płatność serwer-do-serwera, SCA i audyt działań agenta
Płatność serwer-do-serwera to wymiana informacji między Twoim serwerem a bramką płatniczą, bez polegania na przeglądarce klienta. Jak telefon kasjera do banku: cicho, pewnie i z potwierdzeniem na piśmie.
SCA (Strong Customer Authentication) to mocne potwierdzenie tożsamości wymagane przez PSD2 (unijne zasady płatności). Często odbywa się przez 3-D Secure – np. zatwierdzenie w aplikacji banku. Portfele jak Google Pay używają tokenizacji (zastąpienie numeru karty bezpiecznym tokenem), co może uprościć to potwierdzanie.
Na koniec potrzebny jest audyt, czyli dziennik zdarzeń: kto (nazwa agenta lub źródło), co zamówił, za ile, kiedy, jaki był wynik płatności i dlaczego. Dodaj proste ścieżki eskalacji: gdy kwota przekracza X zł lub SCA się nie uda – zatrzymaj zamówienie i poproś człowieka o decyzję lub wyślij link do płatności klientowi. Wniosek: dzięki temu agent płaci bez tarcia, a Ty masz kontrolę i zgodność.
- potwierdzenie płatności odbierane na serwerze sklepu
- obsługa powtórzeń z tym samym numerem operacji (idempotencja)
- tokenizacja i 3-D Secure włączone tam, gdzie wymagane
- listy dozwolonych/zablokowanych źródeł agentów oraz limity kwotowe
- jasne zasady zwrotów i czasu zwrotu środków
Zrób cztery kroki w przygotowaniu checkoutu: dane, rezerwacja, płatność, audyt. Wtedy Twój checkout będzie gotowy na płatności AI – niezależnie od tempa UCP. Chcesz szybki przegląd ustawień i zasad, bez wchodzenia w kod? Umów krótką konsultację – pomogę ułożyć plan działań i priorytety.
Najczęstsze pytania
Czy muszę czekać na UCP, aby zacząć przygotowania?
Nie. Porządkowanie danych, quote/hold, idempotencja, SCA i audyt to uniwersalne praktyki. Zrobisz je już dziś, a gdy UCP będzie szerzej dostępne, po prostu podłączysz się do standardu.
Czy płatność serwer-do-serwera oznacza, że klient nic nie potwierdza?
Nie zawsze. SCA może być wymagana i zwykle odbywa się przez 3-D Secure (np. zatwierdzenie w aplikacji banku). Różnica jest taka, że techniczne potwierdzenie płatności trafia do Twojego serwera, a nie tylko do przeglądarki.
Jak ograniczyć ryzyko nadużyć przez agentów AI?
Wprowadź limity kwotowe i ilościowe, listy dozwolonych/zablokowanych źródeł, idempotencję i pełny audyt. Ustal też progi, po których transakcja trafia do ręcznej weryfikacji.
Co jeśli mój checkout nie wspiera krótkiej rezerwacji (hold) dla agentów AI?
Ustal krótką rezerwację koszyka (np. 10–15 minut), jasno to komunikuj i anuluje wycenę po czasie. To prosty odpowiednik hold na potrzeby agentów AI, który można ustawić procesowo, często bez zmian w kodzie.