This request requires a valid access token. See Authentication to obtain one with
POST /v1/auth/token before you continue.Batches
A batch moves through the same settlement stages a transaction reports: queued (SUBMITTED), in progress at the acquirer (SETTLING), and settled (SETTLED). While a batch is open, its transactions can still be voided; once it closes, only a referenced or standalone refund can return funds. See Payment lifecycle for the full state diagram.
Settlement webhooks
Subscribe tosettlement.settled, settlement.rejected, and settlement.discarded to track batch outcomes without polling. Each event’s data.batch identifies the batch; correlate it with your transactions’ own status changes. See Webhook event types for the full payload shape.
Retrieve a settlement batch
Look up a batch’s status and totals by its reference when you need an authoritative read (for example, to reconcile asettlement.rejected event). This lookup is documented in the API reference.
Reconciliation tips
- Reconcile by batch reference, not by settlement date alone — a batch can span or shift across calendar days depending on cutoff timing.
- Treat
settlement.rejectedandsettlement.discardedas exceptions requiring investigation, not just log entries — funds you expected to settle didn’t. - Cross-check your own transaction totals against the batch totals returned above; a mismatch is worth investigating before you close your books for the period.
- Remember that a transaction’s
amounton a loyalty-split sale reflects only the card residual, not the gross order total — reconcile against the right figure.
Go-live notes
- Register a webhook endpoint before you go live so settlement outcomes reach you without polling.
- Build an alert for
settlement.rejected/settlement.discarded— these need a human, not just a log line. - Review the full go-live checklist.
Next steps
Retrieve a settlement batch
Full reference for the batch-status lookup.
Webhooks
Set up your endpoint and verify signatures.