Skip to main content

Payment rails

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

The platform is rail-agnostic by design. Every payment is associated with a route that may use one or more rails — chosen for speed, cost, reliability, and compliance.

Sending rails (payouts)​

CashXChain can deliver a payment through any of the following, depending on corridor, currency, partner availability, and account configuration:

  • Direct bank transfer to the beneficiary. Funds arrive in the beneficiary's bank account. Underlying schemes include SEPA and SEPA Instant in the EU, FPS / Faster Payments in the UK, ACH and Fedwire in the US, and equivalent local schemes elsewhere.
  • International wire. SWIFT and correspondent banking where local rails are not available or appropriate.
  • Local payout networks. Regulated partner networks for local payouts in beneficiary currencies, including markets where bank rails are slow or unavailable.
  • Stablecoin transfer. Direct stablecoin payout to a beneficiary's address on a supported chain, where the beneficiary is set up to receive crypto-asset payouts and the corridor permits it.
  • Same-network transfer. Instant book-transfer between two CashXChain-enabled accounts.

Funding rails (deposits)​

Accounts can be funded through:

  • Bank transfer in. Direct deposit, SEPA, SEPA Instant, FPS, ACH, wire, or equivalent local schemes into the account's funding details.
  • Stablecoin deposit. Inbound stablecoin transfer to a deposit address, where supported and compliant for the account.
  • Internal transfer. Movement from another CashXChain account or wallet under the same customer.

The set of funding methods enabled on a given account depends on jurisdiction, partner configuration, KYB outcome, and product enablement.

On-chain and off-chain​

CashXChain treats both worlds as first-class infrastructure:

  • Off-chain rails are traditional banking and payment-network rails — SEPA, SWIFT, ACH, FPS, local payout schemes, and partner internal ledgers.
  • On-chain rails are blockchain-native rails — stablecoin transfers, on-ramp and off-ramp partners, and supported public chains.

Most payments use a mix. A typical cross-border flow may collect fiat off-chain, settle through a stablecoin rail in the middle, and pay out off-chain through a local partner — all of which is invisible to the business user, who sees a normal payment with a quote, a fee, and a status.

Stablecoins​

Stablecoins serve two roles in CashXChain:

  1. Internal settlement. CashXChain uses regulated stablecoins as a settlement medium between partners and corridors. This unlocks faster, cheaper, and more transparent flows than bank-only routing in many cases. The business user does not need to know which chain or asset is involved.
  2. Customer-facing rail. Where supported and compliant, accounts can fund and pay out in stablecoins directly. This is opt-in — customers who do not want crypto exposure get fully fiat workflows.

Either way, the user experience is 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.

Route selection​

The CashXChain routing engine picks a route per payment using practical criteria:

  • Currency pair and corridor.
  • Required speed, cut-off windows, and partner operating hours.
  • FX quote quality and expected slippage.
  • Total fee and partner cost.
  • Compliance requirements for the corridor and counterparty.
  • Risk score for the customer, beneficiary, and amount.
  • Liquidity and partner availability.
  • Settlement finality characteristics of the candidate rails.

The chosen route is reflected in the FX quote and the resulting payment record, including expected settlement window and fee breakdown.

Rail availability​

Rail availability is not uniform. It depends on:

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

The API surfaces what is available for a given quote or payment. If a requested rail is not available, the API returns a structured error rather than silently substituting a different one.

Best practices​

  • Treat the rail as an outcome of routing, not as something to hard-code in your integration. Accept the route from the quote and persist the payment ID and the partner / rail references for reconciliation.
  • Reconcile against ledger entries and statements, not just payment statuses.
  • Subscribe to webhooks for payment.completed, payment.returned, and settlement.* events to handle rail-level outcomes.
  • Show users the expected settlement window from the quote, not your own estimate.
  • For corridors with multiple candidate rails, request a fresh quote rather than reusing an old one — rail availability and pricing change.