unirail

unirail — one API for every payment rail

unirail

one API for every payment rail

3 integrated · 10 listed · 23 countries · 2 modes: decide · execute

Routing intelligence for apps that move money. One API over the providers you already have deals with, your own vault wired in, your contracts next to live routing data, and a decision for every payment: which provider, which rail, what it costs and why. You keep your licences, your contracts and the money.

type , or tap a command below.The same content is in the manual after the terminal.

Try help, decide, quote, deals, providers, matrix, routes, vault, events or sdk. Tab completes, arrow keys browse history.
docs ↗dashboard ↗
↓ man uniraila simulation in test mode · sample figures, not pricing

NAME

unirail — one API for every payment rail

SYNOPSIS

$ pnpm add @unirail/sdk
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}` } },
);

DESCRIPTION

Unirail is routing intelligence and management for apps that move money. Think of it as the GDS for payments: the way airline distribution lets one booking system reach every carrier, one Unirail integration reaches every provider you already have a deal with, and each payment takes the route your policy prefers.

Unirail is not an intermediary in the money flow. You hold your own licences, your own contracts with PISPs, aggregators and KYC vendors, and you run your own KYC and AML. Unirail gives you four things on top:

  • One API and SDK over the providers you already contract with.
  • Your secrets manager, wired in (Infisical first), so a new provider needs no new environment variables.
  • Deal tracking and leverage: contracts, fees and volume tiers next to live routing data, so you negotiate knowing what switching saves.
  • Routing decisions: which provider and rail, what it costs, and why.

It starts with banking (bank links and account-to-account payments) and grows into everything banking-adjacent: identity verification, account verification (Confirmation of Payee, Verification of Payee) and compliance screening, across jurisdictions, with more than one provider behind each capability. The providers themselves are a marketplace you browse and connect.

MODES

Decide. Your backend sends masked metadata only, such as op, countries, an amount band and a currency, with no personal data and no account numbers. Unirail returns the decision; your backend then calls the provider with its own credentials through the SDK. Unirail never touches secrets or money.

Execute via Unirail. Unirail calls the provider for you, reading credentials just-in-time from your vault. The money still moves between the banks, under your licence and your contract.

The decision engine can be self-hosted.

ROUTES

Ask for a route quote and get up to three: Cheapest, Fastest and Recommended. Each names its legs, its cost, an ETA (p50 and p90), a success likelihood and its custody: who holds the money after every leg.

Today routes are account-to-account with no custody: the money goes from the payer's bank to the payee's. Meta-providers such as Airwallex hold money in transit; their routes appear only where your routing policy allows it.

ADDRESSES

Accounts are payto:// addresses (payto://scan/…, payto://iban/…). Unirail returns them masked, never in full, with a keyed fingerprint so you can tell two accounts apart without seeing either.

APPROVAL

A quote carries an id and a digest of payer, payee, amount, legs and cost. Bind your user's approval, a passkey for example, to that id and digest. If what they approved no longer holds, creating the payment intent fails with quote_changed.

CREDENTIALS

Provider credentials stay in your own Infisical vault. In decide mode Unirail never reads them. In execute mode it reads them per call through OIDC federation, keeps them in memory for that call and never stores them: not in its database, its logs, its traces or its error reports.

EVENTS

One event stream across every rail, delivered as Standard Webhooks: webhook-id,webhook-timestamp and a v1 HMAC-SHA256 webhook-signature. The SDK'swebhooks.verify checks them.

ENVIRONMENTS

Every organisation has test and live environments, each with its own API keys, provider connections and routing policy, managed in the dashboard.

PROVIDERS

3 integrated, 10 listed, 23 countries.

ProviderStatusWhereCustody
PlaidintegratedGBnone
YapilyintegratedGBnone
Enable BankingintegratedGB, 14 euro-area countriesnone
TrueLayerlistedGBnone
NeonomicslistedNO, SE, DK, FInone
AirwallexlistedGB, SG, HK, AU, US, 14 euro-area countriesprovider-transit
NiumlistedSG, GBprovider-transit
Wise PlatformlistedGB, US, 14 euro-area countriesprovider-transit, payer-own-account
BridgelistedUSprovider-transit, provider-for-user
MoneytreelistedJPnone
PayNow QRlistedSGnone
OpenPaydlistedGB, 14 euro-area countriesprovider-transit
Modern TreasurylistedUSplatform-entity, provider-transit

BUGS

The terminal above is a simulation in test mode: quotes, decisions and deals use sample figures, not pricing, and nothing in it moves money. Compliance screening has no provider yet; it is next.

SEE ALSO