How On-Ramps Work Under the Hood
The Buy button in a wallet is somebody else's product, wired in through an SDK. What happens between your tap and your coins is four systems handing work to each other on a clock.

TL;DR
- A wallet does not sell you crypto. It embeds a provider's widget or calls its API, and the provider carries the licensing, payments and identity work.
- Four systems have to agree: identity, payment authorisation, liquidity sourcing and blockchain settlement. Each can fail independently.
- Quotes expire because the provider has taken price risk between your tap and the trade, usually holding it open for a couple of minutes.
- Orders move through states rather than completing at once, which is why the wallet says pending while your card statement already shows the charge.
Press Buy inside a wallet and something faintly odd happens: the screen changes character, with different fonts, a different flow and a request for a photograph of your passport. You have left the wallet and entered somebody else's product without meaning to.
This piece is about that other product and the machinery behind it, which is worth understanding both if you are integrating one and if you just want to know why the thing behaved as it did, and it is an educational guide, not financial advice.
Why the wallet is not selling you anything
Selling crypto for currency means holding money-transmission permissions in every market you serve, maintaining banking relationships, running identity and financial-crime programmes, and carrying the fraud losses when a card payment turns out to be stolen. That is a business, and it is a different business from making a wallet.
So wallets integrate rather than build, and the provider supplies a hosted widget, a software development kit or a straight API, and takes on the regulated part. The wallet gets a Buy button and keeps its users. This division is why the same three or four provider names appear behind an enormous number of unrelated apps.
The four systems that have to agree
Identity comes first, and a first-time buyer is verified before anything moves: document, selfie, sanctions and politically-exposed-person screening, and sometimes source-of-funds questions above certain amounts. This is why a first purchase can take 10 minutes and later ones take seconds. Where the integration allows it, verification can carry across apps that use the same provider, so a user already known to it is not asked twice.
Payment authorisation is next, and the card or bank rail runs its own checks. The issuer decides independently whether to approve, and a decline here is a decision taken inside your bank rather than by the provider or the wallet.
Liquidity follows, and the provider has to actually obtain the coins, from exchanges, market makers or its own inventory. The price you were shown includes the spread it needs to do that without losing money on the trade.
Settlement is the last of them, and the coins are sent to your address on the network you chose. Once broadcast, this step is outside everyone's control and takes exactly as long as the network takes, which might be 2 seconds on Solana and 30 minutes on Bitcoin at a busy moment.
Any of the four can fail without the others knowing much about it, which is why a failure can be hard for support to explain quickly.
Why the quote has a countdown
When a price appears with a timer on it, the provider has committed to a rate before it has bought anything. It carries the market risk in that window, and the window is short for the same reason a bureau de change does not honour yesterday's board: prices move.
Around 2 minutes is typical, and some providers hold a stablecoin quote for 5 while cutting a volatile pair to 60 seconds. Let it expire and you are re-quoted, because the old number was a promise the provider is no longer able to keep at the same cost. The spread inside the quote is partly payment for carrying that risk, which is why quotes on volatile pairs are held for less time than quotes on stablecoins.
Order states, and why your statement disagrees with the app
An order does not complete, it progresses through a typical sequence of 7 states: created, awaiting payment, payment received, verification passed, coins purchased, transaction broadcast, confirmed. The integrating app is told about these transitions through webhooks, which is how a wallet knows to update its screen without you refreshing anything.
This explains the most common support message in the industry. Your card statement shows a charge the instant the payment leg completes, while the wallet still says pending because the settlement leg has not finished. Nothing is wrong: two systems are reporting two different stages of the same order, and only one of them is looking at the blockchain.
What this changes for you
A decline is usually your bank. The provider passed the request on and received a no. Ringing the issuer resolves this far more often than retrying does.
The network selector matters more than the coin selector. Settlement goes to the address on the chain you picked, and a mismatch with your wallet is the one error nobody downstream can fix.
Prices differ between providers for real reasons. It comes down to different liquidity sources, different payment costs and different risk appetites, and none of it is arbitrary.
Keep the order ID. It is the key that ties the four systems together, and support in any of them will ask for it first.
None of this is glamorous: it is a payments business wearing a crypto hat, and most of what feels strange about buying crypto is the ordinary awkwardness of moving money between regulated systems that were never designed to talk to each other.
Frequently Asked Questions
Because it belongs to a different company. Wallets embed an on-ramp provider's widget or SDK rather than building the regulated business themselves, so pressing Buy usually hands you to the provider's own interface for the payment and identity steps before returning you.
The provider commits to a rate before it has bought the coins, so it carries the market risk during that window. Two minutes is typical. When it lapses you are re-quoted because the original price was a promise the provider can no longer keep at the same cost.
Two systems reporting two stages of one order. The payment leg completed, which is what your statement reflects, while the settlement leg has not finished broadcasting or confirming on the blockchain. This is the most common support question in the industry and usually resolves itself.
Not always. Where apps share the same on-ramp provider and the integration supports it, an existing verified user can be recognised rather than re-checked. Across different providers you will generally verify again, since each carries its own regulatory obligations.
Different liquidity sources, different payment-method costs and different risk pricing. A provider sourcing from a deeper market or accepting a cheaper payment rail can quote tighter. The rail you choose usually moves the total more than the choice of provider does.
