Going live

Swapping your keys and dropping the test- prefix is the smallest part of going live. Test mode is deliberately permissive: it seeds payment methods you may not own, forces the checkout to a fixed method list, skips settlement entirely, and applies no rate limit. An integration that passes every sandbox test can still fail on its first live request.

Work through the checklist below before you point real customers at Kashier.

1. Account, credentials, and hosts

• Activate the account for live mode. Every account starts as a test account. Until Kashier has onboarded and activated yours, live mode will not accept writes. Skip it and every write request to a live host is rejected with Merchant <MID> is not live. — the message names the account status, not your credentials, so it is easy to misread as an auth failure.

• Swap in your live keys. You have four keys in total: a Payment API Key and a Secret Key for test, and the same pair for live. Keys are mode-scoped and cannot cross over. See API keys. Skip it and a test key against a live host fails authentication outright, and a test Payment API Key produces an "invalid hash" error even when your hashing formula is correct.

• Swap every base URL, using the table below. Grep your codebase for test- afterwards — a single missed host silently keeps part of your flow in the sandbox.

The checkout host is the same in both modes — the mode travels on the sessionUrl as a mode query parameter rather than in the hostname. If you load checkout assets from any other host, confirm its live equivalent with Kashier before you switch.

• Update your IP allow-list before your egress IP changes. The allow-list is opt-in — an empty list allows every IP — but once it has at least one entry, only those IPs may use your Secret Key. Manage it from API keys. Skip it and every Secret Key call from the new server is rejected with 403 Unauthorized IP address, which looks nothing like an IP problem unless you read the message. This is one of the more common causes of a go-live-day outage. Dashboard session callers are not IP-checked, so the dashboard will keep working while your server does not.

• Check the role behind the live Secret Key. A Secret Key authenticates the request; what it may do is bounded by the role assigned to the user it belongs to (role-based access control, or RBAC — each route checks the caller's role for a named privilege before it runs). Settlement reads, for example, require balance.all.view_balance and settlement exports require balance.all.export_balance. Skip it and a perfectly valid key is rejected on individual routes. See API keys and error responses.

• Point signature verification at the live Payment API Key. The redirect signature after 3-D Secure and the webhook signature are both computed with the Payment API Key for that mode. Skip it and every live redirect and webhook fails verification and you reject genuine payments. See hashing and signatures and signature verification.

2. Payment methods

This is the section that catches most integrations, because test mode is misleading in two different directions at once.

• Confirm every method you offer is actually enabled on your live account. Which methods a merchant has is derived from that merchant's active payment configuration in the current mode. In live mode the list starts empty and is filled only from real configuration; in test mode Kashier seeds a default set — card, wallet, installments, InstaPay, and Basata — regardless of what you own. Skip it and a method your sandbox happily displayed is simply absent at live checkout.

• Test-only methods you could never have exercised. Outside live mode, hosted checkout and the embedded iframe ignore allowedMethods entirely and force the list to card and wallet. bank_installments, fawry, and the rest cannot be exercised in the sandbox at all — so your first real bank-installment or kiosk payment is also your first test of that code path. Plan one live transaction per method rather than trusting the sandbox: use the smallest amount the method accepts, run it on your own card or wallet, and refund it straight away so the verification costs you only the transaction fee. Do this before you announce the method to customers, not after. See payment sessions.

• Handle declines you never saw. Test outcomes are driven by the CVV and expiry date you submit, so you only ever saw the handful of results listed in test cards. Live traffic reaches real acquirers and returns the full code set — including non-deterministic outcomes that are neither paid nor failed. Make sure your code reads the response code rather than branching on success/failure alone. See payment reason codes and order reconciliation.

3. Capabilities enabled for your account

• Confirm every capability you depend on is switched on. Kashier gates many capabilities behind per-merchant flags, and a brand-new merchant has exactly three enabled: multiple balance accounts, payment links, and customers. Everything else — bulk charge, instant settlement, payment fees, branches, POS auto-settlement, connected accounts, and more — is off until Kashier enables it for you, and you cannot toggle a flag yourself. Skip it and the call fails even though your keys, path, and payload are all correct. There is no single status code for it: some gates reject a disabled capability with 400, others with 401 Unauthorized, so don't build a check around one of them. See capabilities are enabled per merchant.

4. Webhooks

• Create a live-mode webhook. Webhooks are scoped to a mode: a webhook with mode set to test only ever receives test events. Create a second webhook for live rather than flipping your existing one back and forth, so your staging listener keeps working. See manage webhooks. Skip it and live payments complete with no notification reaching your server at all.

• Point the live webhook at a public HTTPS URL. localhost, loopback, link-local, and private addresses are rejected — a tunnel URL that worked during development may not be what you want in production.

• Verify live deliveries with the live Payment API Key. Transaction events are signed with the Payment API Key for the webhook's mode.

• Check your subscribed event list. Matching is exact, so a webhook subscribed to refund is not delivered a partial_refund. Review the subscription you create for live, rather than assuming it mirrors test.

5. Behaviour that only exists on live

• Settlement windows. Settlement windows and batches are produced by the live settlement pipeline only — in test mode there are none, so any reconciliation code that reads them has never run against real data. Exercise it after your first live captures. See settlement.

• Rate limits. There is no rate limit on the test environment. On live, checkout requests are limited to 1000 requests per minute per IP address — so services sharing one outbound IP or sitting behind a NAT share a single bucket. Kashier has not published the reset behaviour or response shape, so handle failures gracefully rather than coding against a specific error format. See rate limits.

• Real money. Live refunds, voids, and payouts move real funds. Make sure the operational paths — refunds, void — are wired up and permissioned before you need them under pressure, not after.

6. After the first live payment

Run one small real transaction end to end before you open the flow to customers, and confirm each link in the chain rather than only the checkout result:

• The order reaches the expected status — check it with order reconciliation, not only the browser redirect.
• The redirect signature verified against your live Payment API Key.
• Your live webhook received the event and its signature verified.
• The refund path works, by refunding that transaction.
• The transaction appears in a settlement window once one closes.

What does not change

Request and response shapes, the hashing formula, error envelopes, and endpoint paths are identical in both modes. Test mode also stays available after you go live — the two modes are fully isolated and one can never touch the other's objects, so you can keep developing against test with live traffic running.