Checkout Security

Tapaya hosts the card fields, tokenization, card authentication, and charging, so your systems never handle raw card data. What stays with you is the server that creates payments and decides when an order is paid. These rules apply to both hosted Checkout and embedded payments.

For how Tapaya handles cardholder and personal data, see Data Protection & Privacy.

Keep the Secret key on the server

• Store the Secret key from the API Keys page in server-side configuration only. It never belongs in browser code, mobile app bundles, or source control.
• Call the merchant Checkout API from your server runtime. Do not run these requests in the customer's browser.
• The Secret key has organization-wide privileges. Send it as Authorization: Bearer <secret-key> for Checkout. See Checkout authentication for merchant matching requirements.

Own the order on your server

• Calculate the order total on your server and persist the order before creating a session or payment attempt.
• Read amounts, currency, and order IDs from your stored order snapshot. Do not accept replacements sent by the browser.
• For embedded payments, bind your prepare and submit endpoints to an authenticated checkout or a signed HTTP-only cookie, and validate the origin of mutation requests.

Verify before you fulfill

A browser redirect, a visit to your success URL, query parameters, return cookies, and browser messages are navigation data. None of them proves payment.

• Retrieve the session from your server with the Secret key and compare its order reference, amount, currency, and payment status with the stored order.
• Fulfill only when that check confirms paymentStatus: successful. An HTTP 200 response alone does not prove payment.
• Record fulfillment atomically, so repeated return visits or status checks cannot fulfill the same order twice.
• If the result is pending or retrieval fails, keep the session ID and check again with a bounded retry. Do not create another session because the first result is unknown.

Retry safely

• Persist a unique idempotency key with the order before creating a session. If a request times out or its response is lost, retry with the same key and an unchanged body.
• Do not generate a new key for an uncertain result. See Idempotency and errors for the replay rules.

Restrict redirect origins

• Add only your own shop origins to Allowed redirect origins in Checkout settings.
• Use HTTPS for deployed shops. Per-session successUrl and cancelUrl overrides must still match a configured origin.

Reporting a security issue

If you suspect a vulnerability or a security incident, contact the security team as described in Contacts.