Kontrolní seznam QA

Projděte tento kontrolní seznam v sandboxu a před přijímáním plateb v ostrém provozu dokončete kontroly pro produkční prostředí. Seznam pokrývá výsledky plateb, ověření, opakované pokusy, konfiguraci a zabezpečení. Každou kontrolu po ověření zaškrtněte.

1. Výsledky plateb

Úspěšná platbaPO-1Zaplaťte kartou 4242 4242 4242 4242. Načtená relace má paymentStatus: successful a objednávka je vyřízena právě jednou. Zamítnutá kartaPO-2Zaplaťte kartou 4916 0184 7581 4056. Objednávka zůstane nezaplacená a opakovaný pokus s kartou pro úspěšnou platbu projde, dokud je relace otevřená. 3-D SecurePO-3Zaplaťte kartou 4012 0018 0000 0016 a dokončete ověření (challenge). Vyřízení objednávky čeká na načtený stav. Chyba zpracováníPO-4Použijte testovací kartu pro chybu zpracování určenou pro testovací platební bránu. Objednávka zůstane nezaplacená, přestože karetní formulář kartu přijal. Neošetřené stavyPO-5Váš kód považuje unpaid, failed, action_needed, cancelled a neznámé hodnoty za nezaplacené. Viz Stav platby.

2. Ověření a vyřízení objednávky

Kontrola na straně serveruVF-1Vyřízení objednávky porovnává referenci objednávky, částku, měnu a paymentStatus s uloženou objednávkou, nikoli s údaji z přesměrování. URL úspěchu bez zaplaceníVF-2Otevřete URL úspěchu přímo, bez zaplacení. Objednávka zůstane nezaplacená. Odkaz pro zrušeníVF-3Klikněte na odkaz pro zrušení v Checkoutu. Objednávka zůstane nezaplacená a váš kód nepředpokládá stav cancelled jen na základě samotné navigace. Opakovaný návratVF-4Po úspěšné platbě dvakrát znovu načtěte návratovou stránku. Objednávka je vyřízena právě jednou.

3. Opakované pokusy a přerušení

Pro každý nezávislý případ použijte novou testovací objednávku a relaci. U testů opakovaných pokusů znovu použijte původní objednávku, tělo požadavku a idempotency key.

Ztracená odpověď na vytvořeníRI-1Ve svém testovacím kódu zahoďte odpověď na vytvoření a požadavek zopakujte se stejným Idempotency-Key a tělem. Vrátí se původní relace a druhá se nevytvoří. Změněné těloRI-2Použijte klíč znovu s jiným tělem. API vrátí HTTP 409 a váš kód to nepovažuje za novou relaci. Zákazník se nevrátíRI-3Zaplaťte a zavřete kartu prohlížeče dřív, než dojde k návratu. Vaše úloha pro odsouhlasení načte uloženou relaci a zaznamená platbu právě jednou. Časový limit při zjišťování stavuRI-4Navoďte vypršení časového limitu při načítání stavu. Vaše aplikace si ponechá ID relace, nechá výsledek nevyřešený a nevytvoří náhradní relaci. Nahrazená relaceRI-6Vytvořte druhou relaci pro stejnou nezaplacenou objednávku. První URL hlásí expired a nelze přes ni zaplatit. Po zaplacení objednávky vrátí vytvoření další relace HTTP 409. Vypršení relaceRI-5Počkejte, až uplyne expiresAt (30 minut), a URL znovu otevřete. Žádnou novou platbu nelze zahájit a objednávka zůstane nezaplacená.

4. Nastavení Checkoutu

Schválený obchodníkCS-1Každý obchodník, pro kterého přijímáte platby, je v tabulce Checkout merchants ve stavu Ready. Návratové cíleCS-2Výchozí URL úspěchu a zrušení jsou nastaveny pro přihlašovací údaje, které používáte (výchozí hodnoty organizace pro Secret key, nastavení obchodníka pro klíč obchodníka), používají HTTPS a jejich přesné originy jsou uvedeny v seznamu Allowed websites těchto přihlašovacích údajů. Přepsání pro jednotlivé relaceCS-3Každé successUrl nebo cancelUrl, které odešlete, odpovídá nakonfigurovanému originu. PeněženkyCS-4Apple Pay a Google Pay jsou zapnuté nebo vypnuté podle záměru. Google Pay v ostrém provozu má nakonfigurované Google Pay merchant ID. Peněženky ve vložených platbáchCS-6Celková částka v peněžence odpovídá objednávce na serveru. Změna dopravy nebo slev ji aktualizuje. Zrušení v peněžence ponechá checkout dostupný a čekající platby blokují další platbu. BrandingCS-5Barva a logo vypadají v Checkout preview správně v rozvržení pro počítač i pro mobil.

5. Zabezpečení

Klíč na serveruSE-1Váš checkout klíč obchodníka nebo Secret key organizace je pouze v konfiguraci serveru, nikdy v kódu prohlížeče, balíčcích aplikace ani v systému správy verzí. Částky určuje serverSE-2Částka, měna a ID objednávky pocházejí z vaší uložené objednávky, nikdy z prohlížeče. Endpointy pro vložené platbySE-3Pokud používáte vložené platby, jsou prepare a submit vázány na autentizovaný checkout nebo podepsanou HTTP-only cookie a originy měnících požadavků se ověřují. Content Security PolicySE-4Pokud používáte vložené platby, vaše CSP povoluje originy skriptů a rámců Tapaya a ověření 3-D Secure v jejím rámci stále fungují.

6. Konfigurace sandboxu

Sandboxové APIPR-1TAPAYA_CHECKOUT_API_URL ukazuje na https://api.sandbox.tapaya.com. Sandboxový klíčPR-2Integrace používá sandboxový checkout klíč obchodníka nebo Secret key organizace načtený z konfigurace serveru. Úloha pro odsouhlaseníPR-3Úloha, která načítá nevyřešené relace, je naplánována ve vašem testovacím prostředí.

7. Připravenost na produkci

Připravenost obchodníkaLV-1Obchodník v ostrém provozu dokončil onboarding s online platbami, získal schválení zpracovatele a má nakonfigurovanou platební bránu. V nastavení Checkoutu je obchodník ve stavu Ready. Přihlašovací údaje pro ostrý provozLV-2Server používá produkční přihlašovací údaje a https://api.tapaya.com. Integrace přes SDK nastavují TAPAYA_ENVIRONMENT=production. Sandboxové klíče a testovací karty se pro platby v ostrém provozu nepoužívají. Peněženky v ostrém provozuLV-3Domény obchodů pro Apple Pay jsou aktivní. Google Pay v ostrém provozu má nakonfigurované merchant ID. Podporované peněženky dokončí platbu a po zrušení fungují dál. Odsouhlasení v ostrém provozuLV-4Produkční návratové URL, ověření na serveru, vyřízení objednávky i úloha pro odsouhlasení používají produkční konfiguraci. Chybí vám něco na této stránce?Navrhněte funkci. Připojíme tuto stránku, aby tým viděl souvislosti.