Skip to main content
The card rail runs both ways. A buyer spends fiat on a card and stablecoin settles to a wallet, or a user sends stablecoin and money lands on the card they already hold. Card details are entered on a hosted payment page - they never touch your page or ours, so PCI scope stays out of your product.
Provider sandbox on this deployment. Card purchases run against the card provider’s sandbox: no card is charged, nothing settles on-chain, and a purchase never reaches completed there. Every response says which environment answered in its environment field.

​
Before you start

  • An API key, and the /v1 prefix - see Authentication.
  • A destination wallet. The asset and chain a card purchase settles as are fixed per deployment, not chosen per request - read them from GET /v1/config.
  • A country and currency that are actually open. Read them from Card countries and Card currencies rather than hard-coding a list.

​
Buying with a card

1

Price it

POST /v1/card/quote with the fiat currency and the amount the buyer pays.The call is anonymous - no account, no wallet, no identity - so you can show a price before asking the buyer for anything. You get back what they receive, the rate, the provider fee, our markup, and the total.See Quote a card payment.
2

Verify the buyer

Cards require Rheon ID at Tier 2. A buyer already verified to that tier is recognised; otherwise POST /v1/card/kyc-token returns the token that opens verification for them, and the result is shared with the card partner.See Card KYC token.
3

Start the payment

POST /v1/card/purchase returns redirectUrl - the hosted card page. Send the buyer there to enter card details or pick Apple Pay, and to pass 3DS.See Start a card purchase.
4

Follow it to settlement

POST /v1/card/status until it settles, or take the webhook and stop polling. Statuses are listed on Transaction statuses.
Fees are inside the total, not added on top. A total of 100.00 with a providerFee of 7.00 means the buyer is charged 100.00 and 93.00 is converted. Showing the two figures side by side without saying so reads as a surcharge.
Read cryptoCurrency from the response, never assume USDC. The corridor is configurable, and the sandbox settles a different asset than production. An amount printed next to the wrong ticker looks like a broken product.

​
Paying out to a card

Payouts run quote, then execute, then status - the same order as every payout on the platform. The quote holds a rate for a short window, and executing inside that window is what locks it. Nothing moves until the user sends stablecoin to the address the quote names.
1

Quote

POST /v1/card/payout/quote - what lands on the card, and what has to be sent. See Quote a card payout.
2

Execute

POST /v1/card/payout against that quote, with the card the money lands on. See Card payout.
3

Status

POST /v1/card/payout/status until the money arrives. See Card payout status.
Card payouts settle in EUR, GBP and USD only. The on-ramp covers a wider set. Do not infer one direction’s coverage from the other’s.

​
What to look up instead of hard-coding

​
Apple Pay

Apple Pay is part of this product, not a separate rail. It is offered on the hosted page, and a native in-app sheet goes through the API - see Apple Pay.

​
Fees

Both directions return the price before the user commits, and in both the fees sit inside the quoted figure rather than on top of it.
  • Buying with a card - the quote carries the provider fee, our markup, and the total the buyer is charged. What the buyer receives is the total minus those two.
  • Paying out to a card - the quote carries the partner’s fee and your markup, inside the amount the user sends. A flat minimum dominates small payouts, so quote each amount rather than extrapolating a percentage.
How the layers are built, and how your own markup or subsidy is set, is on Fees.
  • The other way money comes in: On-ramp.
  • Testing without real money: Sandbox.