Routing intelligence for apps that move money. One API over the providers you already have deals with: Unirail picks the provider and rail for each payment and tells you what it costs and why. Your licences, your contracts, your money flow.
3 lines in service10 listed23 countries
Example route
Enable BankingIn service
NeonomicsListed
Nordic and EEA account information and payment initiation.
PlaidIn service
Bank linking, UK payment initiation, VRP consents and identity verification through Plaid Link.
YapilyIn service
UK open banking: account linking and single immediate payments across UK banks, with Unirail’s own bank picker.
TrueLayerListed
UK and European payment initiation; a second UK PISP for substitution when one provider degrades.
Enable BankingIn service
EEA account information and payment initiation: SEPA, SEPA Instant and domestic schemes, straight from payer to payee.
OpenPaydListed
Banking-as-a-service: accounts and virtual IBANs, payouts, pay-by-bank, stablecoin ramps, UK CoP and EU VoP.
Wise PlatformListed
Cross-border transfers through Wise, or from a user’s existing Wise account.
AirwallexListed
One contract for collections, payouts over local rails in many countries, FX, and UK CoP / EU VoP name checks. Routes through it hold money in transit.
NiumListed
Wallet-based global payouts, collections and FX, plus Nium Verify for account checks.
PayNow QRListed
Singapore person-to-person payments by QR code to a PayNow proxy, attested rather than confirmed.
MoneytreeListed
Japanese account aggregation for linking and ownership checks.
BridgeListed
Stablecoin orchestration: on and off ramps, virtual accounts and custodial wallets, including USDC and USDT.
Modern TreasuryListed
US payment operations over the platform’s own bank accounts: ACH, wires, RTP, counterparties and reconciliation.
3 in service · 10 listed · 23 countries
Add the providers you already have contracts with, per environment. Your Infisical is wired in once, so a new provider needs no new environment variables.
4 of 4 found, sandboxAsk for routes between two payto:// accounts. Up to three quotes come back, each with legs, cost, ETA and custody, plus the routes that can’t run and why.
routeQuotes.create()Your app binds your user’s approval, a passkey for instance, to the quote’s id and digest. If what they approved no longer holds, the intent fails with quote_changed.
{ quote, digest }Your backend calls the provider through the SDK with your own credentials, or Unirail makes the call for you. Either way, legs report on one event stream as Standard Webhooks.
leg.updatedUnirail returns at most three quotes, labelled cheapest, fastest and recommended, chosen from routes no other route beats on every axis. Each one lists its legs, cost, ETA and whether a provider holds the money in between. Routes that can’t run come back too, with the reason.
Airwallex collection account: not offered, two legs with money held in transit.
Recommendedqt_9bQm71
Fastestqt_4f8Kc2
Cheapestqt_2xLpA0
Signs qt_9bQm71 + digest
Illustrative quotes. Which line wins depends on your contracts with each provider and the banks involved. Routes through meta-providers such as Airwallex hold money in transit, so they only appear where your routing policy admits that custody; a policy that admits only none gets them back as infeasible, with the reason.
Unirail is never in the money flow and never the regulated party. You keep your licences, your provider contracts and your own KYC and AML. Unirail decides the route; you choose who makes the call.
Unirail receives masked metadata only, no personal data and no account numbers, and returns the decision: which provider and rail, what it costs and why. Your backend calls the provider through the SDK with your own credentials. Unirail never touches secrets or money, and the decision engine can be self-hosted.
Unirail calls the provider for you, reading your credentials just in time from your own vault through OIDC federation. Your provider contracts stay yours, and nothing of yours is stored. Below is how the keys travel in this mode.
Execute via Unirail Credentials, read just in time
Unirail runs its own OIDC issuer and mints a token per organisation and environment. Your Infisical machine identity trusts that issuer and that subject, read-only on one folder.
Delete the machine identity and access ends. Nothing to rotate on our side, because there is nothing of yours on our side. Non-secret settings, such as redirect URIs or enabled countries, live on the connection in the dashboard.
Values sit in isolate memory while a provider is called, for at most five minutes, and are never written to storage, logs or traces. A cold isolate adds one Infisical round trip before its first provider call.
Every provider is a listing: what it covers by country, its roles, custody model, regulatory status and how onboarding works. You sign with the providers; Unirail routes across them. Capabilities layer outwards from banking, with several providers per capability and jurisdiction, so a route can change line when one degrades.
Linking accounts and moving money between them: payments, pay-ins and payouts.
Checking account details belong to who you expect before money moves: UK Confirmation of Payee, EU Verification of Payee.
Knowing who your user is.
Screening people and payments against sanctions, PEP and adverse-media lists.
Placeholder Provider slots open. Screening joins the map as its first providers are listed.
3 integrated, 10 listed, 23 countries, straight from the Unirail catalogue. Listed providers are researched from public documentation; a claim nobody has verified says so.
The SDK runs in your backend. One call gets the routing decision, one creates the intent, and everything after arrives as events, in the same shapes whichever provider ran the payment. Adding a provider is configuration, not a rewrite.
import { createUnirail } from "@unirail/sdk";
const unirail = createUnirail({ apiKey: process.env.UNIRAIL_SECRET_KEY });
const { quotes } = await unirail.routeQuotes.create({
from: payer,
to: payee,
amount: { value: "5000", asset: "iso4217:GBP" },
});
const intent = await unirail.paymentIntents.create(
{ quote: quotes[0].id, digest: quotes[0].digest, returnUri },
{ context: { idempotencyKey: `pay:${id}` } },
);
One event stream, signed with Standard Webhooks.
Everything a platform used to build in its own back office to operate rails lives at app.unirail.dev: environments, keys, provider connections, routing policy, your provider deals, the event log and a route explorer.
Provider sandboxes only.
ur_test_sk_…A test key can never touch live data, and a live key never touches test. A misconfigured connection fails at setup, not on a payment.
Provider production only.
ur_live_sk_…One provider in one environment, health-checked: credentials resolve, a cheap authenticated call succeeds, webhooks are registered, certificates aren’t near expiry.
Bindings by jurisdiction and stage, plus preferences. “Plaid in GB at stage ga” makes that connection eligible for GB payments.
Secret and publishable keys per environment, scoped, shown once and stored as a hash. The key’s environment decides where a call runs.
Your contracts, fees and volume tiers next to live routing data, so you go into every negotiation knowing what switching would save.
Every normalised event for links, accounts, intents and legs, in order, and the signed endpoints they’re delivered to.
The routes a payment could take between two accounts, and the reasons the others can’t run.