Skip to main content
Buy and sell are two directions on the same ramp primitive. You call POST /v0/ramp/sessions — Sumvin returns a hosted widget URL the user opens to complete payment, and the resulting transaction lands on /v0/ramp/transactions with transaction_type set to CRYPTO_PURCHASE (buy) or CRYPTO_SELL (sell). The user stays inside a single widget for payment capture, any step-up authentication, and on-chain delivery. You observe the outcome by polling the transaction. The on-ramp quickstart walks the full buy flow — quote, create session, poll for settlement — with code samples. Everything here applies to both directions; sell is the same endpoints with the source and destination swapped.

​
When to use each direction

You always send from_asset, to_asset, and chain_id. Sumvin reads which side is fiat and which is crypto, then sets transaction_type accordingly.
Directionfrom_assetto_assetchain_idtransaction_type
BuyFiat (e.g. USD, EUR)Crypto symbol (e.g. SEI, USDC)Chain of the crypto leg (e.g. 1329 for Sei, 8453 for Base)CRYPTO_PURCHASE
SellCrypto symbol (e.g. SEI, USDC)Fiat (e.g. USD, EUR)Chain of the crypto legCRYPTO_SELL
chain_id always describes the crypto leg — the network you are settling crypto on (buys) or debiting from (sells). Discover the assets and chains your integration can use with GET /v0/assets, and check the rampable subset under Supported values.
Some quotes and transactions surface with is_swap: true. That means the upstream provider fulfilled the route by stitching a fiat ramp with a downstream swap rather than a direct route — it widens coverage for pairs no single provider lists end-to-end. The swap is fully managed upstream; from_asset, to_asset, and the fee fields on the response are still end-to-end. No extra integration work is required — surface is_swap to the user only if you want to explain why a particular pair is available.
Sell requires the user to hold enough of the source crypto in the wallet you debit, and to have a fiat destination Meld can pay out to — typically a linked bank account. See Off-ramp for the crypto-to-fiat specifics and Bank linking for account setup.

​
Live coverage

The accepted values for from_asset, to_asset, chain_id, country_code, and payment_method_type are documented in Supported values — invalid inputs are rejected at the API boundary with 422 Unprocessable Entity (enum failure) or 400 with one of RAMP_INVALID_PAIR / RAMP_UNKNOWN_ASSET / RAMP_UNSUPPORTED_ASSET (pair shape or coverage failure). Format-valid pairs still depend on live provider coverage, which changes as service providers adjust their own. Treat GET /v0/ramp/quotes as the source of truth for what a user can actually transact — an empty quotes array means no provider covers that pair at that amount right now. Payment method coverage differs by direction:
  • Buy — commonly CREDIT_DEBIT_CARD, APPLE_PAY, GOOGLE_PAY, ACH, SEPA, BANK_TRANSFER.
  • Sell / off-ramp — commonly ACH, SEPA, BANK_TRANSFER, LOCAL_BANK_TRANSFER. Card rails generally do not support payouts.
Pass payment_method_type on the quote request to narrow the list to one rail. Omit it to let Sumvin return the ranked set.

​
Build the flow

Start with the on-ramp quickstart — it covers the three calls (GET /v0/ramp/quotes, POST /v0/ramp/sessions, GET /v0/ramp/transactions), the status lifecycle, and common failure modes. Swap from_asset and to_asset on the quote and session request to run the sell direction; chain_id stays the same because the crypto leg lives on the same network either way.