Integrating a payout provider costs weeks. Discovering that a corridor does not behave as described costs considerably more, and it is discovered in production. These are the questions worth asking in the first call, in rough order of how much trouble they save.
About the corridor
1. Which rail does this corridor actually use? A local instant system, or a correspondent chain? This determines speed, failure behaviour and what the recipient sees. Providers who know their infrastructure answer immediately.
2. What exactly identifies the recipient here? You want the field names and the formats, not “bank details”. If the answer is vague, the integration will be too.
3. Does this corridor check the recipient’s name? Some do and will refuse a mismatch; some ignore it entirely. This changes your form and your support scripts.
4. What are the amount rules? Decimals or whole units, and what the current limits are. Limits that live in documentation rather than in an API response are limits that will be out of date.
About failure
5. What happens to the money when a payout fails? The right answer is that it returns to your balance as part of the same status change. A separate refund process is a source of reconciliation pain.
6. How do I find out? A webhook is the expected answer. Ask what the retry schedule is and what happens after the last attempt — if delivery simply stops with no way to catch up, you will need to poll anyway.
7. What happens if my request times out mid-flight? Ask specifically about idempotency. If repeating a request can send twice, you will eventually double-pay somebody, and it will happen during an incident when everyone is already busy.
About the relationship
8. Is the balance prepaid, and how quickly does funding land? Prepaid is normal in this business. What matters is the lag between sending funds and being able to use them, because that lag sets your working capital.
9. What happens when a corridor goes down? Markets do stop accepting operations — maintenance, incidents, regulatory pauses. Ask whether you are notified, or whether you discover it through failed payments.
10. Who do I talk to at two in the morning? A named person who knows your integration, or a shared inbox. Both are answers; only one is useful during an incident.
11. Can I test it properly before committing? A sandbox that returns canned responses proves nothing. A sandbox that validates recipient details against the same rules as production, and lets you drive an operation through every status including the unhappy ones, proves quite a lot.
What the answers tell you
Less about the product than about the company. A provider who runs a corridor knows its quirks and will tell you about them unprompted, because they have been woken up by them. A provider reselling a corridor they have never sent their own money through will describe it in the language of their own supplier’s brochure.
The difference shows up in the specifics. Anyone can say “we cover twenty countries”. Fewer can say what a Thai bank does with a name written in Cyrillic, and those are the ones worth integrating with.