Orders

Take money in on one rail and pay it out on another — in one call.

An order is a pass-through: collect this, then pay that. Accept USDC on Solana and deliver Ghanaian cedis to a mobile money wallet; accept a Nigerian bank transfer and pay out in Kenyan shillings. Chipper handles the inflow, the conversion, and the payout, and reports one lifecycle.

It is deliberately not a payout: nothing leaves your balance until the payer’s money has arrived.

Create

POST /v1/orders
{
  "from": { "code": "usdc_solana", "currency": "USDC" },
  "to":   { "code": "gh_mtn", "accountNumber": "233559630374", "amount": 500, "currency": "GHS" },
  "externalReference": "remit-7781"
}

Exactly one of from.amount / to.amount. The response includes deposit instructions — an address (crypto), or a bank account (fiat) — and an expectedAmount in the inflow currency at the current rate. Show those to the payer.

Lifecycle

awaiting_funds → (awaiting_confirmations for crypto) → funds_received → processing_payout → completed

Every step fires an order.* webhook with the same name. GET /v1/orders/{id} returns a merged timeline across both legs, prefixed Collection: / Payout:.

When the amount isn’t exact

Payers round, wallets skim fees, chains have dust. The order handles it rather than failing:

• overpaid / underpaid are reported as states (and webhooks), and the order proceeds on the actual amount received — recomputing the conversion and paying out what arrived.
• It fails only if the received amount is below the destination method’s minimum (statusMessage: "below_minimum"); the money stays on your balance.
• Nothing arrives before the deadline → expired.

When the payout fails

The inflow is already yours. A failed payout leaves the funds on your balance (order.failed); resolve it with a normal payout later. There’s no refund machinery to manage.

Filters

GET /v1/orders?status=awaiting_funds&origin=USDC&destination=GHS&from=…&to=… — plus GET /v1/orders/by-reference/{externalReference} for your own ids.