Accepting crypto at the point of sale

Accepting crypto at the point of sale means a customer standing at your counter pays in a digital asset — a stablecoin like USDC, or a coin like BTC — and you, the merchant, are credited in euros. The asset the customer sends and the money you receive are two different things, joined by a quote struck at the moment of the tap. Nothing about your till, your books, or your bank account learns that crypto was involved. The terminal shows a euro price, the customer scans a code, and a few seconds later the sale closes in euros — the same line it would have been on a card. Crypto at the point of sale is a payment method, not an accounting change, and keeping it that way is the entire engineering problem.

That framing is worth stating first, because most confusion about crypto payments comes from fusing two questions that should stay apart: how the customer pays, and what currency the merchant keeps. Split them and the rest of this follows.

The problem it actually has to solve

A merchant wants the sale, not the volatility. They do not want to end the day holding a bag of assets at an uncertain value, and they do not want their bookkeeper suddenly speaking two currencies. They want the price fixed between the tap and the receipt, the money in euros, and reconciliation that looks like every other card day. A shop that accepts crypto naively gets none of that: it takes an asset whose price moves while the customer is still deciding, parks it in a wallet, and inherits a second currency in its accounts that someone now has to value and convert by hand. So the design goal is narrow and strict — make the crypto visible in exactly one place, the payment moment, and invisible everywhere else.

One tap: a QR, a locked quote, a euro line

Walk the counter flow. The cashier rings up a €24.00 basket. The terminal shows the euro total and renders a QR code that encodes the request — the amount, a destination address or invoice, and a short-lived quote id. The customer scans it with their own wallet, sees exactly what they are about to send, and confirms. The terminal watches the network for that transfer and, on confirmation, prints a receipt in euros. From the cashier's side the rhythm is identical to a card: total, present, approve, receipt. Nobody behind the counter types an address or reads a balance in anything but euros.

Putting the request inside the QR is what makes it safe to hand to a stranger's phone. The amount and the destination travel in the code, checksummed, so the customer cannot pay the wrong address or the wrong amount by mistyping — the same move as identity-by-construction on the collections side, applied to a counter. A code that scans is a code that is correct; there is no free-text field to get wrong.

Settling to euros, so the books never learn crypto

Between the asset the customer sends and the euros the merchant keeps sits conversion, and where it sits is the whole trick. The customer sends USDC or BTC; the platform converts and credits the merchant's account in EUR. The merchant's ledger only ever sees a euro credit and a euro fee line — the same shape as a card settlement — because the asset is converted at the platform, not left in a wallet the merchant now has to manage. End of day, the books are euros end to end. There is no basket of coins to mark to a value, no second currency in the accounts, and nothing to off-ramp on Monday morning.

The customer's job is to pay in whatever they hold. The merchant's job is to keep books in one currency. A point of sale that settles crypto to euros is just the machine that keeps those two facts from ever meeting.

— Protocore · Payments engineering

The rate is locked, not chased

Volatility is the fear, and a locked quote with a countdown is the answer. When the terminal shows the euro price it also strikes a quote valid for a stated window — a handful of seconds. The customer pays inside that window, against that quote, and the euros the merchant is credited are the euros on the screen, not whatever the market did while the wallet loaded. If the window lapses before the customer confirms, the terminal re-quotes: a new code, a fresh countdown, an explicit new price — never a silent drift. The merchant is never exposed to the move between tap and confirmation; that risk sits with whoever struck the quote, not with the shopkeeper who just wanted to sell a coffee.

When the customer is slow, or the terminal is offline

Networks stall and shops lose connectivity, so the offline behaviour has to be boring on purpose. Two cases. When the customer is slow, the quote simply expires and re-quotes — a payment either confirms inside a window or it does not happen, and there is no half-finished sale to unwind. When the terminal itself drops offline, it can still display a request for a known amount, but it cannot strike a fresh quote or confirm settlement, so it holds the sale as pending and reconciles when it reconnects rather than pretending success. The governing rule is that the receipt prints on confirmation, never on hope: a euro receipt means the euros are accounted for, and a sale the terminal could not confirm stays open and visible in the operator console instead of quietly vanishing.

Where the terminal meets the gateway

The counter is the in-person face of the same acceptance stack that runs online. A card-present crypto tap and a pay-by-link checkout are the same event underneath — a request, a payment, a euro settlement, a receipt — presented on different surfaces. So a merchant reconciles in-store crypto and online orders in one place, in euros, with the same fee lines and the same exports, instead of running two books that have to be stapled together at month-end. The terminal is at /products/pos; the online side of the same rails is /products/gateway; and the vocabulary — quote, settlement, acquirer, reconciliation — is defined in the /glossary.

The honest boundary

If nobody at your counter wants to pay in crypto, a crypto terminal is a solution to a problem you do not have — take cards and move on. It earns its place where a real slice of your customers already hold digital assets and would rather spend them than off-ramp first: certain travel corridors, certain online-native crowds, certain regions where stablecoins are simply how people hold spendable money. In those rooms, refusing the tap is refusing the sale. The mechanics above — the QR, the locked quote, settlement to euros, the confirm-before-receipt rule — are what let you take that sale without taking on the volatility, the second currency, or a bookkeeping project. The crypto stays the customer's concern; the euros stay yours.