Bulk Disbursement Pattern
Send many outbound payments with route-aware batching, per-item idempotency, and webhook-driven reconciliation across corridors.
Bulk Disbursement Pattern
Use this pattern when your integration needs to send many outbound payments efficiently, with route-aware batching, per-item idempotency, and webhook-driven reconciliation for each outcome.
✅ Before you start
Complete these steps before you implement the bulk disbursement pattern:
- Authenticate with the merged Login service and store the returned
tokenandcompanyId. - Confirm the source wallet has enough
availableBalancefor the planned batch. - Create and store beneficiary records for every recipient before the batch begins.
- Register webhook endpoints so you can reconcile each payout outcome asynchronously.
- Generate a unique
paymentIdor idempotency key for every item in the batch — never one for the batch as a whole.
📚 Use this page with the recipe
This guide explains when to use the bulk disbursement pattern and the minimum sequence. For the implementation walkthrough, use the recipe:
Bulk Disbursement Pattern Recipe →
The bulk disbursement pattern
This integration pattern follows a strict sequence:
- Group payouts by route or currency to take advantage of route-specific batching.
- Validate beneficiary readiness for every item before submission.
- Submit each payout with its own idempotency key so retries reuse the original operation.
- Track each payout independently through webhooks rather than polling.
- Reconcile completed, failed, rejected, or refunded items back into your source system per record.
- Retry only the affected items when a subset of the batch fails or times out.
What makes this pattern different?
Unlike a single payout flow, bulk disbursement needs to:
- isolate per-item failures from the rest of the batch
- keep idempotency keys at the item level for safe retries
- support partial batch processing across multiple corridors
- drive reconciliation from webhooks rather than synchronous responses
Where to go deeper
Troubleshooting
| Issue | What to check |
|---|---|
| Whole batch is retried | Move idempotency keys to the item level and retry only the affected payouts. |
| Duplicate payouts after retry | Confirm the original paymentId or idempotency key is reused, not regenerated. |
| Beneficiary fails mid-batch | Pre-validate beneficiary readiness before submission and queue the item into remediation. |
| Reconciliation drifts | Reconcile each item from webhook-confirmed states, deduplicate by event ID. |
Next steps
| Bulk Supplier Disbursement → See the supplier-specific implementation of this pattern. | Retry Timed-Out Payouts → Recover safely when an item returns an uncertain result. |
Updated 3 days ago
