QA Checklist

Run through this checklist against the development environment before releasing your integration. It covers payment outcomes, verification, retries, configuration, and security. Tick each check as you verify it.

1. Payment outcomes

Successful paymentPO-1Pay with 4242 4242 4242 4242. The retrieved session has paymentStatus: successful and the order is fulfilled once. Declined cardPO-2Pay with 4916 0184 7581 4056. The order stays unpaid, and a retry with the success card works while the session is open. 3D SecurePO-3Pay with 4012 0018 0000 0016 and complete the challenge. Fulfillment waits for the retrieved status. Processing errorPO-4Use a processing-error test card for the development gateway. The order stays unpaid even though the card form accepted the card. Unhandled statesPO-5Your code treats unpaid, action_needed, cancelled, and refunded as not paid. See Payment status.

2. Verification and fulfillment

Server-side checkVF-1Fulfillment compares order reference, amount, currency, and paymentStatus with the stored order, not the redirect. Unpaid success URLVF-2Visit the success URL directly without paying. The order stays unpaid. Cancel linkVF-3Follow Checkout's cancel link. The order stays unpaid, and your code does not assume a cancelled status from the navigation alone. Repeated returnVF-4After a successful payment, reload the return page twice. The order is fulfilled once.

3. Retries and interruptions

Use a fresh test order and session for each independent case. For retry tests, reuse the original order, request body, and idempotency key.

Lost create responseRI-1Discard the create response in your test harness and repeat with the same Idempotency-Key and body. The original session is replayed and no second one is created. Changed bodyRI-2Reuse a key with a different body. The API returns HTTP 409 and your code does not treat it as a new session. Customer never returnsRI-3Pay, then close the tab before it returns. Your reconciliation job retrieves the stored session and records the payment once. Status timeoutRI-4Make retrieval time out. Your app keeps the session ID, leaves the outcome unresolved, and does not create a replacement session. Session expiryRI-5Wait past expiresAt (30 minutes) and reopen the URL. No new payment can start and the order stays unpaid.

4. Checkout settings

Checkout enabledCS-1Enable Checkout is on for the one merchant matching your organization. Return destinationsCS-2Default success and cancel URLs are set, use HTTPS, and their exact origins are in Allowed redirect origins. Per-session overridesCS-3Any successUrl or cancelUrl you send matches a configured origin. WalletsCS-4Apple Pay and Google Pay are on or off as intended. Live Google Pay has a Google Pay merchant ID configured. BrandingCS-5Color and logo look right in Checkout preview on both desktop and mobile layouts.

5. Security

Key on the serverSE-1The Secret key is only in server configuration, never in browser code, app bundles, or source control. Server-owned totalsSE-2Amount, currency, and order ID come from your stored order, never from the browser. Embedded endpointsSE-3If you use embedded payments, prepare and submit are bound to an authenticated checkout or signed HTTP-only cookie, and mutation origins are validated. Content security policySE-4If you use embedded payments, your CSP allows the provider's scripts, frames, and connections, and 3D Secure challenges still work under it.

6. Production readiness

Production APIPR-1TAPAYA_CHECKOUT_API_URL points at the API base URL supplied for your production deployment, not api.sandbox.tapaya.com. Production keyPR-2The production build uses the production Secret key, loaded from server configuration. Reconciliation jobPR-3The job that retrieves unresolved sessions is scheduled in production.