Reconciliation closes a working period and returns transaction totals — the end-of-day operation that lets your POS compare its records against the terminal's before settlement.
The request
POST /reconciliation with the reconciliation type. A sale reconciliation closes the current period and returns totals; the terminal computes totals per payment brand and acquirer.
The response
ReconciliationResponse returns the period's transaction totals grouped by brand/acquirer: counts and amounts for debits (sales) and credits (refunds). Your POS should compare these against its own journal and surface any mismatch to the merchant — a discrepancy at reconciliation is far cheaper to investigate the same day than at settlement.
Operational guidance
- Run reconciliation at day close, after the last transaction and before shutting the lane down.
- Treat the totals as the terminal's statement of record for the period; store the response with your daily closing documents.
- A reconciliation during an in-flight transaction will be refused or queued — close out active operations first (the one-operation-at-a-time rule applies).
Note
Reconciliation is available on Local API and App-to-App. It is not part of the Cloud API operation set — Cloud-integrated estates reconcile through back-office reporting instead.
Related
- Session and login lifecycle — where day-open and day-close sit in the session flow.