Going-live checklist
Work through this before the first live charge. Each item names the code you will see if it is not done, so a failure in live is one you can recognise rather than one you have to diagnose.
The three that decide the mode #
Live payments are switched on for the merchant; the integration's mode is auto rather than test; and the
key allows live. All three, or the payment is a test payment. Testing has the rule in full.
A live-only key while anything else still resolves to test is refused with key_live_only, which a shopper
meets as a checkout that is not ready.
The configuration a live charge needs #
Live acquiring is complete. Active, with a BIN, a currency, a merchant category code, and a merchant ID
for 3-D Secure. Incomplete shows as acquiring_profile_incomplete, and the shopper sees a checkout that is
not ready rather than a decline.
Routing resolves to exactly one acquirer for the currency you charge in. Zero or several is
routing_unavailable, and it is configuration rather than a transient fault, so retrying does not help.
Your live page's origin is on the integration. The exact origin, scheme and host and port. A live page
on a domain the integration does not list is origin_not_allowed.
A currency resolves. Either passed in the call or set as the integration's default; a browser-created
session with neither is currency_required.
The things that are yours rather than ours #
The secret key is not in the page, the app or the repository. If it ever was, revoke it before investigating — Keys says why in that order.
The outcome is read on your server, from a session read, a payment read, or a webhook. Not from the browser. How it works says why.
Creates carry an idempotency key, a new one per logical create. After a refusal a new key is safe, because the refused request created nothing; a corrected body needs its own key. After a timeout, reuse the same key — that request may have created a session, and the key is what gives it back.
The decline paths have been exercised, not only the approval. A soft decline that lets the shopper retry and a hard decline that ends the session behave differently, and the difference is visible to your page. Test cards has a card for each.
What we have not verified in live #
Said plainly, because a checklist that only lists your work is not an honest one.
A strict Content-Security-Policy is verified for test mode in four browsers and is not yet verified for
live: live card entry loads further card-security sources than test mode does. If you send a strict policy,
expect to adjust it at the live cutover and watch the console on the first live payment.
Security and CSP marks every row with which modes it has been observed in.
The 3-D Secure provider in test is simulated. Your handling of a challenge is proven; a particular bank's real challenge is not.