Tracking Settlement & Funding
Use the transaction object, funding endpoints, webhooks, and the Deposit Reporting API to know exactly where a payment is in the settlement and funding lifecycle — and how to test it in the sandbox.
A payment moves through several stages before it becomes a deposit: authorization → batching → settlement → net funding → payout via ACH. You don't have to guess where a payment is — the transaction object tells you, and webhooks notify you when its status changes.
Looking for the plain-language timelines? Merchants: When Will I Get My Deposit?. Partners: Sub-Merchant Funding.
Read the funding state from the transaction
| Field | What it tells you |
|---|---|
success | The transaction passed initial validation. For ACH, true does not mean the funds have cleared. |
is_settling | The transaction has been batched and is moving through settlement. |
settled_at | The datetime the transaction settled. Populated once funds are confirmed; null until then. |
is_voided | The transaction was reversed. For ACH, this indicates a rejection/return. |
method | card, bank (ACH), etc. — determines which funding timeline applies. |
child_transactions[] | Related records, such as the void created when an ACH payment is returned. |
A payment is only truly funded once
settled_atis populated. Build reconciliation logic aroundsettled_at, notsuccess.
Get funding detail for a transaction
To see how a specific transaction was (or will be) funded, use the Get a Transaction's Funding Instructions resource in the Stax API.
Reconcile deposits with the Deposit Reporting API
To connect deposits back to the transactions that make them up — for example, to reconcile payouts inside your own software — use the Deposit Reporting API. It's the programmatic equivalent of the Deposit Report in Stax Pay.
Get notified when a transaction settles
Subscribe to the update_transaction_settled webhook to be notified the moment a transaction settles or fails, instead of polling. The payload includes the full transaction object and an is_transaction_settled boolean.
See Setting Up Your Webhooks to configure it.
Test funding in the sandbox
Settlement doesn't happen automatically in the sandbox, so there's no deposit data until you generate it. Use the Simulate Settlements feature (Stax Pay → Reports → Deposit Report) to mock the settlement process against your sandbox transactions and create deposit-reporting data to build against.
Running Simulate Settlements fires the
update_transaction_settledwebhook for the simulated transactions — useful for end-to-end testing your funding logic.
Card batch and funding timing
For most merchants, card transactions follow the same general batch and funding flow.
The default card batch time is 8:00 p.m. ET. Batch time can be adjusted upon request, but changes may impact funding timing.
Card funding typically occurs between 2:00–5:00 p.m. ET, depending on the merchant's bank and funding timeline, such as a 2-day or 5-day timeline.
ACH settles differently
ACH transactions don't clear instantly: they're batched daily, funded in good faith before final clearing, and can be returned or clawed back after funding. When an ACH payment is returned, a void appears in child_transactions[], and the void's meta carries achStatus and achDescription (which includes the NACHA reason code).
For the complete ACH lifecycle, settlement states, and return/clawback handling, see ACH Transactions.
Related
- ACH Transactions (lifecycle, returns & clawbacks)
- Setting Up Your Webhooks
- When Will I Get My Deposit? (for merchants)
- Sub-Merchant Funding (for partners)
Updated about 1 month ago