QA Checklist

Run through this checklist against the sandbox environment, then complete the production checks before accepting live payments. 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 test gateway. The order stays unpaid even though the card form accepted the card. Unhandled statesPO-5Your code treats unpaid, failed, action_needed, cancelled, and unknown values 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. Replaced sessionRI-6Create a second session for the same unpaid order. The first URL reports expired and cannot take payment. After the order is paid, creating another session returns HTTP 409. Session expiryRI-5Wait past expiresAt (30 minutes) and reopen the URL. No new payment can start and the order stays unpaid.

4. Checkout settings

Merchant approvedCS-1Each merchant you take payments for is in the Checkout merchants table with status Ready. Return destinationsCS-2Default success and cancel URLs are set for the credential you use (organization defaults for the Secret key, the merchant's settings for a merchant key), use HTTPS, and their exact origins are in that credential's Allowed websites. 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. Embedded walletsCS-6The wallet total matches the server order. Changing shipping or discounts updates it. Wallet cancellation leaves checkout available, and pending payments block another charge. BrandingCS-5Color and logo look right in Checkout preview on both desktop and mobile layouts.

5. Security

Key on the serverSE-1Your merchant checkout key or organization 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 Tapaya's script and frame origins, and 3D Secure challenges still work under it.

6. Sandbox configuration

Sandbox APIPR-1TAPAYA_CHECKOUT_API_URL points at https://api.sandbox.tapaya.com. Sandbox keyPR-2The integration uses a sandbox merchant checkout key or organization Secret key, loaded from server configuration. Reconciliation jobPR-3The job that retrieves unresolved sessions is scheduled in your test environment.

7. Production readiness

Merchant readinessLV-1The live merchant completed onboarding with online payments, received processor approval, and has a configured payment gateway. The merchant is Ready in Checkout settings. Live credentialsLV-2The server uses production credentials and https://api.tapaya.com. SDK integrations set TAPAYA_ENVIRONMENT=production. Sandbox keys and test cards are not used for live payments. Live walletsLV-3Apple Pay shop domains are active. Live Google Pay has a configured merchant ID. Supported wallets complete a payment and recover after cancellation. Live reconciliationLV-4Production return URLs, server verification, fulfillment, and the reconciliation job use production configuration.