v1.0.5Changelog
💡
How to read these

Steps are numbered in call order. Click any endpoint to jump to its parameters, schema and examples in the API Reference. Adjust account IDs, RRNs and amounts for your integration — sandbox values are synthetic.

ATM Cash Withdrawal

The core ATM debit flow for card-present, PIN-verified transactions.

1

Account Lookup

Resolve the card PAN + institution to the cardholder's accounts. POST /accounts

2

Balance Inquiry (optional)

Check the available balance before dispensing. POST /accounts/balance

3

Cash Withdrawal

Post the debit (type: CASHWITHDRAWAL); surcharge via amount.accessFee. POST /transactions/debits

4

Debit Reversal (if needed)

If the ATM cannot dispense, reverse using a new RRN and the original authId. POST /transactions/debits/reverse

Cash & Check Deposit

Covers both CASHDEPOSIT and CHECKDEPOSIT (with check detail items).

1

Account Lookup

Resolve the target account. POST /accounts

2

Deposit

Post the credit — cash for cash, check.checkDetails[] for checks. POST /transactions/credits

3

Credit Reversal (if needed)

Reverse a mis-posted deposit with a new RRN. POST /transactions/credits/reverse

Account-to-Account Transfer

Intra-institution fund transfer. Note the transfer response returns balances as an object (source + beneficiary), not a flat array.

1

Account Lookup (both accounts)

Resolve the source and destination account IDs. POST /accounts

2

Transfer

Move funds from paymentInstrument to beneficiaryInstrument. POST /transactions/transfers

3

Transfer Reversal (if needed)

Reverse with a new RRN referencing the original. POST /transactions/transfers/reverse

Cardless Withdrawal

Mobile-initiated cash pickup — no physical card. The account is identified by account.id only.

1

Generate token (mobile app)

The mobile channel creates a QR / NFC token bound to the account and amount.

2

Scan at ATM

The cardholder presents the token at the ATM to start the withdrawal.

3

Cardless Withdrawal

Post the withdrawal (type: CARDLESSWITHDRAWAL) — no card.pan. POST /transactions/cardless

Common Patterns

RRN uniqueness

Every transaction requires a unique 12-digit Retrieval Reference Number (transaction.rrn). Use a consistent format — e.g. YYMMDD###### where the last 6 digits are a per-day sequence counter.

Reversal RRNs

Reversals are separate transactions and need a new RRN, referencing the original via reverseInfo.authId (from the original response's status.authId). The one exception is a 504 timeout retry — reuse the same RRN to avoid duplicate posting.

Always look up before you transact

Account Lookup resolves a card PAN to an account.id. All financial transactions use that account.id, not the raw card number.

Check responseCode, not just HTTP status

A 200 OK does not guarantee success — always check status.responseCode ("000" = approved). See the full list on the Error Handling page.