Approving a card does not move money. It reserves it. Funds move when the transaction settles, and settlement happens in batches — a day's transactions sent to the processor together.
That is why is_settled is false on a transaction you just approved, and why your bank deposit does not match any single payment.
A transaction joins a batch when its settlement request reaches the processor. Until then batch_id is null.
A batch has no identifier until it exists. You cannot look up "today's batch" before transactions have been added to it, and a fresh sale with a null batch_id is normal rather than a fault.
Batches close on a schedule configured per merchant account. Once a batch closes, its transactions are submitted for funding and is_settled becomes true.
Most merchants never need this: the schedule handles it. Close a batch by hand when you need funds submitted before the next scheduled close, or when you are testing the settlement path.
Four fields are required:
| Field | Notes |
|---|---|
client_id | Whose batch to close |
processor | Tsys or Vericheck — case-sensitive, see below |
batch_type | Credit or Debit |
created_at | ISO 8601 timestamp of when the batch was created |
batch_id is optional, and leaving it out is not a no-op. Omitting it closes every open batch for that client. Send it when you mean one specific batch.
This catches almost everyone.
| Where | Spelling |
|---|---|
processor in a request body | Tsys, Vericheck |
integration as a report filter | TSYS, VERICHECK |
integrations on a transaction response | TSYS, VERICHECK |
Sending TSYS in the body of a batch close returns 400. It is the same processor spelled two ways depending on where the word appears, and the gateway does not normalize it.
Settlement is not instant. The processor funds the merchant account on its own schedule, typically one to two business days after a batch closes.
For ACH, closing a batch is also where returns start to become possible. A return can arrive days after settlement. See Accept an ACH payment.