Payment operations, as an API.
Everything below ships in the platform today. Money is always integer cents, every movement is double-entry, and every tenant's data is isolated by construction.
Three products, one engine.
Payments →
Every rail — ACH, RTP, wire, book transfer, USDC — moved through one payment order on a strict state machine.
Ledgers →
Double-entry, append-only, integer cents. Holds at creation, settlement at completion, reconciled by construction.
Compliance & controls →
KYB, sanctions screening, dual approval, tenant isolation and a complete audit trail — enforced by the platform.
Everything that ships today.
Multi-rail payment orders
ACH, RTP, Wire, Book Transfer and USDC behind one payment-order model — a strict state machine where business fields freeze at submission and every transition is legal or refused.
Idempotency built in
Every write accepts an idempotency key. Retry a timeout without fear: the same key returns the same order, never a duplicate payment.
Double-entry ledger
Balanced, append-only, integer cents. Pending holds post at creation and settle on completion — pending, posted and available always reconcile.
Webhooks that arrive
Events write to an outbox in the same transaction as the change, then a dispatcher delivers with HMAC signatures and retries. A crash between write and send loses nothing.
Card issuing
Provider-agnostic issuing with spend controls, authorization holds on the ledger, and interchange revenue tracked per program.
Risk & approvals
Per-tenant risk thresholds, dual-approval above configurable amounts, require-approval-for-all for trust money, and an audit log on every admin action.
Account verification
Micro-deposit and instant verification flows before a counterparty can receive a dollar.
Multi-tenant by construction
Every tenant-scoped row carries its tenant and every query is filtered at the data layer. Cross-tenant reads are an explicit, logged, admin-only act.
White-label verticals
Each vertical resolves by subdomain to its own brand, its own data plane and its own ops app — promotion to a dedicated database is configuration, not migration.
A number the platform cannot verify is a number it refuses to act on.
Settlement runs block on missing rack prices rather than guessing. Tax engines refuse loads they cannot price rather than filing zero. Go-live is a gated transition that will not pass on demo data. The arithmetic always computes — only the irreversible act refuses.
Refusals are named
no_card_batch, no_rack_price_for_Diesel, no_site_jurisdiction — every blocked day says exactly which number was missing and who to chase.
Demo data cannot pay anyone
Every figure carries its origin — fixture or source-of-record — and one fixture input taints the whole result. The three irreversible money acts refuse a tainted basis.
Health reports what is true
The health endpoint separates "the database is up" from "this process initialized against it" — and a failed migration kills startup rather than serving from a schema in an unknown state.
A payment in four lines.
Create
POST /v1/payment-orders X-API-Key: dt_live_... Idempotency-Key: inv_8842_pay { "externalId": "inv_8842", "direction": "Credit", "rail": "Ach", "amountCents": 250000, "counterpartyName": "Acme Carrier", "ledgerAccountName": "Carrier Payables" }
Observe
// signed webhook → your endpoint // DT-Signature: t=...,v1=hmac_sha256(...) { "type": "payment_order.completed", "data": { "id": "po_9f2c...", "status": "Completed", "amountCents": 250000 } }