Pay by Alias: Resolve Once, Let Routing Pick the Rail
The cleanest payment experiences hide a decision the sender should never have to make: which rail to use. When you pay by alias, you name a person and the system works out the fastest, cheapest, most reachable path to their money. That split — addressing on one side, routing on the other — is the quiet architecture behind modern multi-rail payments.
Two steps that used to be one
Traditionally, choosing a destination and choosing a rail were the same act. If you typed a routing number, you were on ACH. If you pasted a wallet address, you were on-chain. Pay-by-alias breaks that coupling. Step one resolves the alias to a set of possible destinations. Step two selects a rail based on policy, not on what the sender happened to type.
What resolution returns
When KibiPay resolves an alias, it does not just return a single account. It returns the candidate destinations attached to that identity, each tagged with a rail, a verification state, and any constraints. A phone number implies mobile money; a bank account implies ACH or FPS; a wallet implies Solana. The routing engine reads that menu and decides.
- Resolve
@amaraand you might get a verified phone, an unverified email, and a bank account. - The engine filters to destinations that are verified and currently reachable.
- It then ranks the survivors by cost, speed, and success probability.
How the engine chooses
Routing is a ranking problem. Given several viable destinations, the engine scores each rail against the payment's requirements. A small, instant, domestic transfer might favour FPS; a mobile-first recipient in a mobile-money market favours Mojaloop; a crypto-native counterparty favours Solana; a routine US payout favours ACH.
| Signal | Favours |
|---|---|
| Need for instant settlement | FPS, Solana, mobile money |
| Lowest cost for large batch | ACH |
| Recipient reachability | Whichever rail the recipient has verified |
Why senders love it
The sender's job shrinks to one action: choose who, confirm the name, send. No rail dropdown, no account-number form, no guessing whether the recipient prefers bank or wallet. That simplicity is not cosmetic — it removes the exact fields where mistakes and fraud creep in. For the trust layer that sits alongside resolution, see our note on confirmation of payee.
Failure is a routing event, not a dead end
Because the alias resolved to several destinations, a failure on one rail is not the end of the payment. If a mobile-money leg times out, the engine can consider the next-best destination rather than bouncing the whole transfer back to the sender. That reroute logic is only possible because addressing and routing were separated in the first place.
Bringing it together
Pay-by-alias is where KibiPay's directory earns its keep. The directory answers "who and where"; the routing engine answers "how". Keep those responsibilities clean and you get a payment flow that is both simple for humans and flexible for machines. To understand the addressing formats the resolver has to normalise, our guide to sort codes, IBANs, and aliases is worth a read.
Idempotency and retries
Splitting addressing from routing has a subtle operational payoff: retries become safe. Because the payment carries an alias and an intent rather than a committed rail, a transient failure can be retried against the same resolution without double-spending, provided each attempt carries an idempotency key tied to the original request. That key lets the engine recognise a retry as the same payment rather than a brand-new one, so a network blip never turns one transfer into two. Getting idempotency right is unglamorous work, but it is the difference between a routing engine you can trust with real money and one that occasionally pays twice. KibiPay keys every payment attempt so reroutes and retries stay exactly-once from the sender's point of view, no matter how many rails were tried.
Resolve once, route smartly, settle on whatever rail wins. That is the whole idea, and it is why alias-first payments feel less like banking and more like sending a message.