> ## Documentation Index
> Fetch the complete documentation index at: https://rheon.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# On/off ramps with cards

> Buy stablecoins with a card, and pay out to a card a user already holds.

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.

| Direction | The user does | Ends as |
| - | - | - |
| **On-ramp (buy)** | Pays by card or Apple Pay on the hosted page, passes 3DS | Stablecoin settled to the wallet and chain you named |
| **Off-ramp (payout)** | Sends stablecoin to the address the quote names | Fiat on the card they already hold |

<Note>
  **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.
</Note>

## Before you start

* An API key, and the `/v1` prefix - see [Authentication](/api-reference/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`](/api-reference/configuration/what-this-key-may-use).
* A country and currency that are actually open. Read them from
  [Card countries](/api-reference/cards/where-a-card-payment-may-not-come-from) and
  [Card currencies](/api-reference/cards/what-a-card-can-pay-in-and-what-it-buys) rather than hard-coding a list.

## Buying with a card

<Steps>
  <Step title="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](/api-reference/cards/display-quote-for-a-card-purchase).
  </Step>

  <Step title="Verify the buyer">
    Cards require [Rheon ID](/concepts/customers-and-identity) 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](/api-reference/cards/verification-token-for-the-buyer).
  </Step>

  <Step title="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](/api-reference/cards/start-a-card-purchase).
  </Step>

  <Step title="Follow it to settlement">
    `POST /v1/card/status` until it settles, or take the [webhook](/webhooks) and
    stop polling. Statuses are listed on
    [Transaction statuses](/transactions/statuses).
  </Step>
</Steps>

<Warning>
  **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.
</Warning>

<Note>
  **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.
</Note>

## 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.

<Steps>
  <Step title="Quote">
    `POST /v1/card/payout/quote` - what lands on the card, and what has to be sent.
    See [Quote a card payout](/api-reference/cards/quote-a-card-payout).
  </Step>

  <Step title="Execute">
    `POST /v1/card/payout` against that quote, with the card the money lands on.
    See [Card payout](/api-reference/cards/create-a-card-payout).
  </Step>

  <Step title="Status">
    `POST /v1/card/payout/status` until the money arrives.
    See [Card payout status](/api-reference/cards/poll-a-card-payout).
  </Step>
</Steps>

<Warning>
  **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.
</Warning>

## What to look up instead of hard-coding

| Question | Endpoint |
| - | - |
| Which currencies can be spent | [Card currencies](/api-reference/cards/what-a-card-can-pay-in-and-what-it-buys) |
| Which countries are open | [Card countries](/api-reference/cards/where-a-card-payment-may-not-come-from) |
| Minimum and maximum per payment | [Card limits](/api-reference/cards/the-card-payment-window-for-a-pair) |
| The rate right now | [Card rate](/api-reference/cards/the-live-buy-rate-for-an-amount) |

## 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](/products/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](/fees).

## Related

* The other way money comes in: [On-ramp](/products/ramps/on-ramp).
* Testing without real money: [Sandbox](/sandbox).