One request, many legs
Up to 25,000 legs per batch, each with its own recipient, amount, chain, and reference.
Products
Batch payouts
Pay ten thousand recipients in one signed batch, and recover from the three that failed without re-running the other 9,997.
At a glance
- 25,000
- Legs per batch
- 32 MB
- Max payload
- 10,000
- CSV rows via dashboard
- Zero
- Double payments
Overview
Why teams choose batch payouts
Bulk payment systems are usually fine until something goes wrong. Then you are reconciling which subset of a payroll run landed, and the answer is spread across four block explorers and a support thread.
JuicePay encodes intent into the batch itself. Legs are keyed from the batch key and row index, so a replay never double-pays. Failures report per row, along with whether the cause is permanent or transient. You fix the cause, replay the failures, and the rest of the batch is untouched.
Capabilities
What you get
Dry runs
Validate every leg without moving value. Dry runs return the same validation errors as a real submission.
Classified failures
Errors are marked permanent or transient, so your recovery logic knows whether to retry or escalate.
Partial replay
Replay only the legs that failed. Deterministic leg keys make a stale failure list safe to reuse.
Ship batch payouts this week
Mint a sandbox key and run the whole flow against deterministic fixtures before you move a single real dollar.