Skip to main content

Payment rails

A rail is the infrastructure that actually moves money from one place to another. CashXChain puts the rails behind a single API and a single business workflow, and exposes enough information for finance teams to operate confidently.

Every payout travels on one rail: the one that holds its source account. In production that is our banking partner; in the sandbox it is a simulated bank.

Sending rails (payouts)​

Depending on corridor and currency, a payout reaches the beneficiary as:

  • A domestic bank transfer. SEPA in the EU; Faster Payments, BACS and CHAPS in the UK; ACH, Fedwire and FedNow in the US; EFT in Canada; and further domestic schemes elsewhere.
  • An international wire. SWIFT, where no domestic scheme serves the corridor.
  • Interac e-Transfer. CAD payouts to an email or phone alias.
  • A same-network transfer. A payout to another CashXChain business by its username, settled on our partner's own books.

SEPA Instant is offered only by the sandbox's simulated bank; production pays euro over SEPA.

In the sandbox, a digital-asset account also sends on chain — on its own chain or across chains — to IBANs over SEPA, to US, UK, Mexican and Brazilian bank accounts (ACH or wire, Faster Payments, SPEI, Pix), and to other CashXChain businesses by @handle. Production does not offer stablecoin payouts yet.

GET /v1/banking/corridors says which schemes serve a destination and what the beneficiary needs — see Beneficiaries.

Funding rails (deposits)​

Accounts are funded by:

  • Bank transfer in to the account's own details — SEPA, Faster Payments, ACH, a wire, or the local equivalent.
  • A payment from another CashXChain business.
  • Test funds, in the sandbox only.

Each account's pay-in details are served by GET /v1/banking/accounts/{account_id}/payin-instructions — see Accounts. Money that arrives is listed by GET /v1/transactions. In the sandbox, a digital-asset account is funded with test funds on chain — see Accounts and wallets.

Stablecoins​

Production: no payout or deposit uses a stablecoin. The one stablecoin capability there is opt-in: a settlement policy converts money that arrives by bank transfer into another currency, and that currency may be a stablecoin such as USDC. Each conversion is listed by GET /v1/banking/settlement/intents. Without a policy, money stays in the currency it arrived in.

Sandbox: digital-asset accounts in USDC, EURC, USDT and other stablecoins, with a wallet per chain, held at our crypto-asset service provider. They send on chain and across chains, to bank accounts, by @handle, and swap USDC and EURC; each send can be quoted with its route and held to it. See Digital assets.

The user experience stays fiat-native: amounts are quoted in business currencies, statements are issued in business currencies, and there are no seed phrases, gas tokens, or block confirmations to manage.

Routing​

A payout leaves from the rail that holds its source account. CashXChain checks that the rail supports the currency and is reachable; if it is not, the payout is refused with 503 rather than sent another way.

A payout records the rail's own reference (partner_payment_id); the rail itself is not named. rail appears only when you set one, on a same-network transfer (internal), on a conversion (fx_conversion), and on a digital-asset send (the chain, or the bank scheme). The payout quote shows the cost in advance — see Payouts — and, with a destination, the route the payout would take, which quote_id holds it to: see Quotes and the route lock.

Rail availability​

Rail availability is not uniform. It depends on:

  • The customer's account type, jurisdiction, and KYB state.
  • The currencies the account holds.
  • The beneficiary's country, currency, and bank details.
  • Partner availability and operating hours.
  • Compliance requirements for the corridor.
  • Sandbox vs production — the sandbox simulates rails rather than executing on real infrastructure.

GET /v1/banking/payout-options lists the currencies and countries you can pay. If no rail covers a corridor, the API refuses with an error rather than silently substituting another.

Best practices​

  • Persist the payout id and partner_payment_id for reconciliation.
  • Reconcile against statements, not just payout statuses.
  • Follow each payout to a final status by polling it — there are no payout webhooks today. See Payouts.
  • Ask the corridor before you build a beneficiary form; requirements differ by country, currency and payee type.