Environments and API keys

Your account has two environments, TEST and LIVE, and they share nothing. A test payment is not a live payment with a flag on it: it has its own transactions, its own payer directory, and its own totals. Nothing you do in TEST can appear in a live report, and nothing in LIVE can be read with a test credential.

Both are served from the same base URL. The environment is not in the path, and it is not a parameter — it is a property of the key you authenticate with.

Every authenticated call carries your key in the X-Api-Key header:

Four things are worth knowing about it:

• Its environment is fixed at creation. A key cannot be moved between TEST and LIVE. When you are ready to go live you issue a second key; the first keeps working against TEST.
• The list shows only its first 16 characters. That is enough for you to recognise a key and not enough for anyone to use it — and closing the dialog does not lose the value: you can reveal one of your own keys in full again from the dashboard. Only keys minted before that became possible cannot be re-shown.
• It identifies you, it does not authorize the request. On its own it is refused: the request also has to be signed. See Signing requests.
• You can hold several. One per service that calls us is the usual arrangement, because then revoking one does not stop the others.

There is no environment parameter on any data-plane endpoint, and sending one is an error rather than a hint. The reads are scoped to the calling key's environment and the writes execute in it:

• GET /v1/transactions with a test key returns test transactions. There is no filter that would widen it.
• GET /v1/customers with a test key returns the payers of test payments — so your test data never mixes real contact details into a list you are experimenting on.
• Responses echo the environment back in an environment field, which is the value to assert on in your own tests.

The two endpoints under /v1/merchant are the exception, and only because their answer is the same either way: your business and its verification verdict do not differ between environments. The profile still echoes the asking key's environment.

Revoking a key stops it immediately and cannot be undone. Because a key is fixed to its environment and shown only once, the rotation is always the same three steps: issue the new key, deploy it, revoke the old one — in that order, so there is no window where your server holds nothing that works.

The signing secret and encryption key are a different matter. They are one pair per account, they are not self-served, and rotating them stops every client that is still signing with the old secret at the same instant. Plan that one; do not perform it during a sale.