---
updatedAt: 2026-09-16T17:21:22.000Z
agentTools:
  projectIndex: https://docs.staxpayments.com/llms.txt
---

# 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.

<Callout icon="📘" theme="info">
  ###

  Looking for the plain-language timelines? Merchants: [When Will I Get My Deposit?](/docs/funding-and-deposit-timelines). Partners: [Sub-Merchant Funding](/docs/sub-merchant-funding).
</Callout>

## 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.                         |

<Callout icon="📘" theme="info">
  ###

  A payment is only truly **funded** once `settled_at` is populated. Build reconciliation logic around `settled_at`, not `success`.
</Callout>

## 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](/docs/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.

<Callout icon="📘" theme="info">
  ###

  Running **Simulate Settlements** fires the `update_transaction_settled` webhook for the simulated transactions — useful for end-to-end testing your funding logic.
</Callout>

## 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](/docs/bank-ach-transactions).

***

## Related

* [ACH Transactions (lifecycle, returns & clawbacks)](/docs/bank-ach-transactions)
* [Setting Up Your Webhooks](/docs/setting-up-your-webhooks)
* [When Will I Get My Deposit? (for merchants)](/docs/funding-and-deposit-timelines)
* [Sub-Merchant Funding (for partners)](/docs/sub-merchant-funding)

<br />