The ledger (module 5) tells you what each seller is owed. The payout engine is the machine that turns that number into money in their account. It is the part of the stack sellers judge you on most, because a wrong amount or a late deposit is the thing they feel directly. Everything upstream can be perfect and a brittle payout layer will still generate the support tickets.
This is not a single integration. A payout engine makes four decisions on every disbursement: when to release, which rail to use, how to batch, and how to handle currency. We will take them in order.
Timing: when money is allowed to leave
Payout timing is a risk decision before it is an operational one. Funds you have collected may still get pulled back through a refund, a chargeback, or an ACH return, and once you have paid a seller out, clawing that money back is hard. So the engine holds funds for a window, then releases.
Most platforms run a rolling schedule. Stripe Connect, for example, makes funds available on a two-day rolling basis by default, with the exact timing varying by country and account, before they are eligible for payout. The schedule itself is separate from the rail: you can hold available funds and pay out daily, weekly, or on manual triggers via an API call.
New or high-risk sellers usually get a longer hold or a rolling reserve, a percentage of volume held back to cover future disputes. The trade-off is real. Tighter holds protect the platform's balance sheet; looser holds win sellers. Decide this per risk tier, not as one global number, and make the reserve logic visible in the ledger so a seller can see why their available balance is lower than their gross.
Rails: the menu and its constraints
Once funds are released, a rail moves them. In the US you have a small, well-defined set, and each has hard limits and cutoffs you must design around.
ACH
Standard ACH is the cheap default for domestic payouts: cents per transaction, but next-day or slower, and reversible for a window. Same Day ACH adds speed at three Federal Reserve processing windows each business day, with submission cutoffs around 10:30 a.m., 2:45 p.m., and 4:45 p.m. Eastern. The per-payment limit is $1 million, in place since March 2022. Nacha has approved an increase to $10 million, but it does not take effect until September 17, 2027, so do not build to it yet. Anything above the current limit drops to next-day settlement, and Nacha rules prohibit splitting a large payment into multiple same-day entries to dodge the cap.
Instant rails: RTP and FedNow
For payouts that need to land in seconds, 24/7, the two US instant rails are The Clearing House's RTP network and the Federal Reserve's FedNow Service. Both now support payments up to $10 million per transaction. RTP raised its single-payment limit to $10 million in February 2025; FedNow raised its cap to $10 million in November 2025. They run on separate rails and are not interoperable, so reaching a given seller's bank depends on whether that bank has joined the network you are sending on. Instant payouts are also push-only and irrevocable, which is a feature for the seller and a risk for you: once it lands, you cannot pull it back.
Push-to-card
Visa Direct and Mastercard Move push funds to a debit card in near real time. Sellers like it because they get money fast without sharing bank details. You pay a higher per-transaction cost than ACH, and card-network reach and limits apply.
Mass payouts: the batch problem
Paying one seller is trivial. Paying 50,000 sellers every Friday is where engines break. A mass payout run has to be idempotent, partially recoverable, and reconcilable.
Idempotent means a retried batch never double-pays. Attach a unique key to each disbursement so the same instruction submitted twice resolves to one payment. Partially recoverable means that when 200 of 50,000 fail (closed account, bad routing number, rejected return), the run does not halt; it flags those 200, pays the rest, and queues the failures for repair. Reconcilable means every line in the batch maps back to a ledger entry and forward to a rail confirmation, so you can prove what left and what bounced.
A worked example
A creator platform owes 12,000 sellers on a Friday cycle. The engine queries the ledger for available balances above each seller's payout minimum, producing 11,300 eligible disbursements totaling $4.2 million. It groups them by rail: 10,900 to bank accounts via Same Day ACH, 400 to debit cards via push-to-card for sellers who opted in.
The ACH file must clear before the 2:45 p.m. Eastern window to settle that afternoon, so the run starts at noon. Forty payments fail on a bad account number and return; the engine does not retry them blindly. It marks those sellers' balances as still owed, notifies them to update their details, and the other 11,260 settle. On Monday, reconciliation matches every settled payment to its ledger debit and confirms the platform's bank balance dropped by exactly the file total minus returns. The 40 failures sit in a repair queue, not lost in a log.
Cross-border: where cost and complexity live
The moment a seller is in another country, you inherit foreign exchange, local rails, and compliance. The naive approach, an international wire per seller, is slow and expensive at scale.
Aggregator rails exist to solve this. Visa Direct and Mastercard Move reach accounts, cards, and wallets across 190-plus countries and many currencies, often by connecting into domestic instant schemes such as PIX in Brazil, UPI in India, SPEI in Mexico, and SEPA Instant in Europe. The seller receives funds on a familiar local rail; you submit one instruction.
The cost that hides from you is the FX spread. A provider quoting a low headline fee may take its margin in the exchange rate. When you compare cross-border providers, separate the explicit fee from the rate markup against the mid-market rate, and price the all-in cost per corridor. A 1.5 percent spread on $2 million of monthly payouts is $30,000 a month that never appears on an invoice line.
The takeaway
A payout engine is a decision tree, not a connector. For each disbursement it picks a release time set by risk, a rail set by speed and limits, a batch strategy that survives partial failure, and a currency path priced corridor by corridor. Build it so every payment is idempotent, every failure is recoverable, and every dollar traces back to the ledger and forward to a rail confirmation. Get that right and the rest of the platform's money movement stays quiet, which is exactly what sellers want from it.