Skip to main content

How CashXChain works

CashXChain turns complex payments into a simple business workflow. The hardest cases — cross-border and multi-currency — drive the design, but the same workflow scales down to local and same-currency payments.

A customer creates an account, completes onboarding, registers a beneficiary, prices the payment, submits it, and follows it to settlement. Behind that simple workflow, CashXChain checks the instruction against the corridor, the plan's limits and the account's verification, and sends it to our regulated banking partner.

Three-layer model​

CashXChain is designed around three layers.

1. Client layer​

The client layer is the interface used by businesses and platforms. It can be the CashXChain dashboard, a platform acting for its customers with a master key, or your own system calling the API.

The client layer captures business intent:

  • Who is paying?
  • Who is receiving?
  • What amount and currency should move?
  • What is the purpose of payment?
  • What invoice, order, or internal reference should be attached?

2. Instruction and orchestration layer​

The CashXChain backend validates the request, checks that the account and beneficiary belong to the caller, applies plan limits, verification and the payee-name check, records the payout, and prepares the partner's instruction.

This layer does not require the end user to understand which rails are involved. It presents a unified payment workflow and records each payout's status changes.

3. Partner execution layer​

Regulated partners perform regulated activities where required. Depending on corridor, currency, customer type, and payment method, this can include holding funds, collection, local payout execution, AML screening, sanctions screening, Travel Rule obligations, and final settlement.

CashXChain tracks the partner execution lifecycle and normalizes the result back into a consistent payment status model.

Example payment flow​

  1. A German SME wants to pay a supplier in Kenya.
  2. The SME asks what a Kenyan beneficiary needs, registers the supplier, and has the receiving bank's name check run where the corridor has one.
  3. The SME prices the payout — or locks an FX rate with a quote — and sees what leaves its account.
  4. The SME submits the payout with an idempotency key, so a retry can never pay twice.
  5. CashXChain validates the instruction against the corridor, the plan's limits and the account's verification, and routes it to the rail that holds the account.
  6. A regulated partner performs required checks and executes the payment.
  7. The payout moves from submitted through processing to settled; the SME follows it by its id.
  8. The SME issues a statement and reconciles the payment against the invoice.

The same flow as runnable calls is the Quickstart.

Invisible blockchain​

Invisible blockchain is the design principle behind the product: a business user sees currencies, balances, quotes, references, statements, and counterparties — never gas, keys, or transaction signing. In production every payout travels on bank rails today. In the sandbox, digital-asset accounts hold stablecoins in wallets our crypto-asset service provider keeps, and send through the same payout API: the business names an amount and a destination — an address, an IBAN, a bank account or another business's @handle — and the provider signs and executes.

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. See Rails.