---
id: going-live
title: Going-live checklist
summary: What to have in place before the first live charge, and what we have not yet verified in live.
faces: ["public", "agent"]
section: shared
group: Go live
slug: going-live
order: 70
---
# 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](/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](/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](/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](/js/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](/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.