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

# Selling crypto (off-ramp)

> The in-widget off-ramp flow: destination account book, network and deposit, payout, and the QR versus auto-redirect behaviour.

The off-ramp turns the user's crypto into local currency paid into a bank account they nominate. The account they choose is the part that most often needs attention, so the widget keeps a reusable list of them.

### The flow

<Steps>
  <Step title="Choose an amount">
    Quoted and refreshed the same way as the on-ramp.

    <img src="https://mintcdn.com/ripio-9dfd4837/08vkB56X36FZiua_/ramps-api/widget/assets/widget-offramp-amount.png?fit=max&auto=format&n=08vkB56X36FZiua_&q=85&s=16da64591d9ad72af679120796e8f981" alt="Off-ramp amount entry with the quote" width="644" height="1082" data-path="ramps-api/widget/assets/widget-offramp-amount.png" />
  </Step>

  <Step title="Choose where the money should land">
    The user picks one of their saved destination accounts, or registers a new one.
  </Step>

  <Step title="Choose a network and deposit the crypto">
    The widget shows a deposit address for the chosen network.
  </Step>

  <Step title="Ripio sells and pays out">
    Once the deposit confirms, the crypto is sold and the local currency is sent to the destination account.
  </Step>
</Steps>

### The destination account book

Saved accounts persist across sessions, so a returning user sells in a few taps.

<img src="https://mintcdn.com/ripio-9dfd4837/08vkB56X36FZiua_/ramps-api/widget/assets/widget-offramp-account-book.png?fit=max&auto=format&n=08vkB56X36FZiua_&q=85&s=e3871cb088a786f86b37e2b627369f03" alt="The destination account book listing a saved account" width="676" height="1122" data-path="ramps-api/widget/assets/widget-offramp-account-book.png" />

What a new account requires depends on the country:

| Country | What the user provides |
| - | - |
| Argentina | Alias, CBU or CVU |
| Mexico | CLABE, validated asynchronously with the bank |
| Colombia | A BRE-B key, or full bank account details |
| Brazil | A PIX key — only the key. The holder is resolved from it |

Every account carries a status, and only an `enabled` account can receive a payout. The widget marks the others as unselectable and says why:

| Status | What it means for the user |
| - | - |
| `enabled` | Ready to receive a payout |
| `unconfirmed` | Registered, waiting for the user to confirm it |
| `processing` | Being validated with the bank |
| `suspended` | Superseded by a newer account for the same payment method |
| `revalidation_required` | Needs to be checked again before it can be used |
| `disabled` | Not usable. In Brazil this is the key that belongs to someone else — see below |

#### Brazil: the key's holder is shown before the account is saved

A Brazilian PIX key is resolved to its account holder while the form is being submitted, so the widget can show the user **whose account they are about to be paid into** — name, tax ID and bank — and ask them to confirm it. Nothing is asked about the holder up front: the single key field is the whole form.

The holder must be the user themselves. When the key belongs to somebody else, the widget shows that same screen with the resolved holder's details, explains that the destination has to be an account in their own name, and lets them go back and try another key. The account is saved as `disabled` and cannot be confirmed.

Two other keys are rejected on the field itself, each with its own message: one that no bank has registered, and one that exists but is not active yet at the user's bank (a key still being claimed at BACEN, or a cancelled one). See [Brazil](/ramps-api/overview/countries/brazil) for the formats a key can take and the errors the API answers with.

<Note>
  The authoritative rules — including the one-active-account-per-payment-method constraint and how a suspended account comes back — are in [Fiat account lifecycle](/ramps-api/fiat-accounts/lifecycle). The widget surfaces those rules; it does not change them.
</Note>

<Warning>
  Bank-side validation is asynchronous and can be slow. Colombia BRE-B in particular can take up to an hour to resolve. The widget waits about 5 minutes and then tells the user it will email them when the account is ready, rather than blocking the flow.
</Warning>

### How the user gets back to you

Decided by whether the QR deposit screen is enabled on your account:

* **Not enabled** — the widget redirects to your URL as soon as the sale is confirmed, with transaction parameters appended. The user never sees a deposit screen, so you are expected to send the crypto on their behalf.
* **Enabled** — the widget shows the deposit address and a QR code so the user sends the crypto themselves, plus a button back to you.

Ask your Ripio contact which of the two your account uses.

Both forms append the full parameter set. See [Returning to your app](/ramps-api/widget/get-started/returning-to-your-app).

### What your backend observes

`OFF-RAMP.DEPOSIT.RECEIVED` → `OFF-RAMP.TRADE.COMPLETED` → `OFF-RAMP.WITHDRAWAL.PROCESSING` → `OFF-RAMP.WITHDRAWAL.COMPLETED`

A payout that cannot be delivered arrives as `OFF-RAMP.ORDER.CANCELLED`, and what you can do about it depends on `refundable` — see [Recovering a rejected payout](/ramps-api/widget/flows/order-recovery). Full payloads are in [Off-Ramp Webhook Events](/ramps-api/webhooks/off-ramp-events).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.