Every rail, one payment order.
ACH, Same-Day ACH, RTP, wire, book transfer and USDC — moved through a single object on a strict state machine. You describe the money once; the platform routes it, holds it on the ledger, drives it to settlement, and tells you the moment anything changes.
One object for money in motion.
A PaymentOrder is the single verb of the platform. Direction, amount, rail, counterparty, and the ledger account it posts against — all declared up front. Amounts are always integer cents; a rail is never a bare string; a direction is Credit or Debit and nothing else. Once the order is submitted, its business fields freeze: what you approved is what settles.
Declared once
Amount in cents, direction, rail, counterparty and ledger account in one request. No rail-specific payload to relearn per network — the shape is the same for ACH and for USDC.
Immutable at submission
Business fields are frozen the moment an order is submitted. You cannot quietly change an amount or a counterparty on an order already in flight — an edit is a new order, with its own approval.
One state machine
Every order moves through the same transitions, and every transition is either legal or refused. There is no back door that leaves an order in a state the books can't explain.
Pick the rail per payment, not per integration.
Each network has its own timing, cost and failure modes. The platform models all of them behind the one order, so choosing Same-Day ACH over standard, or RTP over wire, is a field — not a second integration.
The workhorse.
Credits and debits over the ACH network, standard or Same-Day. Low cost, batch settlement, and a full return model — the platform maps every NACHA return code (R01 insufficient funds, R02 account closed, R03 no account, and the rest) to a typed status your webhook can branch on.
- Standard and Same-Day windows
- Typed return-code handling, not raw strings
- Company-entry and counterparty validation before submission
Instant, irrevocable, 24/7.
Real-time credits that clear in seconds and never reverse. The platform treats irrevocability as a first-class property: an RTP credit is gated by the same approval policy and balance checks as any rail, because there is no clawback once it lands.
- Seconds to settle, any hour of any day
- Approval and balance gates before send — no take-backs
- Ideal for payouts a recipient is waiting on
High value, same day.
Domestic wires for the big, time-critical movements — an auction cutoff, a real-estate close. Wires carry the strictest controls: dual approval above a per-tenant threshold, and a cutoff the platform enforces rather than discovers after the fact.
- Dual-approval by default on high-value movement
- Cutoff-aware — an order that can't make the window says so
Money that never leaves the platform.
A move between two accounts inside DigitalTreasury settles instantly on the ledger with no bank rail in the middle — a tenant sweeping float to an operating account, capital advanced against collateral the ledger already holds. Free, immediate, and fully double-entry.
- Instant settlement, no network cost
- The same posting rules as any external payment
Stablecoin, same envelope.
USDC settlement behind the identical payment order — the ledger doesn't care that the rail is a blockchain. On-chain movement is modeled with the same statuses, the same holds and the same reconciliation as ACH, so treasury sees one book, not two.
- One payment-order shape across fiat and stablecoin
- Posted to the same double-entry ledger, to the cent
A payment you can always explain.
Every order walks a defined path. Nothing skips a state; nothing lands somewhere the ledger can't account for. The status you read is the status that is true.
Draft → Submitted
Created and validated, then submitted — the point at which business fields freeze and approval policy applies. A submission that violates a control is refused here, before any money is reserved.
Pending → Processing
Approved and handed to the rail. A pending hold posts to the ledger at this point, so available balance reflects money already committed — not just money already gone.
Completed · Failed · Returned · Cancelled
Terminal states, each with a webhook. Completion posts the settlement; a return or failure reverses the hold and carries the reason; a cancellation is only legal while the order still permits it.
Create a payment order
POST /v1/payment-orders X-API-Key: dt_live_... Idempotency-Key: inv_8842_pay { "externalId": "inv_8842", "direction": "Credit", "rail": "Rtp", "amountCents": 250000, "counterpartyName": "Acme Carrier", "ledgerAccountName": "Carrier Payables" }
Watch it settle
// signed webhook → your endpoint // X-DigitalTreasury-Signature: 9f86… { "type": "payment_order.completed", "data": { "id": "po_9f2c…", "status": "Completed", "rail": "Rtp", "amountCents": 250000 } }
The details that decide whether money is safe.
Idempotent writes
Every create accepts an Idempotency-Key. Retry a timed-out request with the same key and you get the same order back — never a second payment. A different body under a used key is a conflict, not a silent overwrite.
Approvals before the act
Per-tenant thresholds, dual approval above a configurable amount, and require-approval-for-all where trust money demands it. The gate is on the transition into the rail, so an unapproved order simply never moves.
Returns that carry meaning
An ACH return arrives as an inbound event, is matched to its order, reverses the ledger hold, and lands in a typed status with the return code — so "account closed" and "insufficient funds" are different branches in your code, not one generic failure.
Reconciled by construction
Because a hold posts at submission and settlement posts at completion, pending, posted and available balances always tie out. Reconciliation isn't a nightly job that might disagree — it's an invariant the ledger maintains.
Refusals are named
When a payment can't proceed, the reason is specific — a missing counterparty account, an unverified receiver, a tainted basis — never a shrug. The platform would rather block a payment than send a wrong one.
Delivery you can trust
Every status change writes to an outbox in the same transaction as the change, then delivers as an HMAC-signed webhook with retries. A crash between "it happened" and "we told you" loses nothing.
Move money you can account for.
Every rail, one order, on a ledger that always balances.
Request access → See the ledger →