Buy now, pay later spent its first decade as an online product. The button sat under the cart total, the approval happened on a phone or laptop, and the merchant never had to change a single thing about its physical stores. That changed once Affirm, Klarna, Afterpay, PayPal and Sezzle each decided that the roughly four out of five retail dollars still spent in physical stores were worth chasing. Getting there meant rebuilding the product around a card terminal, a queue and a cashier who has forty seconds to explain it.
This guide walks through how in-store BNPL actually works at the physical checkout: the three plumbing options providers settled on, what a point-of-sale integration involves, what staff get asked, where the queue slows down, and what happens to a return once the plan is running.
In short
- Three flows dominate: a QR code the shopper scans at the terminal, a virtual card the provider loads into Apple Pay or Google Pay, and an in-app one-time barcode or card. Most US volume now runs on the virtual-card path because it needs no POS change at all.
- Virtual cards ride the card networks: the terminal sees a Visa or Mastercard debit or prepaid transaction, which is why the merchant pays interchange-level fees on that path rather than the online BNPL rate.
- Integrated flows cost more to build but give the merchant the data: a native tender type on the POS reports BNPL as BNPL, supports partial refunds cleanly and lets staff see the plan status at the till.
- The queue is the hidden cost: a first-time in-store BNPL approval can add 60–120 seconds against a 5–8 second tap; repeat users add almost nothing. Staff scripting decides which of those two numbers a store gets.
- Refunds follow the rail, not the storefront: a virtual-card purchase is refunded like a card and the provider adjusts the plan; an integrated purchase is refunded through the provider’s API. Both cases need a policy for what the shopper sees while the money is in flight.
Why in-store pay later took longer to arrive
The online version of BNPL was simple to distribute. The provider shipped a JavaScript snippet or a platform app, the merchant pasted it in, and the underwriting, identity check and payment happened on the provider’s own pages. Nothing about that model transfers to a terminal that speaks EMV, prints receipts and expects to be certified by an acquirer before a new tender type can appear on it.
The economics also looked worse. Online, the provider justified a 4–6 percent merchant fee by claiming it brought incremental orders and a larger basket. In a store the shopper is already standing there with the item, so the incrementality argument is weaker and merchants pushed back on paying the online rate. For a breakdown of what each rail charges, see our comparison of BNPL merchant fees against card and wallet costs.
The app was on the wrong side of the counter
Online, the provider owns the checkout screen and can ask for a phone number, date of birth and the last four digits of a Social Security number without anyone finding it strange. At a physical till, those questions have to happen on the shopper’s own phone, in the shopper’s own app, before the cashier ever gets involved. That forced every provider to make the consumer app the center of the in-store product, rather than the merchant’s checkout.
Card networks solved it before the POS vendors did
The breakthrough was not a POS integration at all. Once Apple Pay and Google Pay could hold a provider-issued virtual card, the BNPL company could issue a single-use or reloadable card number in the shopper’s wallet and let the existing contactless terminal do the rest. Affirm, Klarna, Afterpay, Sezzle and Zip all ship a version of this today, and it is the reason a store with no BNPL contract at all can still see BNPL-funded purchases in its card settlement. Our guide to how retail payments are changing across cards, BNPL and crypto covers how that convergence between BNPL and the card networks is playing out more broadly.
The three flows: QR code, virtual card and in-app
Every in-store BNPL product on the US market today is one of three flows, sometimes offered side by side by the same provider. They differ on who has to build what, which rail the money moves on, and what the merchant can see afterward.
Flow one: the QR code at the terminal
The POS or the payment terminal displays a QR code that encodes the basket total and a transaction reference. The shopper scans it with the provider’s app, sees the installment schedule, confirms, and the provider posts an approval back to the POS through an API. The cashier sees the tender close out like any other and the receipt prints the provider’s name. Klarna’s and Afterpay’s own in-store products both work this way when the merchant is integrated, and Adyen, Stripe Terminal and Worldpay all expose a version of it to their in-store merchants.
The QR flow gives the merchant the most control: the BNPL transaction is a distinct tender type, refunds go back through the same reference, and reporting separates BNPL from cards. The cost is that the POS vendor or acquirer has to support it, which for a mid-market retailer on an older terminal estate can mean a certification project rather than a settings change.
Flow two: the virtual card in the wallet
The shopper opens the provider’s app, requests an in-store purchase, and the provider either issues a one-time virtual card for a stated amount or activates a standing card that already lives in Apple Wallet or Google Wallet. The shopper then taps the phone on the contactless reader. The terminal sees a Visa or Mastercard transaction on a debit or prepaid BIN; it does not know that BNPL is involved. Affirm Card, the Klarna Card, the Afterpay Card and Sezzle’s virtual card all follow this model, and it is the flow most likely to be in use when a store reports BNPL purchases it never signed up for.
The trade-off is the mirror image of the QR flow. Nothing needs to change on the merchant side and the fee is whatever the card acceptance agreement charges, which is usually lower than an integrated BNPL rate. In exchange, the merchant gets no BNPL-specific data, cannot see the plan at the till, and handles refunds as ordinary card refunds with the provider adjusting the installment schedule on its side afterward.
Flow three: the in-app barcode or one-time code
A minority of programs still use a barcode or numeric code generated in the app and scanned or keyed by the cashier, often where a retailer has a house financing program that predates the wallet era or where the checkout is on a handheld device rather than a fixed terminal. PayPal’s in-store Pay in 4 experience has cycled through variants of this, and some big-box financing programs still run a code-based flow. It works, but it is the slowest of the three at the counter and the most dependent on staff knowing what to do.
| Attribute | QR code at terminal | Virtual card in wallet | In-app barcode or code |
|---|---|---|---|
| Merchant build required | POS or acquirer integration, certification | None | POS must accept and route a code; sometimes a barcode scan step |
| Payment rail | Provider’s own settlement | Card network (debit or prepaid BIN) | Varies; usually provider settlement |
| Fee basis | Negotiated BNPL rate | Card acceptance rate | Negotiated BNPL rate |
| Visible as BNPL in reporting | Yes | No, appears as a card | Yes |
| Refund path | Provider API, same reference | Card refund; provider adjusts plan | Provider API or manual |
| Typical added time at counter (repeat user) | 10–25 seconds | 5–10 seconds | 20–40 seconds |
| Who sees the plan at the till | Cashier (via POS) and shopper | Shopper only | Shopper; cashier sees a code |
What the POS integration actually requires
Retailers who want the QR or native flow, rather than passively accepting virtual cards, face a build. How big a build depends on who sits between the terminal and the provider. Our overview of what to look for in a modern POS system sets out the general landscape; the section below is specific to pay later.
Acquirer-led versus provider-led integration
The path of least resistance is acquirer-led. If the store already runs on Adyen, Stripe Terminal, Worldpay, Fiserv or a similar unified acquirer that has BNPL providers pre-integrated, adding Klarna or Afterpay at the terminal can be an account-level enablement plus a tender-type mapping in the POS. The acquirer has already done the certification work; the merchant’s job is contracts, reporting and staff.
Provider-led integration means the retailer’s POS vendor, or its own engineering team, connects directly to the BNPL provider’s in-store API. This is the model for retailers on a custom or legacy POS, or those who want a specific provider their acquirer does not carry. Expect a scope that includes generating and displaying the QR payload, polling or receiving a webhook for approval, handling timeouts and cancellations at the terminal, mapping the result to a tender, and building refund and partial-refund calls. Six to twelve weeks is a realistic range for a chain with a modern POS; longer if terminal firmware has to be touched.
Tender types, receipts and end-of-day
The detail that most often gets missed in scoping is what happens after the approval. The POS needs a distinct tender type so that BNPL sales do not land in the cash or card buckets, receipts need to identify the provider and, in most programs, print a plain-language note that the customer has entered an installment agreement with a third party, and end-of-day reconciliation has to expect settlement from the provider on its own schedule rather than with the card batch. Retailers who skip the tender-type step usually discover the problem in finance when the settlement file does not match the drawer.
| Integration path | Typical fit | Effort | Provider choice | Data and refund control |
|---|---|---|---|---|
| Passive virtual-card acceptance | Any store with contactless | None | Whatever the shopper carries | None; card-level only |
| Acquirer-enabled BNPL tender | Stores on a unified acquirer with pre-integrated providers | Low: enablement, tender mapping, receipt text | Limited to acquirer’s roster | Full, through acquirer reporting |
| Direct provider API on modern POS | Chains with in-house or vendor-supported POS | Medium: 6–12 weeks | Any provider with an in-store API | Full, merchant-owned |
| Static QR plus manual amount | Small stores on standalone terminals | Very low | Provider that offers static codes | Partial; reconciliation is manual |
Staff training and the questions customers ask at the till
Online, the provider answers the customer’s questions on its own screens. In a store the cashier does, and the answers a cashier gives can create legal and reputational exposure for the retailer that the online version never carried. Training is therefore less about the mechanics of the flow and more about the boundaries of what staff should say.
The five questions that come up most
Store teams that have run in-store BNPL for a year or more report a stable cluster of questions. The first is whether it costs anything, where the correct answer is that the pay-in-four products are typically interest-free if paid on time but longer plans may carry interest, and that the terms are shown in the app before the shopper confirms. The second is whether it affects a credit score, which staff should not answer beyond directing the shopper to the provider’s own disclosures, because the answer differs by provider and by product and has changed as bureaus began accepting BNPL data. The third is what happens if a payment is missed; again, the provider’s terms govern and staff should not paraphrase them.
The fourth question is whether the shopper can use it today with no account, and the honest answer is that a first-time user will need a few minutes to sign up in the app, so a store that is busy may want to offer to hold the items. The fifth is what happens on a return, which is the question staff most often get wrong and which deserves its own section below.
What staff should never do
Cashiers should not handle the shopper’s phone, should not enter personal information on the shopper’s behalf, and should not describe the product as “free” or “no credit check” unless the provider’s own materials use exactly those words. A one-page script, reviewed by whoever handles the retailer’s compliance, prevents most of the problems. It is worth reading how the major providers position themselves in our comparison of Klarna, Afterpay and Affirm for US merchants, because the words each one uses in its own marketing are the safe words for staff to repeat.
Signage, prompts and the first-time user
The highest-friction moment is a shopper who has heard of pay later, has no account and is now at the counter with a line behind them. Retailers who have handled this well moved the discovery earlier: shelf-edge or fitting-room signage with a QR code that opens the provider’s sign-up, prompts on the store’s own app, and a script that lets the cashier suggest setting up the account before the shopper joins the queue. A store that only mentions BNPL at the terminal will experience it as a slow product, because it is only ever seeing first-time sign-ups under time pressure.
Queue time, approvals and declines at the counter
Online, a slow or declined BNPL approval costs a conversion. In a store it costs the conversion and the patience of everyone in line. The queue is the number most retailers underestimate when they model the channel, and it is worth breaking down where the seconds go.
Where the seconds go
For a repeat user with the provider’s app installed and a card already in their wallet, the added time over a standard contactless tap is small: a few seconds to open the app and request the purchase, then a tap. For a repeat user on a QR flow it is slightly more, because the shopper has to open the app, scan, review the schedule and confirm. For a first-time user, the account creation, identity verification and underwriting step can take anywhere from one to several minutes, most of it spent typing on a phone. A retailer that sees a 60–120 second average added time is almost certainly looking at a first-time-heavy mix, and the fix is upstream of the terminal.
Approval rates and soft declines
In-store approval rates track online rates for the same provider and the same customer, with one difference: the item is physically present, so the provider has stronger evidence of the purchase and, for some categories, better fraud signals. Declines still happen, and how they are surfaced matters. A decline on a virtual card looks to the cashier like any card decline, with no reason code that means anything to the store. A decline on an integrated flow may return a reason category, but staff should not read it aloud; the shopper’s own app will explain, and the cashier’s job is to offer another tender without comment.
Partial approvals and split tenders
Some providers approve a lower amount than requested, especially for a new customer or a large basket. Whether the POS can accept a BNPL tender for part of the total and a card for the rest is an integration decision that has to be made up front. Split tender support is standard on modern POS software but is often not enabled for a new tender type by default, and a store that cannot split will turn a partial approval into a full decline. The effect of that on conversion is discussed in our analysis of how BNPL actually affects retail conversion rate; the in-store version of the finding is that a split-capable checkout keeps the sale far more often than one that forces an all-or-nothing choice.
Returns and refunds when the plan is already running
This is where in-store BNPL diverges most sharply from cards, and where staff and finance teams need a written policy before launch rather than after the first complaint. The core problem is timing: a shopper who bought on a four-installment plan and returns the item a week later has paid one installment, owes three more, and now wants to know why the refund is not simply “the money back.” The full mechanics for online orders are set out in our explainer on BNPL refunds and disputes when an order goes wrong; what follows is the in-store layer on top.
Refunds on the virtual-card path
If the original purchase came in as a virtual card, the store refunds it as a card. The refund goes back to the card number that was used, which is the provider’s card, and the provider then reduces or cancels the remaining installments and returns any installments already paid to the shopper’s funding source. The store’s involvement ends at the card refund. The shopper’s experience, however, includes a lag of several days between the store saying “refunded” and the provider reflecting it, and staff should say plainly that the pay-later provider will update the plan and return any paid installments on its own timeline.
Refunds on the integrated path
For QR or native-tender purchases, the refund goes through the provider’s API against the original transaction reference. Full refunds are simple. Partial refunds, where the shopper returns one item from a multi-item basket, require the provider to recompute the remaining schedule, and how each provider does that (reducing the last installments first, or spreading the reduction) is set in the provider’s terms rather than by the store. Staff need to be able to say that the plan will be adjusted, not restated, and that the shopper’s app is the source of truth for the new schedule.
Exchanges, store credit and the dispute path
Exchanges for a different item of the same value are usually handled as a refund and a new purchase, because most providers cannot re-point an existing plan at a new basket. Store credit is the difficult case: issuing store credit for a BNPL purchase leaves the shopper still paying installments for an item they no longer have, with credit they may not use for months. Many retailers exclude BNPL purchases from store-credit-only return policies for exactly this reason. Disputes follow the rail too: a virtual-card purchase can be disputed as a card chargeback, while an integrated purchase goes through the provider’s own dispute process.
Measuring whether in-store BNPL added sales
The question a CFO will eventually ask is whether the program paid for the fee and the build. Answering it in a store is harder than online, for the simple reason that the store’s best-distributed flow, the virtual card, is invisible in the store’s own data. A serious measurement plan has to deal with that before anything else.
Start by finding the volume you cannot see
Ask the acquirer for a BIN-level breakdown of debit and prepaid transactions, or ask the BNPL providers directly for the store’s virtual-card volume. Most will share it for a partner merchant, and the number often surprises: retailers routinely discover that BNPL-funded volume on the card path is a multiple of what the integrated tender reports. Without that figure, any incrementality claim is based on a fraction of the channel.
Test designs that work in a store
Store-level holdouts are the cleanest design: enable the integrated program in a matched set of stores, leave it off in a matched control set, and compare basket size, units per transaction and conversion where a conversion measure exists. Signage and prompt tests within a store, where the program is on everywhere but promotion varies, isolate the marketing effect from the tender effect. Looking only at the average basket of BNPL transactions versus card transactions is the analysis most often presented and the least reliable, because BNPL users self-select into larger baskets whether or not the tender caused them.
What the fee is buying
The honest framing is that the integrated BNPL fee buys three things: data the card path does not give, a native experience that may lift conversion for high-ticket categories, and a marketing relationship with the provider’s app audience. Whether those three things are worth the spread between the BNPL rate and card interchange is a category-by-category question. Jewelry, furniture, electronics and sporting goods tend to answer yes, while grocery and low-ticket apparel usually do not.
The broader shift in how card, wallet and BNPL costs are converging is set out in our overview of how retail payments are changing across cards, BNPL and crypto, and the tactical side is in the BNPL playbook for retail in 2026. We argued in June that in-store BNPL would go mainstream before the 2026 holidays; the repeat-user share of BNPL transactions is the cleanest way to tell whether that has happened in a given chain.
What the rules say and what they leave to the merchant
In-store BNPL sits in the same regulatory frame as online BNPL, with one added wrinkle: the store’s staff are now part of the disclosure chain. This section is general information about how the landscape has developed and is not legal, tax or compliance advice. Rules in this area have changed more than once since 2024 and are likely to change again, so figures and positions below should be verified against the relevant regulator’s current publications, and a retailer’s own program should be reviewed by a licensed attorney or compliance professional familiar with its situation.
The US federal picture
In May 2024 the Consumer Financial Protection Bureau issued an interpretive rule stating that BNPL lenders offering pay-in-four products through a digital user account are card issuers for purposes of Regulation Z, which would extend certain dispute, refund and periodic-statement protections to those products. According to the CFPB’s own later announcements in 2025, the Bureau said it would not prioritize enforcement of that rule and signaled its intention to revisit it. The practical position for merchants, as of the time of writing, is that the providers themselves carry the compliance burden for their credit products, and that a retailer’s exposure is mostly around what its staff say and what its receipts and signage claim. Readers should confirm the current status of the interpretive rule with the CFPB directly.
State law and the store
Several US states have moved to license or register BNPL providers or to bring them under existing small-loan and retail installment statutes, with California, New York and others active in this area. Those obligations generally fall on the lender, not the retailer, but state consumer protection and advertising law applies to what a store says at the point of sale regardless of who the lender is. That is the legal reason for the staff script: a cashier who describes a product as having “no credit check” when the provider performs a soft inquiry is making a representation the retailer may be responsible for.
Outside the United States
The United Kingdom’s Financial Conduct Authority brought BNPL into its regulatory perimeter in 2026, and the European Union’s revised Consumer Credit Directive, which member states were required to apply from late 2026, extends credit rules to most pay-in-instalment products. Retailers operating stores in those markets face provider-side affordability checks that can lengthen the in-store approval step, and should expect that to show up in queue time. Our earlier report on the FCA’s BNPL regime taking effect covers the UK detail; the European Commission’s consumer credit pages and the FCA’s policy statements are the primary sources to check for current requirements.
FAQ on in-store BNPL
Does a store need a contract with a BNPL provider to accept pay later in person?
No. Any store that accepts contactless Visa or Mastercard can receive purchases funded by a provider’s virtual card, because the terminal sees an ordinary card transaction. A contract is needed only for the integrated QR or native-tender flow, which gives the store BNPL-specific reporting, refund handling and a negotiated rate.
Which in-store BNPL flow is fastest at the counter?
For a shopper who already has the provider’s card in Apple Pay or Google Pay, the virtual-card tap is fastest, typically adding only a few seconds over a standard contactless payment. The QR flow adds a scan and a confirmation step. Code-based flows are slowest. First-time sign-ups are slow on every flow, which is why the best programs move sign-up out of the queue with signage and app prompts.
What does the merchant pay on an in-store BNPL sale?
It depends on the rail. A virtual-card purchase is charged at the store’s normal card acceptance rate for the debit or prepaid BIN involved. An integrated purchase is charged at the rate in the retailer’s BNPL agreement, which is generally higher than card interchange and is negotiated by volume and category. Current fee schedules should be confirmed with the acquirer and the provider, since both change.
How does a refund work if the customer has already paid one installment?
The store refunds through the same rail the purchase used: a card refund for a virtual-card purchase, or an API refund for an integrated one. The provider then adjusts the plan, cancelling remaining installments and returning any already paid to the shopper’s original funding source. The store’s refund and the provider’s plan adjustment happen on different timelines, so staff should explain that the shopper’s app will show the updated schedule.
Can staff help a customer sign up at the till?
Staff can explain where to download the app and that sign-up happens on the shopper’s own phone. They should not handle the phone, enter the shopper’s personal information, or characterize the credit terms beyond what the provider’s own materials say. A short written script, reviewed by whoever handles compliance for the retailer, is the usual safeguard.
What happens if the BNPL approval is for less than the basket total?
If the POS supports split tender for the BNPL tender type, the shopper can pay the approved amount with BNPL and the remainder by card or cash. If it does not, a partial approval becomes a full decline and the sale is at risk. Enabling split tender for the new tender type is one of the most important integration decisions and is often off by default.
Can a store see which of its card sales were actually BNPL-funded?
Not from the POS alone, because a virtual-card purchase looks like any other debit or prepaid card. Retailers get that view by asking the acquirer for a BIN-level breakdown or by asking the BNPL providers for their virtual-card volume at the store. Without one of those, the store’s own BNPL reporting covers only the integrated tender and understates the channel.
Is the regulatory picture for in-store BNPL different from online?
The credit product is regulated the same way regardless of where the purchase happens, and those obligations sit mostly with the provider. The difference for the store is that its staff, signage and receipts become part of what the shopper is told, which brings state advertising and consumer protection law into play. This is general information rather than legal advice; the current position should be confirmed with the relevant regulator and qualified counsel.