---
id: testing
title: Testing
summary: What puts a checkout in test mode, what test mode does and does not prove, and where the cards are.
faces: ["public", "agent"]
section: shared
group: Test
slug: testing
order: 52
next: ["test-cards"]
---
# Testing

Test mode takes real-looking payments that charge nobody. You do not switch it on; it is what you get
until all three of the things below are true.

## What makes a payment live

A payment is live only when **all three** hold:

1. Live payments are switched on for the merchant.
2. The integration's mode is `auto` rather than `test`.
3. The key allows live.

If any one of them is false, the payment is a test payment. That is the whole rule, and it is worth knowing
in that shape because it tells you where to look when something is in the wrong mode: there are only three
places it can be.

**`auto` means "follow the merchant's live toggle"** — an integration on `auto` is live when the merchant is
live and test while they are not. An integration pinned to `test` stays in test whatever the toggle says,
which is what you want for a staging integration that should never take money by accident.

A key can allow both modes, test only, or live only. A test-only key forces test whatever else is true. A
live-only key is the awkward one: if everything else resolves to test, the request is refused with
`key_live_only` rather than quietly taking a test payment, and in a browser the shopper sees a checkout that
is not ready rather than a message they could act on.

## What test mode gives you

The card form is simulated, so no card details are handled and nothing is charged. The card number you type
decides the outcome: an approval, a soft decline that lets the shopper try again, a hard decline that ends
the session, a 3-D Secure challenge, or a failed authentication. The full list is on
[Test cards](/js/test-cards).

Everything else is real. The session is a real session with a real thirty-minute life, the API answers the
same refusals with the same codes, webhooks are delivered, and the hold and capture flow behaves as it will
in live.

## What test mode does not prove

Three things, and it is better to know them now than on launch day.

Live card entry loads further card-security sources that test mode does not, so a strict
`Content-Security-Policy` verified in test is not yet verified for live — [Security and CSP](/security-and-csp)
says which rows have been observed and which have not.

The 3-D Secure provider is simulated, so a challenge in test tells you your page handles the challenge
correctly, not how a particular bank's real challenge will look.

Live acquiring must be configured before a live payment can be routed at all, and an incomplete live
acquiring profile shows up as a checkout that is not ready rather than as a decline.