Płatności gotowe na agentów: jak rezerwacje rozliczają się, gdy nikt nie wypełnia formularza

Piątek, 21:42. Podróżujący prosi swojego asystenta AI: „Zarezerwuj mi jutro po południu 60-minutowy masaż głębokich tkanek niedaleko mojego hotelu, do 80 €, z 24-godzinnym oknem rezygnacji."

Agent znajduje trzech dostawców. Dwóch wymaga przepływu card-on-file otwieranego w przeglądarce. Agent nie potrafi otworzyć przeglądarki. Wybiera trzeciego — tego, który przyjął rezerwację i zablokował zaliczkę w jednym wywołaniu API, w oparciu o mandat autoryzowany przez użytkownika tydzień wcześniej.

Ciebie na tej krótkiej liście nie było. Nie dlatego, że twoje ceny były złe. Dlatego, że agent nie mógł ci zapłacić.

Discovery rozwiązuje AEO. Połączenie rozwiązuje MCP. Płatność to kolejny punkt awarii — i większość systemów rezerwacyjnych nie jest na nią gotowa.

Dlaczego klasyczny checkout się sypie pod agentem

Normalny checkout zakłada cztery rzeczy. Każda z nich pęka w momencie, gdy kupującym jest agent AI:

1. Widoczne wyzwanie 3DS. Strong Customer Authentication (SCA) z PSD2 zostało zaprojektowane tak, by przerwać użytkownika UI-em. Agent nie widzi UI. Jeśli twoja jedyna ścieżka przez SCA to redirect do strony wystawcy karty — rezerwacja kończy się cichą porażką.
2. Sesja przeglądarki, która zostaje otwarta. Tokenizowane skarbce kart często oddają iframe lub redirect target. Agenci wołają API i ruszają dalej; nie utrzymują otwartych zakładek.
3. Ludzki kciuk na przycisku „Potwierdź". Dwie dekady badań UX optymalizowały moment, w którym człowiek mówi „tak". Tego momentu już nie ma.
4. Pola formularza na dane karty. Nawet jeśli agent ma metodę płatności, to prawie nigdy nie jest to surowy PAN. To token, mandat albo delegowany handle do portfela.

Jeśli twój checkout zakłada którekolwiek z tych — agent przejdzie do dostawcy, który ich nie zakłada.

Trzy modele autoryzacji w agentic commerce

Nie ma jednego słusznego wzorca. Dziś zbiegają się trzy — każdy z innym profilem zaufania i latencji:

1. Wstępnie autoryzowane mandaty

Użytkownik nadaje agentowi (lub portfelowi za agentem) stałe upoważnienie do obciążania określonych kategorii usług do limitu. Agent rezerwuje i pobiera środki w jednym wywołaniu.

• Najlepsze dla: zaufanych platform, rezerwacji powtarzalnych lub niskiej wartości, częstych podróżników.
• Mechanika: Stripe Customer mandate, mandaty ACH/SEPA, card-on-file z intencjami off-session.
• Trade-off: najwyższa wygoda, najniższe tarcie. Użytkownik nie ocenia każdego obciążenia osobno.

2. Płatności delegowane

Agent przygotowuje payment intent i przekazuje go zweryfikowanemu urządzeniu użytkownika do potwierdzenia dotknięciem. Rezerwacja jest zablokowana; człowiek ratyfikuje.

• Najlepsze dla: rezerwacji o większej wartości, pierwszych transakcji u nowego dostawcy, branż regulowanych.
• Mechanika: PaymentIntent off-session, push do portfela, capture po potwierdzeniu biometrycznym.
• Trade-off: mocna postawa antyfraudowa, ale 5–60 sekund opóźnienia z człowiekiem-w-pętli.

3. Potwierdzenia per transakcja

Agent commitsuje rezerwację z blokadą; użytkownik dostaje powiadomienie, dotyka „potwierdź", środki zostają pobrane. Jeśli zignoruje — autoryzacja wygasa, slot się zwalnia.

• Najlepsze dla: dostawców, którzy nie mają jeszcze relacji mandatowej z użytkownikiem.
• Mechanika: PaymentIntent z capture_method=manual, 7-dniowe okno autoryzacji, webhook na capture.
• Trade-off: najwyższa odpadalność, najniższy próg zaufania.

Większość dostawców skończy obsługując modele 2 i 3. Portfel — Apple Pay, Google Pay albo agent-native wallet — zdecyduje, który odpali w danej transakcji.

Blokady i zaliczki jako warstwa zaufania

Najczystszy wzorzec, jaki widzimy: agent commitsuje wcześnie, człowiek ratyfikuje później, slot jest zablokowany w międzyczasie.

Konkretnie:

1. Agent woła createBooking z paymentIntent, którego capture_method to manual.
2. Karta jest autoryzowana — środki zarezerwowane, nie pobrane. Na większości sieci kartowych autoryzacja trzyma się do 7 dni.
3. Twój system emituje webhook i push do użytkownika.
4. Użytkownik potwierdza → robisz capture. Ignoruje → autoryzacja wygasa, slot zwalnia się automatycznie.

To jest graceful degradation. Agent działa zdecydowanie, użytkownik zachowuje ostatnie słowo, ty nigdy nie zostajesz z fantomową rezerwacją blokującą realnych klientów.

Zwroty i no-show, gdy rezerwujący nie jest człowiekiem

Gdy kupującym jest AI, krajobraz sporów się zmienia:

• Log agenta staje się dowodem. Otagowany czasowo trace wywołań narzędzi („użytkownik poprosił o rezerwację, agent potwierdził, płatność pobrana w T+3.2s") jest mocniejszym dowodem niż jakiekolwiek ciasteczko sesji.
• Ryzyko chargebacków spada dla transakcji, w których podpisał się zweryfikowany mandat — wystawca traktuje to bliżej powtarzalnego, autoryzowanego obciążenia niż sporu CNP.
• Wstępne zaliczki zyskują na znaczeniu. Odzbrajają przypadek no-show, w którym agent zarezerwował z entuzjazmem, a użytkownik nie pojawił się.
• Twoja polityka no-show musi być czytelna maszynowo. Jeśli warunki rezygnacji są zakopane w stronie prawnej — agent je zignoruje, a twoje decyzje zwrotowe wyglądają potem na arbitralne.

Wystaw politykę jako strukturę: okno rezygnacji, kwota zaliczki, progi zwrotu. Agenci czytają to zanim zarezerwują, nie gdy coś idzie nie tak.

Co Timerise daje dziś

Jeśli budujesz na Timerise — klocki są już na miejscu:

• paymentIntent z manual capture na każdej mutacji rezerwacji. Domyślne okno blokady: 7 dni, zwracane w odpowiedzi, żeby agent wiedział, kiedy wygasa.
• Stripe customer mandates wiązane z sesją rezerwacyjną Timerise — wielokrotnego użytku u różnych dostawców pod tym samym merchant of record.
• Webhook acknowledgement jako kanoniczne zdarzenie „booking confirmed". Nie ufaj HTTP 200 z wywołania rezerwacji; ufaj webhookowi.
• Klucze idempotencji wymagane na createBooking i capturePayment. Replay-safe z definicji.
• Strukturalne kody błędów, na których agent może routować bez parsowania angielskiego: card_declined, insufficient_authorization, slot_taken, mandate_revoked, sca_required.

Mapują się czysto na narzędzia MCP, które wystawiamy — agent podłączony przez MCP odzyskuje się po nieudanej płatności bez eskalacji do użytkownika. Najczęściej.

Checklist: agent-ready payments

Jeśli chcesz rezerwacji od agentów AI, prześwietl powierzchnię płatności wg tej listy:

1. Klucze idempotencji na mutacjach rezerwacji i płatności. Agent będzie retryował; zrób retry-y bezpiecznymi.
2. Webhooki, które są kanonicznym potwierdzeniem rezerwacji, nie opcjonalnym listenerem.
3. Strukturalne kody błędów — stringi, na których agent zrobi switch, nie ludzkie komunikaty.
4. Flagi wyjątków SCA w odpowiedziach (Low Value, Trusted Beneficiary, MIT) — żeby agent wiedział, kiedy challenge da się ominąć.
5. Manual capture z oknem blokady (w sekundach) zwracanym w odpowiedzi.
6. Polityka zwrotów i rezygnacji jako pola, nie free-form text. Cutoff w ISO 8601, procent zwrotu jako liczba.
7. URL paragonu w odpowiedzi sukcesu. Agenci wrzucają je użytkownikowi do portfela automatycznie.

Połowa to zwykła higiena API. Druga połowa to różnica między „akceptujemy płatności" a „agenci będą u nas kupować".

Płatność to prawdziwy handshake

Discovery (AEO) sadza cię na krótkiej liście. Połączenie (MCP) pozwala agentowi rozmawiać. Płatność to moment, w którym rezerwacja faktycznie staje się rezerwacją.

Jeśli twój checkout dalej zakłada przeglądarkę i ludzki kciuk — zbudowałeś zapraszające drzwi z zamkiem, którego agent nie złamie. Agent przejdzie do następnego dostawcy na liście — po cichu, bez ticketu, którego mógłbyś zdebugować.

Najbliższe dwanaście miesięcy podzieli biznesy rezerwacyjne na dwa obozy: te, w których pieniądze ruszają się z prędkością agenta — i te, które wciąż czekają na klik potwierdzenia, który nigdy nie nadejdzie.