A second rail won't fix the first

From Dubai, I speak with people who sell, buy and work across borders. Many are building digital businesses. Some call a second way to get paid their “plan B.” I understand the instinct. Depending on one doorway feels risky when your suppliers and customers are in different places.

But before talking about any product, I try to say the awkward part out loud: a second route will not release money held on the first. It cannot make a bank reverse a decision, and a new provider is not a guarantee of continuity. If that's the expectation, we're starting in the wrong place.

What another route may offer is an option for future transactions, provided the business and that route are eligible. Less exciting. More useful.

For an e-commerce merchant, I'd start with a sheet of paper, not a demo. Write down three real operations:

• Getting paid for an order. Who pays, in which currency, to which beneficiary, and how is the order identified?
• Paying a supplier. Which legal entity is on the invoice, what method does the supplier accept, and who bears conversion and charges?
• Handling an exception. If the payment is delayed, what status is confirmed, who can investigate, and what do you tell the other party?

Only then would I compare the two routes. Not just the visible price. I would also look at supported jurisdictions, the legal names that appear, limits, the timelines actually published by the provider, and the quality of its records. If you can't explain who owns each step, the route is not ready for your operating model.

There's another uncomfortable question: how much of the process depends on one person? Teams talk about banking redundancy while only the founder knows how to match a receipt to an invoice. Two providers don't solve that. You still need references, states and someone who can close an exception.

This connects to something I wrote recently: the customer should not have to learn our architecture in order to pay us. An alternative improves the product only if it doesn't pass confusion to the buyer or the operations team.

I'm a co-founder of Bennu, so I have a stake in this problem. That's exactly why I want to be precise: requesting an invitation does not mean approval, an available account or access to any particular route. Those depend on the relevant review, provider, jurisdiction and active capability.

In the end, what matters is building. In cross-border payments, building also means knowing what to do when one route is unavailable, without pretending the other one solves everything.