Provider availability changes by account
A route allowed for one account or payout may not be eligible for another. Ops needs the policy order and result on the record.
Routing
Keep global payouts moving when corridors change
Your account policy sets an ordered provider path. If an eligible initiation attempt fails, Gruv can try the next option without turning the retry into a second payout.
Corridor validationRetryable failoverProvider trace
馃嚭馃嚫North America
ACH 路 RTP 路 Wire
馃嚜馃嚭Europe
SEPA 路 Faster
馃嚙馃嚪LATAM
Pix 路 SPEI 路 Local
馃嚫馃嚞Asia-Pacific
NPP 路 FPS 路 IMPS
馃嚘馃嚜MENA
IPS 路 Local rails
馃嚢馃嚜Africa
M-Pesa 路 Mobile
Multi-country routes
Where global payout routing breaks
You discover bad details after funds are in flight
A provider can accept an instruction and later return a failure. The payout record needs the provider reference and latest status.
Recovering a failed payout takes longer than sending it
Without the provider reference, reason, and retry identity on one record, ops cannot tell whether to retry, investigate, or stop.
Support cannot explain where the money is
A contractor asks "where is my payout?" Your support rep checks the bank portal, the spreadsheet, and Slack before finding the answer.
Corridor Routing
Corridor routing with recoverable failures
Use account policy to order eligible providers. If initiation fails with an eligible retryable result, preserve the payout identity while trying the next option.
Account-policy eligibility
Evaluate the payout against the provider options and priority in account policy.
Ordered provider choice
Start with the first eligible provider in account policy rather than inventing a route at request time.
Retryable initiation failover
When an initiation failure is eligible for failover, try the next provider under the same payout intent.
Provider status and reference
Keep the current payout status, reason, provider selection, and provider reference together for operations.
Idempotent retry identity
Reuse the original idempotency identity when retrying the same payout instruction.
Operational trace
Retain provider selection, reference, status changes, and timestamps for investigation and review.
Capabilities
What corridor delivery requires
Account-policy provider order
Review the eligible providers, their priority, and the result of each initiation attempt.
Eligibility before choice
Choose only from providers allowed by account policy for the payout request.
Retryable failover
Move to the next provider only when the initiation result qualifies for failover.
Delivery trail
Provider selection, reference, status changes, reasons, and timestamps stay on the payout record.
How it works
From validated route to recoverable delivery
What to confirm before a corridor goes live
A sound route starts with an explicit provider order and ends with a status trail operations and finance can follow.
Policy
Provider order
Review the eligible providers and their priority before releasing a batch.
Input
Beneficiary readiness
Confirm the payout request and beneficiary are ready before provider selection.
Failure
Retry boundary
Define which initiation failures qualify for the next provider attempt.
Support
Investigation trail
Keep the selected provider, reference, status, and reason ready for support.
Finance
Result handoff
Keep the provider decision and current payout result visible for review.
More in Mass Payouts
Explore more in Mass Payouts
Payout risk review
See which payout instructions need attention, understand the reason, record the decision, and execute only approved item
Overview
Upload payout rows by CSV or API, catch field and beneficiary issues, review and process the batch, see each payout stat
Batch review
Review payment-run status, inspect individual payouts and reason codes, take the actions available to you, and download
Frequently Asked Questions
Do all countries support the same payout methods?+
No. Account policy and the payout request determine which provider options are eligible. Review that order before releasing the batch.
What happens when a payout fails in one country?+
The item retains its status, reason, selected provider, and provider reference. If initiation failed with an eligible retryable result, the router can try the next provider under the same payout intent.
Can we launch in three countries and expand later?+
Begin with corridors approved for the account, test a routine initiation and an eligible failure path, then review the trace before expanding.
How do retries avoid paying someone twice?+
Reuse the same idempotency identity only for the same payout instruction. A conflicting payload is rejected rather than treated as the original request.
Next step
See where Gruv fits
Tell us what you are trying to do, where it needs to work, and how your team handles it today.
Contact the team