Zabezpečení Checkoutu

Tapaya hostuje pole pro kartu, tokenizaci, autentizaci karty i zatížení karty, takže vaše systémy nikdy nepracují s nezpracovanými údaji o kartě. Na vás zůstává server, který vytváří platby a rozhoduje, kdy je objednávka zaplacená. Tato pravidla platí pro hostovaný Checkout i pro vložené platby.

Jak Tapaya nakládá s údaji o držitelích karet a s osobními údaji, se dozvíte v části Ochrana údajů a soukromí.

Uchovávejte klíče na serveru

• Checkout klíč obchodníka nebo Secret key organizace ukládejte pouze do konfigurace na straně serveru. Ani jeden nepatří do kódu v prohlížeči, do balíčků mobilních aplikací ani do systému správy verzí. Do prohlížeče se dostane pouze publishable key a client secret platby.
• Checkout API obchodníka volejte ze svého serverového prostředí. Tyto požadavky nespouštějte v prohlížeči zákazníka.
• Checkout klíč obchodníka má přístup pouze ke svému obchodníkovi. Vlastnímu backendu obchodníka předejte tento klíč, nikdy ne Secret key vaší organizace.
• Secret key organizace má oprávnění v rámci celé organizace. V režimu platformy jej posílejte s X-Tapaya-Merchant-Token v každém požadavku; API ověří, že obchodník patří do organizace daného klíče. Viz autentizace Checkoutu.
• Klíče obchodníka se zobrazí jen jednou a ukládají se pouze jako hash. Klíč, u kterého máte podezření na únik, zneplatněte, ale až poté, co vytvoříte jeho náhradu.

Spravujte objednávku na svém serveru

• Celkovou částku objednávky počítejte na svém serveru a objednávku uložte dříve, než vytvoříte relaci nebo pokus o platbu.
• Částky, měnu a ID objednávek čtěte z uloženého snímku objednávky. Nepřijímejte náhradní hodnoty odeslané prohlížečem.
• U vložených plateb svažte své endpointy prepare a submit s autentizovaným checkoutem nebo s podepsanou HTTP-only cookie a u požadavků měnících data ověřujte jejich origin.

Před vyřízením objednávky ověřte platbu

Přesměrování prohlížeče, návštěva vaší URL pro úspěšnou platbu, parametry dotazu, návratové cookies a zprávy z prohlížeče jsou navigační data. Žádné z nich platbu neprokazuje.

• Načtěte relaci ze svého serveru a porovnejte její referenci objednávky, částku, měnu a stav platby s uloženou objednávkou.
• Objednávku vyřiďte pouze tehdy, když tato kontrola potvrdí paymentStatus: successful. Samotná odpověď HTTP 200 platbu neprokazuje.
• Vyřízení objednávky zaznamenávejte atomicky, aby opakované návraty nebo kontroly stavu nemohly vyřídit stejnou objednávku dvakrát.
• Pokud je relace stále ve stavu unpaid nebo se ji nepodaří načíst, ponechte si ID relace a kontrolu zopakujte s omezeným počtem pokusů. Nevytvářejte další relaci jen proto, že výsledek té první je neznámý: nová relace pro objednávku nahradí tu starou. Webhooky zatím nejsou k dispozici, proto stav odsouhlasujte opakovaným dotazováním (polling).

Opakujte požadavky bezpečně

• Před vytvořením relace uložte s objednávkou jedinečný idempotency key. Pokud u požadavku vyprší časový limit nebo se jeho odpověď ztratí, zopakujte jej se stejným klíčem a nezměněným tělem.
• Kvůli nejistému výsledku negenerujte nový klíč. Pravidla pro opakování najdete v části Idempotence a chyby.

Omezte originy pro přesměrování

• Do Allowed websites v nastavení Checkoutu přidávejte pouze originy svých vlastních obchodů.
• Pro nasazené obchody používejte HTTPS. Přepsání successUrl a cancelUrl pro jednotlivé relace musí i tak odpovídat nakonfigurovanému originu.

Nahlášení bezpečnostního problému

Pokud máte podezření na zranitelnost nebo bezpečnostní incident, kontaktujte bezpečnostní tým podle pokynů v části Kontakty.