Product · Platform
Everything between your API call and cleared funds — the rails, the router, the runs, the accounts, and the ledger that ties them together.
Each network has its own windows, cutoffs, and failure modes. We model all of them so you can address them as one.
Standard ACH settles T+1; same-day ACH clears in hours across three daily submission windows. latchpay picks the window automatically, batches to it, and handles the full return-code set — R01 insufficient funds, R03 no account, R29 corporate not authorized, and the rest — as first-class payout states, not support tickets.
For high-value, must-arrive-today payouts. Same-day settlement with a hard network cutoff late afternoon Eastern; we track the cutoff live and either submit or tell you it will queue for the next window before you commit. Irrevocable once sent — the router treats wires accordingly.
EUR payouts across the SEPA zone. Standard SEPA credit transfers settle next business day; SEPA Instant clears in seconds around the clock where the receiving bank participates. IBANs are checksum-validated and bank-directory-checked at creation time, so malformed destinations fail in the API response, not three days later.
Real-time payments, 24/7/365 including weekends and holidays, with a <2s median payout acknowledgement. Credit-push only and irrevocable, which makes it our favorite rail for time-sensitive payouts to reachable accounts — and why the router checks reachability before promising it.
Smart routing
For every payout, the router scores each eligible rail on four inputs and picks the winner. No configuration required; every decision is recorded on the payout for audit.
When a rail degrades mid-run, unsent payouts re-route to the next-best rail automatically. Already-sent payouts that return are retried or failed cleanly — never silently dropped.
Follow a payout end to endSettlement runs
Post payouts one at a time or a million per run — batch or stream, same API. A run moves through a fixed lifecycle, and one bad payout never blocks the other 999,999.
Every item is account-validated, screened, and priced. Items that fail validation are rejected in the API response with a reason code; the rest proceed.
Payouts fan out to their rails independently. A run is completed when every item reaches a terminal state — settled, returned, or failed — and run.completed fires with per-item counts.
A returned or failed payout is quarantined into the exception queue with its return code and retry options. It never holds funds, blocks siblings, or stalls the run.
Recipients & accounts
Most payout failures are bad destinations. We validate accounts and verify ownership before anything touches a rail.
POST https://api.latchpay.xyz/v1/recipients { "name": "Brightline Retail LLC", "account": { "routing": "021000021", "number": "••••4821" }, "verify_ownership": true } // → 201 { "id": "rcp_2ma7", "status": "verified", // "rails": ["ach", "rtp", "wire"] }
Treasury & funding
Fund runs the way your treasury works: prefund a balance and draw it down, or authorize a just-in-time debit from your operating account when a run executes. Either way, funds sit 1:1 in segregated, bankruptcy-remote accounts at regulated banking partners — never commingled, never lent. The float is not a business model.
The ledger
Every payout, return, fee, and funding movement writes an append-only ledger line, matched against bank statement lines in real time. Nothing is ever edited — corrections are new entries that reference the old.
Per-rail and per-payout pricing is published, not negotiated in the dark — see pricing
Four rails, one router, one ledger — and a payout lifecycle you can read in five minutes.