Product · How it works
The full lifecycle of a payout run — validation, screening, routing, clearing, returns, and reconciliation. Nothing hand-waved.
Step 01 · Create a run
One request creates a run of 1 to 1,000,000 payouts. Every item is validated synchronously — currency, amount, recipient, rail eligibility — and invalid items are rejected with reason codes in the response, before any money moves.
POST https://api.latchpay.xyz/v1/payouts Idempotency-Key: "run-2026-07-02-a" { "currency": "USD", "rail": "auto", "items": [ { "recipient": "rcp_2ma7", "amount": 4821000 }, // … 411 more ] } // → 201 { "run": "run_8fa2", "accepted": 410, // "rejected": 2, "status": "validating" }
Nothing touches a rail until it passes every gate. Then each payout gets a rail and a locked price.
Routing numbers and IBANs are checksum- and directory-validated; recipient ownership checks run for first-time destinations. Bad account data fails here, synchronously — not as a return next week.
Every payout is screened against sanctions lists, then evaluated against your configurable approval policy — amount thresholds that require a second approver, velocity limits per recipient and per day. A held payout waits; it never leaks.
The router scores cost, speed target, destination coverage, and live rail health for each payout, assigns a rail, and locks the price. The run summary comes back with per-rail counts and total fees before anything is sent.
How the router decides — and what happens when a rail degrades — is covered in depth on the platform page
Step 04 · Clearing
Payouts fan out to their rails and clear independently. You see every state change as it happens — created → sent → settled — per payout, not per batch.
Step 05 · Returns & exceptions
ACH returns arrive days after send — R01 insufficient funds, R03 no account, R29 not authorized. Each one flips the payout to returned, fires payout.returned with the code, and enters a decision.
Returned funds land back in your segregated account and post to the ledger the moment they arrive. Money in motion deserves a paranoid rail.
Step 06 · Reconciliation & close
Every state change fires a signed webhook, and every money movement — disbursement, return, fee — is matched to its bank statement line in real time. Your books agree with the bank's before you ask.
POST https://yourapp.example/webhooks/latchpay Latchpay-Signature: "t=1751468400,v1=9f2ab…" { "event": "payout.settled", "payout": "payout_31c9", "run": "run_8fa2", "rail": "rtp", "amount": 1240000, "ledger_line": "led_66e0", "statement_match": true }
Step 07 · What you never do again
No NACHA files hand-built at 4pm, no SFTP drops, no per-bank formats. The API is the file.
No exporting statements into a spreadsheet to hunt for the $14.20 that does not match. Every line is already matched.
Returns arrive as webhooks with codes and dispositions, not as a support thread three weeks later.
Seven steps, no hand-waving. The sandbox lets you run all of them today.