How to choose a mass payout provider

The demo shows the run, not the residue

A payout run that works is indistinguishable across vendors; the product you are actually buying is what remains afterward. Residue is the failed tail of the run: recipients whose details were wrong, whose banks bounced the credit, whose names tripped a screening rule, whose funds arrived short. At a hundred recipients the residue is an inbox; at fifty thousand it is a team. The provider's design decisions — where vetting happens, how failures isolate, when funds are final — set the size of that team, which is why they matter more than the per-payout fee on the pricing page.

Recipient onboarding is the product

The hard constraint on paying thousands of recipients across borders is not moving the money — it is knowing who each recipient is. Every recipient must be vetted, screened, and validated before the first payment, and the provider's model for that work is the largest difference between platforms. Some hand you an API and leave vetting as your problem. Some re-vet from scratch what other platforms have already vetted, and charge you the delay. A network model does the work once and shares it — the economics of that difference are the argument of Mass payouts scale on vetting, not volume.

Ask a payout provider how fast it pays and you learn about its rails. Ask how a new recipient becomes payable and you learn about its product.

What a failure actually costs

Failures are per-recipient events; the question is whether the provider treats them that way. One flagged name should hold one payout, not the run. A bounced credit should return funds to a known place, on a known timeline, with a reason you can act on — not evaporate into a correspondent chain for two weeks. Retries should be idempotent, so resolving a failure cannot double-pay the other side of it. And the failure state should be queryable per recipient, because "where is my payment" lands on your support team, not the provider's. Walk a vendor through one wrong bank account, end to end, before you sign anything.

Settlement windows are a product feature

Payout recipients live on every calendar. A provider bound to banking hours batches Friday's earnings into Monday's problem; on stablecoin rails, settlement runs on the payment's schedule rather than the banking system's, and funds that have settled are final. Finality matters as much as speed: a credit that can be clawed back is not paid, it is provisionally paid, and recipients — especially sellers and workers being paid their income — feel the difference. Why finality is a property to verify rather than assume is the subject of Settlement finality is a compliance property.

Price the recipient, not the payout

Per-payout fees are the visible line of a price that mostly lives elsewhere: the FX spread applied when funds convert to the recipient's currency, deductions taken on the receive side before the money lands, the cost of failures measured in support time and float, and minimums that reprice small payouts. The way to compare providers is an all-in quote per recipient, per corridor, at your actual size distribution — the same discipline argued in What a cross-border payment actually costs. A provider that cannot quote all-in is telling you where the margin hides.

Global mass payouts on Infinite (infinite.net) are built on the network model: recipients vetted once into the network, screening on every instruction, per-recipient failure isolation, and same-day final settlement that does not observe weekends.

Frequently asked questions