Test cards and testing

You can use the following cards to test your integration with Kashier.

Card numbers

Card type	Card number	Cardholder name
MasterCard	`5111111111111118`	Michel Doe
MasterCard	`5123456789012346`	John Doe
MasterCard	`5123450000000008` (3D-Secure enrolled) — use this one in the quick start	John Doe
Visa	`4012000033330026`	John Doe
Visa	`4508750015741019` (3D-Secure enrolled)	John Doe

CSC/CVV response codes

CVV	Response GW code
100	`MATCH`
101	`NOT_PROCESSED`
102	`NO_MATCH`

Expiry date response codes

These are outcome triggers, not real expiry dates

In test mode the expiry date you submit chooses the result. These values are matched literally — they are not read as dates, and none of them has "expired". 06/25 still returns APPROVED, and 04/27 returns EXPIRED_CARD even though it is a future date. Send the value for the outcome you want to exercise; any expiry not in this table is not a defined trigger.

Expiry date	Transaction response code
06/25	`APPROVED`
05/25	`DECLINED`
04/27	`EXPIRED_CARD`
08/28	`TIMED_OUT`
01/37	`ACQUIRER_SYSTEM_ERROR`
02/37	`UNSPECIFIED_FAILURE`
05/37	`UNKNOWN`

Telling the failure codes apart

DECLINED, EXPIRED_CARD, and TIMED_OUT describe the card or the attempt. The next two do not — they describe Kashier's side of the call, and neither is a judgement about the customer's card:

Code	What actually happened	What to do
`ACQUIRER_SYSTEM_ERROR`	The acquirer errored while processing the transaction. An infrastructure fault upstream of the card.	Treat the attempt as failed. Do not tell the customer their card was declined or ask for a different one — the same card may work on a retry.
`UNSPECIFIED_FAILURE`	The gateway failed the transaction without reporting a reason. No further detail exists.	Same handling as above. Log the full response; it is the only thing Kashier support can work from.

Both are terminal for that attempt, which is what separates them from UNKNOWN below. Branch on the response code rather than on a success/failure boolean, so these two never reach the customer as "your card was declined".

UNKNOWN is neither paid nor failed

UNKNOWN means the provider gave no deterministic answer — a timeout, a busy gateway, or an order it cannot find. The transaction rolls up to order status INITIATED, not FAILED. Never treat it as paid or as declined, and never tell a customer to retry on the strength of it: a retry on a charge that did land double-charges them. Re-read the order with order reconciliation before you do anything else.

Reading the reconciliation verdict

The field is spelled `reconcilation` — one `i`

The API returns reconcilation, not reconciliation. The misspelling is in the API itself, so it is the spelling your code has to match. Reading response.reconcilation works; reading the correctly-spelled response.reconciliation returns undefined on every transaction and fails silently — you get no error, just a field that is never there.

Order reconciliation returns a per-transaction reconcilation field. It is not a payment outcome. It says whether Kashier has reconciled that transaction against the provider, not whether money moved:

`reconcilation`	What it means
`NA`	The default — not yet reconciled. Carries no information about the payment.
`OK`	Reconciled and consistent. A reconciled failure is also `OK`.
`Failed`	Reconciliation ran but the two sides did not match. Investigate.
`Not_Exists`	The counterpart record was not found on the side being reconciled.

Never decide a retry from the reconciliation verdict alone

OK does not mean the charge succeeded — it means the record is consistent, which is equally true of a reconciled FAILURE. Branch on the transaction's own status together with its reconcilation:

status: SUCCESS and reconcilation: OK — the charge landed. Do not retry.
status: FAILURE and reconcilation: OK — the charge is confirmed failed. Retrying is safe.
reconcilation: NA — nothing has been reconciled yet. Do not act on it at all; poll again, and escalate to Kashier support rather than re-charging the customer.
Failed or Not_Exists — treat the outcome as undetermined and escalate. Do not retry on the assumption that nothing landed.

Mobile e-wallet

Wallet type	Mobile number
Vodafone	`01001001001`

Unlike cards, a wallet test payment has no trigger table — the outcome comes from whichever wallet provider is wired to your test account, and Kashier runs two different implementations behind the same request shape. If this number does not behave the way you expect, check the response code before assuming the number is wrong:

k_5 — "the mobile number is not registered on any provider". This is terminal, and Kashier does not schedule its automatic reconciliation for that order, so it never resolves on its own. Do not keep polling it. It usually means your test account is wired to a provider this number is not registered with; ask Kashier support which wallet provider your account uses.
Anything else — see wallet payments for the full flow, including the PENDING reconcile result that means "not finished yet" rather than "failed".