Parallel acceptance: taking crypto beside your POS

What parallel acceptance is

Parallel acceptance means you take a crypto payment next to your register instead of through it. The customer pays a separate wallet or scans a QR code, and the money lands in your crypto wallet. Your point-of-sale system is not part of that transaction at all. It does not create the payment request, it does not confirm the payment, and it does not know the sale happened unless a person tells it.

People sometimes call this the "beside-the-register flow." It is a legitimate, widely used way to accept crypto, and for a lot of small businesses it is the only setup that makes sense. But it is not an integration, and calling it one would set the wrong expectations for your staff and your books.

What it is not

It is not native support, and it is not an official or third-party integration. With those, the sale flows back into your POS and appears in your reports. With parallel acceptance, none of that happens automatically. That single difference drives almost everything below.

Why the POS is not involved

Your register is designed around card and cash tenders it controls. A crypto wallet or a printed QR code sits outside that system. So the payment can be perfectly successful while your POS shows nothing, because the two never talked to each other. This is why we never describe parallel acceptance as "working with" a POS without the qualifier that the POS is not involved.

Static QR versus dynamic invoice

There are two common ways to present the payment, and the difference matters:

• Static QR. One fixed address, the same for every sale, often on a printed or laminated card. The customer types in the amount themselves. It is the cheapest and simplest option, but because the customer enters the amount, someone has to check that the right amount actually arrived before handing over goods.
• Dynamic invoice QR. A fresh code generated for each sale with the amount already set. The customer just confirms. It removes the wrong-amount risk but needs a device and an app to generate each code.

Manual amount entry and double-entry risk

With a static QR, the amount is entered by hand, so mistakes happen: a customer fat-fingers the total, or pays the pre-tax figure. Build in a quick check of the received amount as part of your routine. And because the sale does not flow into the POS, someone also has to key it into the register separately, which is a second manual step and a second chance for the numbers to drift apart.

How the sale gets into the POS

Most registers let you record a sale under a custom or "other" tender type. The usual approach is to ring the sale as normal, mark it paid under a crypto or "other" tender, and keep the wallet's transaction record so the two can be matched later. Whether your specific POS offers a custom tender type is something to confirm on your own system; we will not assume it here.

Confirmation

Before the customer leaves, confirm the payment actually arrived. On-chain payments may take a moment to show as received, and payments over the Lightning Network are typically near-instant. Decide in advance how long you are willing to wait and what you do if a payment is slow, so a cashier is never guessing at the counter.

Tips, tax, discounts, and partial payments

Because the register is not driving the payment, the niceties it normally handles are on you. Tax still applies to the sale and should be part of the total you collect and record. Tips, discounts, and split or partial payments are not handled by the crypto flow itself; you work them into the amount you request. If your business depends on any of these at the point of sale, parallel acceptance will feel clumsy, and that is worth weighing honestly.

Refunds

Crypto payments do not have a card-style reversal. A refund is a fresh payment you send back to the customer, which means confirming their address, deciding how you handle exchange-rate movement between the sale and the refund, and documenting it. Have a written refund rule before you need one.

For the full walkthrough, see how to refund a crypto payment.

Reconciliation

At close, the crypto sales you rang into the register need to match the payments in your wallet. This is a manual matching step, and it is the recurring cost of parallel acceptance. Keeping a simple running log of crypto sales makes it painless; skipping it makes month-end miserable. Our accounting guidance covers a clean routine.

Security

If funds land in a wallet you control, you are responsible for protecting it. Use a hot wallet for daily takings and sweep to more secure storage on a schedule. The Merchant Security Playbook covers the practical routine.

Who this fits well

• Low-to-moderate volume businesses where a few crypto sales a day is realistic.
• Merchants with no POS at all, or a very simple one.
• Mobile and outdoor sellers: markets, fairs, food trucks, pop-ups.
• Anyone testing crypto cheaply before committing to anything more involved.

Who should probably skip it

• High-volume, fast-line businesses where a manual confirmation step would back up the queue.
• Table-service restaurants where payment has to attach cleanly to a check.
• Operations that need every sale to appear in POS reports automatically for staffing, inventory, or franchise reporting.

When we recommend not using it

If crypto would be a rare request and the manual reconciliation would cost you more time than the sales are worth, the honest answer is to wait. A method being possible does not make it worthwhile. If only a handful of customers will ever ask, a single laminated QR card, or simply not offering it yet, may be the right call.