Contractor & Gig Worker Payouts
Pay contractors, freelancers, and gig workers across corridors using instant local rails, mobile money, and standard bank routes with per-item reconciliation.
Contractor & Gig Worker Payouts
Use this flow when you need to pay contractors, freelancers, or gig workers across corridors, including instant local rails where available.
✅ Before you start
Complete these steps before you run a contractor payout cycle:
- Authenticate with the merged Login service and store the returned
tokenandcompanyId. - Confirm the source wallet has enough
availableBalancefor the planned run. - Collect contractor banking, mobile-money, or stablecoin wallet details for each corridor.
- Create and store beneficiary records for repeat workers so you can reuse them across cycles.
- Register webhook endpoints so you can reconcile each payout outcome asynchronously.
- Generate a unique
paymentIdor idempotency key per worker payment.
📚 Use this page with the recipe
This guide explains when to use the contractor payout flow and the minimum sequence. For the implementation walkthrough, use the recipe:
Contractor & Gig Worker Payouts Recipe →
The contractor payout workflow
This use case follows a simple sequence:
- Create or validate beneficiary records for each worker with Create beneficiary.
- Check beneficiary readiness before adding a worker to the payable run.
- Choose the right rail for the corridor — instant local rails such as M-Pesa or FPS where supported, or standard bank transfer otherwise.
- Get an FX rate and create the FX trade with Get FX rate and Create FX trade when the payout currency differs from the source wallet currency.
- Track payout state through webhooks for each item.
- Reconcile final state back into your contractor management system.
What makes this use case different?
Unlike B2B supplier flows, contractor payouts usually need to:
- support C2B routes such as mobile money and instant local rails
- capture personal identity data required by certain corridors
- prove individual payment outcomes per worker rather than per run
- refresh beneficiary readiness before each cycle for active contractors
Where to go deeper
Troubleshooting
| Issue | What to check |
|---|---|
| Worker payout rejected | Verify routing fields, mobile-money number format, country, and corridor requirements. |
| Instant rail not used | Confirm the corridor supports the instant rail and the receiving account is enabled for it. |
| Worker beneficiary requires update | Re-run beneficiary validation before payout when isUpdateRequired is true. |
| Duplicate payment risk | Reuse the original paymentId or idempotency key when retrying a worker payment. |
Next steps
| Send → Implement the outbound payout flow for each worker. | Currency Guides → Confirm instant rail and mobile-money availability per corridor. |
Updated 3 days ago
