Test mode vs live mode

2 min read

Quick answer #

Pay@ Gateway provides two completely separate environments: test mode (also called sandbox) for building and testing your integration, and live mode for processing real customer payments. Test mode uses fake card numbers, doesn’t move real money, and is available immediately when you sign up. Live mode activates once your account is verified. The two environments use different API keys, so you can’t accidentally process a real payment in test mode or a test payment in live mode.

When to use each #

Test mode (sandbox) #

Use test mode whenever you’re:

Building a new integration with Pay@ Gateway
Testing changes to your existing checkout flow
Demoing your site to a client or stakeholder
Reproducing a transaction issue without spending real money
Training a new developer on your team

Test mode is identical to live mode in every way that matters for integration work — same API endpoints, same response formats, same webhook payloads — except no actual money moves and no real cards are involved.

Live mode (production) #

Switch to live mode when:

Your integration is built and tested
Your account is verified (FICA complete)
You’re ready to accept real customer payments

Once live, you can keep test mode available for ongoing development — they coexist on the same merchant account.

How to tell which mode you’re in #

Three visual cues confirm the current mode:

[PH-019]

Always check the mode indicator before testing or making changes. The number of merchants who’ve accidentally processed a real customer payment while thinking they were in test mode is small but non-zero — the dashboard is designed to make this very difficult, but worth being deliberate about.

API keys — never mix them #

Each mode has its own pair of API keys:

Test mode: keys start with pk_test_ (public) and sk_test_ (secret)
Live mode: keys start with pk_live_ and sk_live_

If you use a test key in a live integration, transactions will fail with an “invalid environment” error. If you use a live key in your test code, real customers might get charged.

Best practice: store live keys as environment variables on your production server only. Never commit live keys to source control. Never email or share live keys outside your team.

Test cards #

In test mode, Pay@ Gateway provides a set of test card numbers covering the common scenarios:

Successful card transaction
Declined for insufficient funds
Declined for fraud check
3D Secure challenge that succeeds
3D Secure challenge that fails
Expired card
Invalid CVV

See Test cards reference — Article 15 — for the full list.

Switching from test to live #

When you’re ready to go live, see Switching from sandbox to live — Article 11. Key things to remember:

Replace your test API keys with live keys in production code
Verify the live keys work with one small real transaction before promoting to all customers
Keep test mode active in parallel for ongoing development

Common test mode mistakes #

A few things that trip up new integrators:

Mixing keys in the same request — using a test public key with a live secret key (or vice versa) fails. Both keys in a single API call must be from the same mode.
Webhooks pointing to the wrong environment — your dev/staging webhook URL and your production webhook URL need to be configured separately. Test events fire to the dev URL; live events to production.
Test transactions affecting reports — they don’t. Test transactions are isolated from your live reporting completely.
Test API rate limits — test mode has the same rate limits as live mode. If you’re running automated tests, account for this.