Płatności agentowe: jak delegować płatność i ograniczać uprawnienia

Klient prosi agenta o zamówienie zwykle kupowanych materiałów eksploatacyjnych, ale w trakcie wyszukiwania zmieniają się cena i warunki dostawy. Kto zezwolił na pobranie nowej kwoty? Płatności agentowe powinny zaczynać się od odpowiedzi na to pytanie, a nie od przycisku płatności na czacie. Dla sklepu internetowego kluczową decyzją jest określenie granic delegowania: konkretnego sprzedawcy, waluty, kwoty, terminu i warunków ponownego potwierdzenia.

Chodzi o scenariusz, w którym agent programowy inicjuje płatność w imieniu użytkownika w granicach przyznanych uprawnień. Nie jest to zgoda na dysponowanie kartą przez model. Płatność realizuje odpowiednia infrastruktura, a sklep sprawdza zamówienie i wynik operacji. Poniżej wyjaśniamy, jak zaprojektować taki proces, odróżnić go od zwykłego checkoutu i przetestować przed uruchomieniem.

Gdzie kończy się pomoc w zakupach, a zaczyna delegowanie

Asystent może porównać produkty, skompletować koszyk i otworzyć stronę płatności. Jeśli końcową czynność za każdym razem wykonuje klient w standardowym checkoucie, nie jest to jeszcze autonomiczne delegowanie płatności. Kolejny poziom to uprzednie zezwolenie agentowi na sfinalizowanie określonego zakupu na uzgodnionych warunkach. Potrzebne są wtedy osobny zapis zgody, weryfikacja jej ważności i jasny sposób zatrzymania realizacji.

Warto rozdzielić trzy rzeczy: zamiar zakupu produktu, uprawnienie do zainicjowania płatności i faktyczny wynik przetwarzania. Wiadomość „kup najtańsze” nie określa dozwolonego sprzedawcy, pełnej kwoty z dostawą ani dopuszczalnego zamiennika. Nawet pomyślna autoryzacja bankowa nie oznacza, że magazyn potwierdził towar lub że zamówienie można już wysłać.

Ogólne możliwości rozmowy i obsługi katalogu to odrębny temat asystenta AI dla sklepu internetowego. W projekcie płatniczym przedmiotem odbioru nie jest jakość odpowiedzi bota, lecz zgodność każdej operacji finansowej z uzgodnionymi parametrami.

Porównuj tryby według mechanizmów kontroli, a nie poziomu autonomii

Początkowym rozwiązaniem może być koszyk przygotowany przez agenta i zwykłe potwierdzenie przez klienta. Rozszerzaj uprawnienia, jeśli powtarzalność zakupów uzasadnia większą złożoność utrzymania.

Przy drogich zakupach lub indywidualnych warunkach dostawy prostszy tryb jest często bardziej zrozumiały. Ogranicz pilotaż do jednego rodzaju zakupu, a nie całego asortymentu.

Co ogranicza token płatniczy — i czego nie potwierdza

Konkretnym przykładem realizacji są Shared Payment Tokens, czyli SPT, w Stripe. Zgodnie z oficjalną dokumentacją SPT agent udziela określonemu sprzedawcy ograniczonego dostępu do metody płatności klienta. Określa się dla niego walutę, maksymalną kwotę i termin wykorzystania. To przykład mechanizmu, a nie uniwersalny wymóg dla wszystkich płatności agentowych.

Ważność tokena nie jest tym samym co ważność zgody

Delegowanie płatności wymaga własnych reguł biznesowych. Klient może zezwolić na zakup do końca dnia roboczego, podczas gdy wydany token płatniczy będzie ważny krócej. Ważny token nie przedłuża wygasłej zgody, a ważna zgoda nie sprawia, że wygasły token nadaje się do użycia. Przed podjęciem działania sprawdzaj oba warunki niezależnie.

Usługa zarządzania zgodami musi wiązać operację z wersją koszyka i zasadami zamiany produktów. Jeśli zlecenie obejmuje kilka zakupów, potrzebna jest wyraźnie określona polityka; nie zamieniaj domyślnie jednorazowej zgody w subskrypcję.

Nie nazywaj wszystkich tokenów jednorazowymi

Stripe opisuje SPT dla płatności niecyklicznych i cyklicznych: nazwa „token” nie oznacza dokładnie jednego obciążenia. Przy jednorazowym zakupie sprawdź wybrany tryb i upewnij się, że nie przewidziano niezamierzonych płatności cyklicznych. Parametry zapisuj zgodnie z dokumentacją faktycznej wersji integracji.

Według stanu na 11 listopada 2026 roku Stripe wymienia kraje obsługiwane w ramach SPT; Ukrainy nie ma na tej liście. Nie jest to wniosek dotyczący wszystkich innych produktów płatniczych ani wszystkich klientów z ukraińskimi kartami. Dostępność sprawdza się dla konkretnych uczestników, kont, metod i rynków. Dostęp do standardowego acquiringu nie potwierdza dostępu do produktu agentowego.

Przykład hipotetyczny: cena zmieniła się po zatwierdzeniu

Hipotetyczny przykład w obsługiwanym środowisku: użytkownik zezwolił na zakup zestawu materiałów eksploatacyjnych u uzgodnionego sprzedawcy. Zgoda obejmuje kody produktów, pełną kwotę z dostawą, walutę i limit czasowy. Nie jest to realizacja GL.ua ani stwierdzenie, że usługa jest dostępna w Ukrainie.

Agent otrzymuje aktualną ofertę, a serwer sklepu zapisuje jej wersję. Po zatwierdzeniu zmieniają się warunki dostawy, a łączna kwota przekracza dozwolony limit. Prawidłową reakcją nie jest jej zaokrąglenie ani dodanie wyjaśnienia na czacie po pobraniu środków, lecz zatrzymanie realizacji i pokazanie nowych warunków. Nowy dostęp do płatności przyznaje się dopiero po właściwym potwierdzeniu zmiany zgody.

Jeśli kwota nadal mieści się w limicie, ale produkt zastąpiono innym, weryfikacja również musi to wychwycić. Limit pieniężny nie zastępuje sprawdzenia zawartości zakupu. W tym celu serwer porównuje wersję koszyka, sprzedawcę i dozwolone zamienniki; model jedynie proponuje działanie, a nie zmienia zasad zatwierdzania.

Osobnym wyjątkiem jest dodatkowe potwierdzenie przez klienta. W Stripe SPT może przejść do stanu requires_action, między innymi wtedy, gdy potrzebne jest uwierzytelnienie 3D Secure. Proces musi umieć się zatrzymać, przekazać człowiekowi wymagany krok i poprawnie wznowić działanie. Obietnica „płatności bez udziału klienta w każdych warunkach” jest tu nieprawidłowa.

Zbuduj kontrolowaną ścieżkę od zgody do zamówienia

Wydziel usługę sprawdzania zgody przed wywołaniem dostawcy płatności. Model językowy nie powinien otrzymywać tajnych kluczy o nieograniczonych uprawnieniach ani danych karty. Jego narzędzie płatnicze powinno przyjmować tylko minimalny zestaw parametrów dozwolonej operacji.

W takim łańcuchu potrzebne jest wspólne powiązanie zgody, wersji koszyka, zamówienia i operacji płatniczej. Kontrola uprawnień płatniczych oznacza, że te powiązania można sprawdzić po awarii, zamiast odtwarzać je z treści rozmowy. Ponowione żądanie z tym samym zamiarem nie powinno tworzyć drugiego zakupu tylko dlatego, że pierwsza odpowiedź zaginęła.

Protokół AP2 opisuje kryptograficznie podpisane mandaty dla checkoutu i płatności. Specyfikacja sprawia, że uprawnienia można zweryfikować, ale nie zapewnia automatycznie acquiringu. Obsługiwane wersje i role uczestników należy uzgodnić przed rozpoczęciem prac programistycznych.

Sklep osobno zarządza rezerwacją towaru. Jeśli płatność została potwierdzona po wygaśnięciu rezerwacji, nie można automatycznie obiecywać wysyłki. Potrzebna jest ponowna weryfikacja i określona ścieżka obsługi wyjątku. Ten powiązany proces opisuje materiał o potwierdzaniu dostępnych zapasów ATP.

Jak sprawdzić rozwiązanie przed uruchomieniem

Zacznij w środowisku testowym dostawcy od macierzy dozwolonych i zabronionych działań. Dla każdego testu potrzebne są oczekiwane stany zamówienia i płatności oraz osoba odpowiedzialna za obsługę wyjątku.

1. Potwierdź dostępność produktu dla wymaganych uczestników i metod płatności. Zapisz wersję integracji i ograniczenia dostępu testowego.
2. Odtwórz prawidłowy zakup, przekroczenie kwoty, inną walutę, innego sprzedawcę, zamianę produktu i wygaśnięcie zgody. Niedozwolone zmiany muszą zatrzymywać działanie.
3. Sprawdź wygasły i unieważniony token niezależnie od cofniętej zgody biznesowej. Nie polegaj wyłącznie na komunikacie w rozmowie.
4. Zasymuluj utratę odpowiedzi po żądaniu i ponowne dostarczenie wiadomości. Upewnij się, że powtórzenie nie tworzy nowego zamówienia ani zbędnej próby płatności.
5. Przejdź przez dodatkowe uwierzytelnienie, odrzucenie płatności, anulowanie i zwrot. Uzgodnij stany w sklepie i u dostawcy, uwzględniając opóźnione zdarzenia.
6. Sprawdź wyłączenie kanału agentowego, standardowy checkout i pracę obsługi klienta. Zespół musi widzieć przyczynę zatrzymania i dysponować instrukcją dla klienta.

Dziennik powinien wyjaśniać zdarzenia bez ujawniania sekretów i zbędnych danych osobowych. Przed nieodwracalnym działaniem sprawdzaj autentyczność wiadomości od dostawcy i stan operacji. To kryteria odbioru, a nie gwarancja braku oszustw.

Ryzyko, terminy i koszt pilotażu

Główne zagrożenia to błędnie zinterpretowana zgoda, podmiana warunków, ponowna realizacja, wyciek danych dostępowych i rozbieżność między płatnością a zamówieniem. Tokeny, weryfikacje po stronie serwera i dzienniki zmniejszają ryzyko, ale go nie eliminują. Zewnętrzny opis produktu ani wiadomość agenta nie mogą zmieniać polityki płatniczej.

Terminy zależą od gotowości całego łańcucha

Zaplanuj etapy: sprawdzenie dostępności, opis zgód, prototyp, integrację ze stanami zamówienia, testowanie wyjątków i ograniczone uruchomienie. Terminy zależą od dostępu do produktu, gotowości API, rezerwacji, zwrotów i obsługi klienta. Oszacowanie harmonogramu przedstaw po tych weryfikacjach.

W budżecie rozdziel analizę biznesową, interfejs zatwierdzania, usługę zarządzania zgodami, integrację płatniczą, dziennik zdarzeń, testy i instrukcje operacyjne. Osobno wycenia się infrastrukturę, korzystanie z modelu, opłaty dostawcy, monitoring i obsługę zmian API. Warunki przetwarzania płatności i odpowiedzialność stron należy wyjaśnić z dostawcą i kompetentnymi specjalistami; ten artykuł nie jest poradą finansową ani prawną.

Zacznij od granic uprawnień, które można zweryfikować, i zachowaj zwykły checkout jako działającą alternatywę. Jeśli sklep nie uzgodnił jeszcze stanów płatności i zamówienia, najpierw popraw ten proces. Aby przejść do konkretnego następnego kroku, przekaż GL.ua (Glyanets) schemat obecnego procesu płatności i jeden scenariusz delegowania w ramach tworzenia sklepu internetowego i jego integracji: to podstawa do oceny architektury pilotażu, jego ograniczeń i zakresu prac.