Use Cases of Merchant Acquiring: QR, POS, SoftPOS, BNPL and More

Merchant acquiring is no longer one product. It is a set of shared building blocks that a bank, acquirer or payment aggregator can combine to support every way a merchant gets paid: a QR code at a kirana counter, a card terminal at a supermarket, a phone that doubles as a terminal, a checkout page, a link sent on WhatsApp, a pay-later option, or a wallet that only works inside one ecosystem.

Merchants rarely accept payments through just one channel. A restaurant may take QR payments at the table, cards at the counter and online orders through a gateway. If each channel runs on a separate stack, the acquirer ends up with duplicate onboarding, scattered merchant records, fragmented reconciliation and inconsistent risk controls.

This guide walks through eight core use cases of merchant acquiring, explains what each one needs from the underlying platform, and shows how a single set of building blocks can serve all of them.

What merchant acquiring is, and the building blocks behind it

Merchant acquiring is the business of enabling merchants to accept payments and settling those funds into the merchant's account. The acquirer (a bank, or a licensed payment aggregator working with one) signs up the merchant, routes each transaction to the right network or issuer, manages risk and pays the merchant after deducting fees.

Behind every acceptance channel sits a common set of capabilities:

• KYC / KYB: Verifies the identity of the business and its owners, and checks documents, bank accounts and ownership before the merchant goes live.

• Onboarding: Captures merchant details, assigns pricing and limits, and provisions devices, QR codes or API credentials. Digital onboarding turns a multi-day process into one that can close the same day.

• Merchant management system (MMS): The system of record for each merchant, covering hierarchy (chains, outlets, terminals), commercials, settlement, reconciliation, disputes and reporting.

• Issued instruments: The payment instruments on the customer side, such as wallets, prepaid cards or credit lines. Some use cases need the acquirer or its partner to issue these; others accept instruments issued elsewhere.

• Acquiring switch: Receives card transactions from terminals and gateways, applies routing rules and connects to card networks for authorisation, clearing and settlement.

• 3DS server (3DSS): Handles the merchant side of 3-D Secure authentication for card-not-present transactions, so online payments can be authenticated by the issuer.

• Tokenization: Replaces card numbers with network or acquirer tokens, so merchants can store credentials for repeat payments without holding raw card data.

• Fraud and risk management (FRM): Monitors transactions and merchant behaviour in real time to flag fraud, laundering patterns and merchant-level risk.

The use cases below differ mainly in which of these blocks they switch on.

Use case 1: QR payments

QR payments are the fastest way to bring small and micro merchants into digital acceptance. In India, UPI QR has made it possible for street vendors, kirana stores and service providers to accept payments with nothing more than a printed code.

How it works: The merchant displays a static or dynamic QR code. The customer scans it with a UPI or wallet app and approves the payment. Funds are credited to the merchant's account, either instantly or through scheduled settlement.

Where it fits: Small retail, food stalls, local services, utilities, parking, and as a low-cost secondary channel for larger merchants.

Building blocks needed:

• KYC / KYB and onboarding, often in a lighter, risk-tiered form for small merchants

• Merchant management for QR generation, settlement and reconciliation

• Issued instruments are optional, needed only if the acquirer also wants to accept its own wallet or prepaid instrument on the same QR

• FRM is optional but valuable, since QR fraud often shows up as fake merchants or QR code swaps

What acquirers should watch: Merchant volumes are high and ticket sizes are low, so onboarding cost per merchant and automated reconciliation matter more than anything else. Dynamic QR, which carries the amount and an order reference, makes reconciliation much easier than static QR.

Use case 2: POS payments

Point-of-sale terminals remain the backbone of card acceptance in physical retail. Modern Android POS devices go beyond cards: a single terminal can accept chip, tap, swipe, QR and wallet payments, print receipts and run billing apps.

How it works: The customer taps, inserts or swipes a card. The terminal sends the transaction to the acquiring switch, which routes it to the card network and issuer for authorisation. Approved transactions are cleared and settled to the merchant.

Where it fits: Supermarkets, large-format retail, restaurants, fuel stations, hospitals, hotels and any merchant with consistent card footfall.

Building blocks needed:

• KYC / KYB, onboarding and merchant management, including terminal provisioning and outlet-level hierarchy

• Acquiring switch for card routing, authorisation and network connectivity

• Tokenization for stored credentials, contactless and repeat payments

• Issued instruments and FRM are optional, depending on whether the acquirer runs its own prepaid or wallet programmes and how much transaction monitoring it wants in-house

What acquirers should watch: Terminal management (deployment, key injection, software updates, device health) is an operational load in itself. Value-added services such as EMI at checkout, dynamic currency conversion and loyalty redemption help acquirers stand out in a crowded market.

Use case 3: SoftPOS

SoftPOS turns an NFC-enabled Android smartphone into a contactless card terminal. It removes the cost and logistics of dedicated hardware, which makes card acceptance viable for merchants who would never buy or rent a POS device.

How it works: The merchant installs a certified SoftPOS app. The customer taps a contactless card or a phone wallet on the merchant's device. The app captures the transaction securely and sends it to the acquiring switch, after which the flow mirrors a regular POS payment.

Where it fits: Delivery agents collecting cash-on-delivery as card payments, field sales teams, insurance and loan collection agents, home services, pop-up stores, and small merchants who want card acceptance without hardware.

Building blocks needed:

• KYC / KYB, onboarding and merchant management, with device binding and app-based provisioning

• Acquiring switch for card authorisation

• Tokenization, since SoftPOS is built around contactless and tokenised credentials

• FRM is strongly recommended, because the device is a general-purpose phone and fraud patterns differ from dedicated terminals

What acquirers should watch: SoftPOS solutions need to meet card network and PCI security standards for contactless acceptance on commercial devices. Contactless transaction limits and PIN entry rules also shape which ticket sizes SoftPOS can serve.

Use case 4: Soundbox

A soundbox is a small connected speaker that announces each payment received, usually paired with the merchant's QR code. It solves a practical problem for busy counters: the merchant no longer has to check a phone to confirm that a customer has paid.

How it works: When a payment lands against the merchant's QR, the acquirer's platform sends a real-time notification to the soundbox over a SIM or Wi-Fi connection. The device announces the amount, often in the local language. Newer variants add a small display, a built-in dynamic QR or even card-tap capability.

Where it fits: Kirana stores, pharmacies, tea stalls, vegetable vendors and any high-footfall counter where the owner cannot watch every transaction.

Building blocks needed:

• KYC / KYB, onboarding and merchant management, with the soundbox mapped to the merchant's QR and outlet

• Real-time payment notification from the merchant management layer to the device

• Device management for SIM connectivity, firmware and rental or subscription billing

• FRM is optional, mostly for spotting merchant-level anomalies

What acquirers should watch: The soundbox is also a retention tool. A merchant with a device on the counter is less likely to switch acquirers, and the device can carry offers, loan prompts or settlement alerts. Device rental fees and connectivity costs need to be weighed against that retention benefit.

Use case 5: Online payment gateway

The online payment gateway is the most component-heavy acceptance use case. It has to accept cards, UPI, net banking and wallets in a single checkout, authenticate card-not-present transactions and support stored credentials for repeat customers.

How it works: The customer checks out on a website or app and picks a payment method. For cards, the gateway runs 3-D Secure authentication through the 3DS server, sends the authorisation through the acquiring switch and stores the card as a token if the customer opts in. Other methods are routed to their respective rails.

Where it fits: E-commerce, travel and ticketing, edtech, subscriptions, insurance premiums, utilities, government payments and any business selling online.

Building blocks needed:

• KYC / KYB, onboarding and merchant management, including API credentials, webhooks and website or app checks

• Acquiring switch for card routing and authorisation

• 3DSS for issuer authentication on card-not-present payments

• Tokenization for saved cards, one-click checkout and recurring mandates

• Issued instruments and FRM are optional, though most gateway operators run some form of transaction risk scoring

What acquirers should watch: Success rates drive merchant loyalty. Smart routing, retries, token-based checkout and clean 3DS flows all improve conversion. Refunds, chargebacks and settlement reconciliation at scale need strong merchant management tooling.

Use case 6: Payment links

Payment links let a merchant collect money without a website, an app or a terminal. The merchant generates a link for a specific amount and shares it over SMS, email, WhatsApp or social media. The customer opens it and pays through a hosted checkout.

How it works: The link opens a hosted payment page that runs on the same gateway infrastructure. Card payments go through 3DS authentication and the acquiring switch, while UPI and other methods follow their own rails. The merchant gets a real-time status update and the payment is reconciled against the link reference.

Where it fits: Social commerce sellers, freelancers and consultants, clinics and diagnostic labs, tuition and coaching fees, B2B invoice collection, and phone or chat-based orders.

Building blocks needed:

• KYC / KYB, onboarding and merchant management, with a merchant dashboard or API to create, track and expire links

• Acquiring switch, 3DSS and tokenization, the same card-not-present stack as the online gateway

• FRM is optional but useful, since links can be forwarded and misused

What acquirers should watch: Payment links are often the first digital product a small business adopts. Bulk link creation, partial payments, expiry controls and automatic reminders turn a simple feature into a light collections tool.

Use case 7: BNPL

Buy now, pay later brings credit to the point of sale. The customer completes a purchase and repays in instalments or at a later date, while the merchant is paid upfront. For merchants, BNPL can lift conversion and average order value on higher-ticket purchases.

How it works: At checkout, the customer selects BNPL. The lender or BNPL provider checks eligibility against a pre-approved credit line, the purchase is charged to that line, and the merchant receives settlement. The customer then repays the lender as per the agreed schedule.

Where it fits: Consumer electronics, fashion, travel, education, healthcare, home improvement and B2B purchases where buyers need short-term working capital.

Building blocks needed:

• KYC / KYB, onboarding and merchant management, including merchant-specific BNPL offers and subvention settings

• Issued instruments, because the credit line itself has to be issued and managed on the customer side

• FRM is optional, though credit and identity fraud controls are important for any lending programme

• The acquiring switch, 3DSS and tokenization are not core to BNPL, since the transaction runs on the credit line rather than a card network

What acquirers should watch: BNPL sits at the meeting point of payments and lending, so it must follow the lending regulations in each market. In India, this includes RBI's digital lending guidelines, which govern how credit is disbursed, disclosed and repaid.

Use case 8: Closed-loop wallets

A closed-loop wallet can be used only within a defined network of merchants, usually owned or contracted by the issuer. Think of a campus card, a mall gift wallet, a food court card, a transit card or a corporate cafeteria wallet.

How it works: Users load money into the wallet and spend it at participating merchants. Because the network is closed, the operator controls both sides: it issues the wallet to users and onboards the merchants who accept it. Settlement to merchants happens within the operator's own ledger.

Where it fits: Universities, malls and food courts, entertainment parks, residential societies, corporate campuses, transit systems and loyalty-led retail chains.

Building blocks needed:

• KYC / KYB, onboarding and merchant management for the merchants inside the network

• Issued instruments, since the operator issues and manages the wallets used by customers

• FRM is optional, mainly for load and spend anomalies

• No acquiring switch, 3DSS or tokenization is needed, because transactions never leave the closed network

What acquirers should watch: Closed-loop wallets are simpler to run than open-loop instruments, but they still come with regulatory obligations in many markets, such as caps on wallet balances and rules on refunds and expiry. Done well, they generate rich spend data and keep value within the ecosystem.

One set of building blocks, every acceptance use case

KYC / KYB, onboarding and merchant management are common to every use case. What changes from one use case to the next is whether issued instruments, the acquiring switch, 3DSS and tokenization are needed. FRM sits across all of them as an optional layer.

● Included · ○ Optional ·

The pattern is clear. Card-based channels (POS, SoftPOS, online gateway and payment links) lean on the acquiring switch and tokenization, with 3DSS added for card-not-present payments. Account-to-account and issuer-led channels (QR, soundbox, BNPL and closed-loop wallets) lean on issued instruments and the merchant management layer instead.

What to look for in a merchant acquiring platform

An acquirer that wants to serve all eight use cases should look for a platform built on shared components, not a bundle of separate products. Five questions help separate the two.

1. Is there one merchant record across channels? A merchant who takes QR, POS and online payments should have a single profile, one KYC, one pricing setup and one settlement view.

2. Can new channels be switched on without re-onboarding? Adding SoftPOS or payment links to an existing merchant should be a configuration change, not a new project.

3. Is reconciliation unified? Settlement, refunds and chargebacks across channels should reconcile in one place, with merchant-level reporting.

4. Does risk management see the whole merchant? Fraud and merchant risk signals are far more useful when FRM sees activity across every channel, not just one.

5. Is it modular? Acquirers at different stages need different components. A bank starting with QR should be able to add the acquiring switch, 3DSS and tokenization later without replacing what it already runs.

A modular stack also keeps the business model flexible. The same platform can serve a bank's own merchant base, a payment aggregator's long-tail merchants, or a closed ecosystem such as a campus or a fleet network.

How M2P helps

M2P's merchant acquiring stack is built as a set of composable building blocks: KYC / KYB, digital onboarding, a merchant management system, issuance, an acquiring switch, a 3DS server, tokenization and fraud risk management. Banks, acquirers and payment aggregators can start with the components they need today and add more as their acceptance footprint grows.

Because every channel runs on the same merchant record and the same settlement and reconciliation layer, adding a new use case does not mean starting over. A merchant onboarded for QR can be extended to POS, online payments or BNPL with configuration rather than a fresh integration.

Conclusion

The eight use cases covered here look different at the counter, on the checkout page and in the customer's app. Underneath, they draw on the same core capabilities. Acquirers that treat merchant acquiring as one platform, rather than eight separate products, can launch new channels faster, keep a single view of each merchant and apply risk controls consistently.

To explore how M2P's merchant acquiring building blocks can fit your acceptance roadmap, talk to our team.

Frequently asked questions

What is merchant acquiring? Merchant acquiring is the service of enabling businesses to accept payments and settling those funds into their accounts. The acquirer onboards the merchant, processes transactions and manages risk and settlement.

What is the difference between a merchant acquirer and a payment gateway? The acquirer holds the merchant relationship and settles funds. A payment gateway is the technology layer that captures online payments and passes them to the acquirer or payment networks. Many providers offer both.

How is SoftPOS different from a regular POS terminal? SoftPOS runs on an NFC-enabled smartphone and accepts contactless payments without dedicated hardware. A regular POS terminal is purpose-built and supports chip, swipe and contactless.

Do QR payments need an acquiring switch? Not for UPI QR, which runs on account-to-account rails. A card switch is needed only when the same acceptance point also takes card payments.

Can one platform support both open-loop and closed-loop payments? Yes. With shared KYC, onboarding and merchant management, the same platform can run open-loop channels like POS and gateways alongside closed-loop wallets.

Why does fraud risk management matter across every use case? Fraud often moves between channels. A merchant risk view that spans QR, POS and online payments catches patterns that a single-channel view would miss.