Going live

The checklist to work through before your integration takes real customers’ money.

Work through this before the first real customer stands in front of the till.

Correctness

Amounts are whole tugrik

₮1,500 is 1500. Check every path that builds an amount — especially any code ported from an integration that used minor units. A ×100 error here is a customer charged a hundred times over.

The field is amountMNT

Uppercase MNT. amountMnt is rejected with 400 invalid request body. Verify against a live call, not against your own type definitions.

You store the transaction id at the moment of sale

Written to your own order record before you show the cashier a success screen. Without it a refund becomes a manual search.

The QR string is passed through unmodified

No trimming, no prefix stripping, no case changes. If your scanner appends a newline or a configured prefix, strip that in your code before sending.

Safety

Every charge carries an Idempotency-Key

Generated once per sale attempt and reused across every retry of that attempt. Confirm by forcing a timeout and checking the customer was charged once.

A timeout or 5xx is never treated as a decline

The charge may have committed. Retry idempotently or reconcile against GET /v1/transactions — never silently fail the sale, and never silently recharge.

409 is handled as 'already done', not as an error

qr token already used → verify before recharging. transaction already reversed → mark it refunded and show success.

Status is checked before parsing JSON

Only 422 returns JSON. Calling .json() on a 409 throws and turns a handled decline into an unhandled crash at the till.

Credentials are not in the client

Not in a shipped mobile binary, not in a browser bundle, not in git. One terminal per till, so a lost device is one rotation rather than a store-wide re-credential.

Cashier experience

Every 422 code maps to a message a cashier can act on

All ten of them, in Mongolian. Do not show the raw English error text and do not show a generic “declined” — the difference between “not enough balance” and “can’t be used today” decides what the customer does next.

Token errors offer Rescan, not failure

TOKEN_EXPIRED and TOKEN_INVALID are recoverable at the counter. Give the cashier a button.

401 tells staff to re-pair, not to retry

A dead credential cannot be retried into working.

Nothing blocks on the VAT receipt

It does not exist at the moment of sale and never will. If your receipt template has a slot for it, leave it blank or fill it in later.

Operations

You log the transaction id, status, and 422 code on every charge

Never log the QR string or the terminal password. The id is what support will ask for.

Retries back off exponentially with jitter

A tight retry loop against a shared rate limit turns one slow request into an outage.

Device clocks are synchronised

Skewed clocks produce confusing history windows and spurious token-age complaints.

Day boundaries are computed in Asia/Ulaanbaatar

Spend rules and daily limits reset at Mongolian midnight; the API returns UTC timestamps. Convert, do not assume.

The final rehearsal

Run this end to end on the real hardware, with a real card, before you open:

1. Charge ₮100

   201, vatStatus: "pending". Save the id.

2. Rescan the same code

   409 qr token already used. Your POS should offer to verify, not to charge again.

3. Replay the original request with the same Idempotency-Key

   201 with the same id. The customer was charged once.

4. Pull the balance up in the customer's pass

   ₮100 gone, once.

5. Wait a few minutes, then list transactions

   vatStatus: "issued" with a receipt number in vatReceiptID.

6. Reverse it

   204. Then reverse it again: 409, handled as success.

7. Check the pass and the status

   ₮100 returned. vatStatus moves to voided.

If all seven behave as described, your integration is sound.

Getting help

Email [e-mail] with the transaction id and the approximate time. That is enough for us to trace any payment end to end.