Jak otestovat platební bránu v e-shopu: 3D Secure, webhooky a refundace
Platební integrace není hotová jen proto, že jedna testovací platba skončila zeleným potvrzením. Mezi kliknutím zákazníka, odpovědí banky, návratem do e-shopu a serverovým oznámením platební brány může nastat zpoždění, opakování i výpadek. Následující checklist pomáhá produktovému, vývojovému a QA týmu ověřit integraci před nasazením, aniž by zaměňoval předprodukční test za monitoring ostrého provozu.
Proč je platba řada stavů, ne jedno přesměrování
Prohlížeč zákazníka a server e-shopu dostávají výsledek různými cestami. Zákazník se může po platbě vrátit na děkovnou stránku, zavřít kartu nebo ztratit připojení. Nezávisle na tom může brána poslat webhook, tedy serverové oznámení o změně stavu platby. Objednávka proto potřebuje jednoznačná pravidla, který ověřený stav je rozhodující a které události smějí spustit rezervaci zboží, fakturu nebo e-mail.
Nejprve si zakreslete podporované stavy platby a jejich přechody. Názvy se mezi poskytovateli liší, obvykle je ale třeba rozlišit alespoň rozpracovanou, úspěšnou, zamítnutou, zrušenou a refundovanou platbu. Pokud ověřujete celý nákupní proces od košíku, pomůže také širší článek o automatizovaném testování e-shopu. Zde se soustředíme na integrační rozhraní a stav objednávky.
Předprodukční checklist
1. Úspěšná a zamítnutá platba. Při úspěchu ověřte částku, měnu, identifikátor objednávky a výsledný stav v e-shopu i administraci brány. Objednávka, potvrzení a související účetní záznamy mají vzniknout právě jednou. Při zamítnutí nebo technické chybě má zákazník dostat srozumitelnou možnost platbu zopakovat, objednávka se ale nesmí tvářit jako zaplacená. Používejte pouze testovací údaje doporučené vaším poskytovatelem; například Stripe dokumentuje samostatné testovací scénáře pro úspěch, zamítnutí a autentizaci. Jde o příklad možností jednoho dodavatele, nikoli o obecný seznam pro každou bránu.
2. Celý tok 3D Secure. 3D Secure je dodatečné ověření držitele karty, které může zákazníka přesunout do výzvy banky. Otestujte úspěšné ověření, zrušení zákazníkem, neúspěch, chybu a vypršení času. Vyzkoušejte také návrat tlačítkem zpět, obnovení stránky a pokračování po přerušení. Každá větev má skončit předvídatelným stavem a nesmí vytvořit druhou platbu ani druhou objednávku.
3. Návrat zákazníka není jediný zdroj pravdy. Zavřete kartu před návratem do e-shopu a doručte webhook až později. Potom proveďte opačný test: zákazník se vrátí, ale webhook se zpozdí. Rozhraní může dočasně ukázat stav „platbu ověřujeme“, úspěch ale nemá odvozovat pouze z adresy návratové stránky. Ověřte, že pozdější serverový stav objednávku bezpečně dokončí a zákazník může výsledek zjistit bez opakování platby.
4. Dvojklik, opakovaný pokus a idempotence. Zpomalte síť, dvakrát stiskněte tlačítko a zopakujte požadavek po zdánlivém timeoutu. Idempotence znamená, že opakování stejné operace nezpůsobí druhý obchodní výsledek. Pokud brána podporuje idempotency key, používejte jej podle její dokumentace, ale zároveň chraňte vlastní vytvoření objednávky jedinečným obchodním identifikátorem. Otestujte i souběžné požadavky, ne pouze opakování po sobě.
5. Webhooky v nepříjemném pořadí. Ověřte podpis nad původním tělem požadavku podle dokumentace dodavatele. Požadavek s neplatným podpisem odmítněte; platný typ události, který nezpracováváte, bezpečně ignorujte nebo zaznamenejte a potvrďte odpovědí podle kontraktu brány. U Stripe to obvykle znamená rychlou odpověď 2xx. Stejnou událost pak doručte dvakrát, pošlete novější stav před starším a nasimulujte opakování po chybě nebo timeoutu endpointu. Zpracování má být bezpečné při duplicitě a nemá předpokládat pořadí, které poskytovatel negarantuje. Stripe u webhooků výslovně popisuje opakování, duplicity i negarantované pořadí; u jiné brány ověřte její vlastní smlouvu a dokumentaci.
6. Stav objednávky a vedlejší účinky. U každého scénáře zkontrolujte databázi, sklad, e-mail, fakturaci a zákaznický účet. Událost přijatá dvakrát nesmí dvakrát odečíst zásobu ani odeslat dvě faktury. Zamítnutá nebo nedokončená platba nemá aktivovat placenou službu. Zároveň si dohodněte, zda se nezaplacená objednávka vůbec vytvoří a jak dlouho zůstane rezervovaná; test má ověřit vaše pravidlo, nikoli je vymyslet.
7. Refundace a částečná refundace. Otestujte plnou i částečnou částku, případně více částečných refundací v povoleném součtu. Zkontrolujte přechod objednávky, dostupnost v zákaznickém účtu, dobropis a informace pro podporu. Refundace může mít vlastní průběžný nebo neúspěšný stav, proto nestačí ověřit odpověď na první API požadavek; tým potřebuje sladit konečný výsledek s událostí brány.
Co sandbox nepotvrdí
Sandbox neboli testovací režim simuluje vybrané výsledky bez skutečného pohybu peněz. Nemusí však kopírovat pravidla bank, antifraud, časování, dostupnost platebních metod ani živou konfiguraci účtu. Před nasazením proto porovnejte testovací a ostré klíče, povolené měny a metody, návratové adresy, webhook endpoint, podpisový klíč a verzi API. Rozsah bezpečné ostré zkoušky si předem dohodněte s provozem a poskytovatelem; ne každá integrace ji potřebuje ve stejné podobě.
Po nasazení sledujte poměr zahájených, úspěšných a zamítnutých plateb, zpožděné nebo chybné webhooky, nesladěné stavy objednávek a dobu dokončení. Takové pozorování doplňuje release checklist, ale nenahrazuje jej. Návrh bezpečné opakované kontroly rozebírá samostatný článek o monitoringu platební brány.
Co tím získáte
Takto sestavené testy odhalují chyby v přechodech mezi stavy, nejen na výsledné obrazovce. Tým může před releasem doložit, že duplicita, zpoždění či přerušení nezpůsobí neočekávaný obchodní výsledek v ověřeném rozsahu. Stejná očekávání pak pomáhají podpoře a provozu při diagnostice skutečného incidentu.
Další krok: uzavřete checklist
Ke každému scénáři přiřaďte očekávaný stav platby, stav objednávky, povolené vedlejší účinky a důkaz v logu. Potom označte vlastníka, který umí neúspěch vyhodnotit před releasem. Výsledkem není jen jedna úspěšná zkušební platba, ale opakovatelný důkaz, že integrace zvládne i přerušení, duplicitu a zpoždění bez ztráty nebo zdvojení objednávky.