Every Treasury money movement, a payout, a collection, or a transfer, is a transaction that follows the same lifecycle. This is the shared reference for the statuses, the flow, and how to track a transaction. The method pages (Pay via ACH, Collect via ACH, Transfer funds, and the wire and BOOK pages) link here instead of repeating it.

The flow

You submit a transaction, we validate it, and it moves through processing to a terminal state. You're notified of each change by webhook.

sequenceDiagram
    participant You as Your application
    participant PCE
    participant Rail as Rail / counterparty
    You->>PCE: POST /transaction (unique externalId)
    PCE->>PCE: Validate request
    PCE-->>You: status SCHEDULED
    PCE->>Rail: Process over the method's rail, PROCESSING
    Rail-->>PCE: Settlement result
    PCE-->>You: Webhook, COMPLETED (or PENDING / FAILED / CANCELLED)

How long the middle takes depends on the method. Every Treasury money movement follows this lifecycle. Pick a method below for its scenarios, fields, and rail-specific detail.

Payment methods

Pay out, to a third party

Collect, you pull from a payer (with authorization)

Get paid in, a payer sends to you (funding instructions)

Transfer your own money

Statuses

The exact reasons depend on the method (for example, ACH return codes apply to ACH, not BOOK). For the specific codes and how to resolve each, see Error Codes and Messages.

Good-funds period (inbound ACH)

An ACH debit can be returned by the payer's bank even after it settles, for insufficient funds, a closed account, or an unauthorized debit. To cover that risk, PCE holds inbound funds for a good-funds period (also called the realization interval) before treating them as final.

• During the window, the transaction stays in PROCESSING.
• Once the interval passes without a return, funds are realized and the transaction moves to COMPLETED.
• If the bank returns the debit within the window, or the interval lapses without realization, it moves to FAILED.

Don't treat inbound funds as spendable until the transaction is COMPLETED. This applies to collections and funding pulls; it does not apply to payouts (money leaving) or instant BOOK transfers.

Update a scheduled transaction

You can modify a transaction that is still in SCHEDULED or PENDING status, for example to change the amount before the rail picks it up. Transactions already in PROCESSING or a terminal state cannot be updated.

Make POST request to /v1/customer/id/{customerId}/transaction/id/{transactionId} (or externalId for either path segment).

Request

POST /v1/customer/id/48201/transaction/id/230001518
PromiseMode: NEVER

{
  "amount": "500.50"
}

Response

204 No Content — the update was accepted. Retrieve the transaction to confirm the new amount and status.

Only certain fields can be updated, and only while the transaction is still SCHEDULED or PENDING. If an update is not allowed, the API returns 400 with a reason code.

Track a transaction

Two ways, no polling required:

1. GET /v1/customer/id/{id}/transaction/id/{id} (or externalId), retrieve the current state.
2. Webhooks, subscribe to transaction events and react to each status change.

To retrieve many transactions at once, by account, date range, method, or status, use Find & list transactions rather than fetching each ID individually. That page also covers listing ACH returns.

A webhook wraps the transaction resource in payload[], the same fields you'd get from a GET. ACH events are transaction.ach.create (on create) and transaction.ach.update (on each status change); wire is transaction.wire.*.

{
  "id": 65817044,
  "eventType": "transaction.ach.update",
  "eventTimeStamp": "06/30/2026 09:40:55",
  "eventId": "0001709618091430044",
  "eventCreated": 1782810724000,
  "payload": [
    {
      "resourceName": "transaction",
      "url": "/v1/customer/id/4225975/transaction/id/230492021",
      "id": 230492021,
      "externalId": "your-ref-001",
      "status": "COMPLETED",
      "statusDate": "06/30/2026 09:40:55",
      "amount": 300,
      "method": "ACH",
      "statusReason": "Processed By System"
    }
  ]
}

For the full event catalog and payloads, see Webhook Event Types. For every transaction, store the returned id and your externalId, you'll need them for tracking, reconciliation, and follow-up actions.

Update a transaction

You can change a transaction only while it's still SCHEDULED, before it moves to PROCESSING. Once it's picked up for processing it can no longer be edited; create a new transaction instead (or, for a completed payout, a refund).

Send a POST to /v1/customer/id/{id}/transaction/id/{id} (or /externalId/{externalId}) with only the fields you want to change. This is the same method-agnostic action for every rail. Typical edits are the amount, scheduleDate, or purpose; the source and destination can't be changed, cancel and create a new transaction to move different money.

Request (reschedule and adjust the amount)

POST /v1/customer/id/4225975/transaction/id/230492021

{
  "amount": "250.00",
  "scheduleDate": "07/02/2026"
}

Response

204 No Content. Retrieve the transaction with GET /v1/customer/id/{id}/transaction/id/{id} or watch for the transaction.<method>.update webhook to confirm the change.

Idempotency

For Treasury, PCE uses the request-body externalId as the idempotency key; there's no separate header. Send a unique externalId per transaction; retrying with the same value never creates a duplicate.

Recurring transactions

A recurring transaction is a schedule that generates transactions automatically on each due date. Each generated transaction is a normal Treasury transaction and follows this lifecycle. The schedule has its own separate statuses (ACTIVE, PAUSED, CANCELLED, COMPLETED), which are not the transaction statuses above, see Recurring transactions.

See also

• Pay via ACH, Collect via ACH, Transfer funds, the method pages that use this lifecycle
• Recurring transactions, schedule money movements to run automatically
• Webhook Event Types, the full event catalog
• Processing cut-off and status change times, cut-offs and expected status timing per rail
• Error Codes and Messages, reason and return codes