Issuer vs Acquirer Explained: Understanding Card Transaction Roles

Every card transaction, whether tapped at a POS terminal or completed at an online checkout, involves five entities working in sequence: the customer, the merchant, the acquirer bank, the card network, and the issuer bank. What feels instant to the end customer is, underneath, a structured chain of authorisation requests, risk checks, and fund movements completing within a few hundred milliseconds.

The issuer and acquirer sit at opposite ends of that chain, with the card network operating as the routing layer between them. The issuer represents the customer; the acquirer represents the merchant; the card network, that is, Visa, Mastercard, RuPay, or Amex, provides the rails that connect the two. None of them can settle a transaction without the others.

Growth of Card and Digital Payments

India’s card and digital payment volumes have grown at a pace that few markets can match. Factors driving that expansion include:

Mobile and smartphone penetration at scale. Approximately 85.5% of Indian households own at least one smartphone, and 86.3% of households have internet access within the household, per the National Statistics Office’s Comprehensive Modular Survey on Telecom (January-March 2025).
Rapid growth in e-commerce and quick-commerce transaction counts.
UPI’s emergence as the leading acceptance mechanism through QR-based merchant onboarding across Tier 2 and Tier 3 cities, pulling a meaningful share of low-value transactions away from cards.
Continued dominance of cards in corporate spending and cross-border transactions, segments where UPI’s framework currently does not operate.
UPI’s design focuses on low-value, instant transactions with policy-defined limits on individual and daily transaction values, set by NPCI and RBI rather than by underlying technical constraints.

The picture is not cards versus UPI in any simple sense. UPI has taken a share in low-value retail. Cards continue to lead in segments that UPI doesn’t address. Both rails are growing in absolute terms.

Why Payment Infrastructure Matters

A payment system has to do four things well, and none of them are optional:

Confirm a transaction is legitimate before releasing funds.
Complete that confirmation fast enough that the experience doesn’t degrade.
Stay up when transaction volumes peak.
Keep cardholder data protected at every handoff point.

When the issuer–acquirer framework breaks down, whether through fraud, system downtime, or misaligned settlement processes, the consequences spread across all three sides of the transaction:

Merchants lose revenue on declined or unsettled transactions.
Banks carry liability for chargeback and breach exposure.
And customers get caught in failure scenarios where the amount is debited from their account. But the merchant terminal doesn’t receive the authorisation confirmation, leaving them temporarily out of funds while the merchant denies the service or goods

These reversal scenarios take days to resolve through bank-initiated reconciliation, and they erode customer trust in card payments far more than the underlying transaction value would suggest.

For enterprises processing millions of card transactions a day, the operational health of this infrastructure is not a back-office concern. It directly affects customer experience, merchant settlement timelines, and bank-side risk exposure.

What is an Issuer Bank?

An issuer bank is the financial institution that provides a payment card, such as a credit, debit, or prepaid to a customer. When a cardholder swipes, taps, or enters their card number, the issuer is the institution being asked to release funds or extend credit for that purchase.

In India, the major card issuers vary by product type. HDFC Bank sits among the leading credit card issuers, alongside SBI Cards, ICICI Bank, Axis Bank, and Kotak Mahindra Bank.

While for debit cards, SBI is the clear market leader, accounting for roughly one-third of all debit cards issued in India, given its extensive savings account base across urban and rural geographies.

Beyond these, a growing range of co-branded card programmes operate in partnership with network brands and fintech distribution partners.

The card may carry a Visa or Mastercard logo, but the network and issuer play distinct roles; the network provides the acceptance rails and scheme rules, while the issuer owns the customer relationship and carries the credit and fraud risk.

Certain risk scenarios are covered by the network through scheme-defined liability frameworks, but the primary exposure stays with the issuer.

Responsibilities of an Issuer Bank

The issuer’s obligations run from the moment a customer applies for a card through every transaction that card ever makes, and into any disputes that arise after the fact:

Verifying identity and creditworthiness before issuing a card, including income assessment, credit bureau checks, and KYC documentation.
Managing the cardholder’s account includes viewing account activity, generating statements, reviewing repayment cycles, reviewing credit limits, etc.
Performing authorisation decisions in real-time for each transaction, including balance checks, fraud scoring, card status validation, and, if necessary, 3D Secure authentication.
Fraud monitoring runs continuously against the cardholder’s evolving behaviour profile.
Handling chargeback adjudication. When a cardholder disputes a charge, the issuer reviews the evidence and determines whether a reversal is warranted.
Operating within applicable regulatory guidelines (RBI), card scheme rules (Visa, Mastercard, RuPay, Amex operating regulations), PCI-DSS data security requirements, and KYC and AML obligations relevant to the issuing jurisdiction.

There’s also a credit risk dimension that often gets underweighted in discussions of payment infrastructure. When an issuer approves a credit card transaction, it’s extending a short-term unsecured loan. If the cardholder defaults, the issuer carries that loss. Every approval decision is, at some level, a lending decision.

How Issuer Banks Authorise Payments

When an authorisation request arrives at the issuer’s processing system, the checks run roughly in this order:

Is the card active, not blocked, not expired?
Does the account have an available balance or credit headroom to cover this amount?
Does the transaction match this cardholder’s typical patterns, merchant type, location, or transaction value?
For card-not-present transactions, has the secondary authentication step been passed?

The output is a response code: an approval with an authorisation number, or a decline with a specific reason code that tells the acquirer whether the decline is hard (don’t retry) or soft (retry may succeed). This decision loop completes in a few seconds. The speed matters at checkout; every additional second of latency is a conversion risk.

What is an Acquirer Bank?

An acquiring bank is the financial institution that enables a merchant to accept card payments. It holds the merchant’s account, routes transactions to the right card network, receives settlement funds once the issuer side clears, and puts those funds into the merchant’s operating account.

In India, major acquirers include HDFC Bank, Axis Bank, ICICI Bank, and several specialist payment aggregators operating under RBI licensing. The same bank can hold both issuer and acquirer functions. This is common among large universal banks, but operationally, these are distinct roles regardless of whether one institution is performing both.

Responsibilities of an Acquirer Bank

Merchant Onboarding

KYC documentation, which includes business registration, GST, director identity verification, and bank account confirmation.
Risk assessment covering industry category, projected transaction volumes, average ticket size, and prior chargeback history.
Merchant category code (MCC) assignment, which determines applicable interchange rates and card network rules going forward.

Ongoing Operational Role

Provisioning payment acceptance infrastructure: POS terminals for physical retail, gateway access for online, APIs for custom integrations.
Routing every authorisation request from the merchant’s systems to the correct card network and handling the response back.
Batching approved transactions at the end of the day, receiving settlement funds once the issuer side clears, deducting MDR, and crediting the merchant’s account on a T+1 or T+2 cycle, depending on agreed terms.

Chargeback Liability

When a chargeback dispute is upheld, the acquirer debits the reversed amount from the merchant’s account. The acquirer absorbs the shortfall only when recovery fails:
- No balance to debit: the merchant has gone insolvent, closed operations, or had its account terminated.
- Insufficient settlement coverage: settlement balances and reserve accounts can’t cover the reversal, or chargeback volume from a single merchant outpaces what ongoing settlements can offset.
  In these scenarios, the acquirer remains contractually liable to the issuer under card scheme rules, and the cardholder must be refunded regardless of merchant solvency.
This is why acquirers underwrite merchants carefully at onboarding and monitor chargeback ratios throughout the relationship.
High-risk segments like gaming, travel, and subscription commerce face more intensive due diligence, and many acquirers require these merchants to maintain rolling reserve accounts, holding back a portion of settlement funds as a buffer against future chargeback claims.

Compliance Oversight

Ensuring merchants remain compliant with PCI-DSS and card network operating rules throughout the relationship, not just at onboarding.

Relationship Between Acquirer and Merchant

The acquirer is typically the merchant’s primary financial relationship in payments. That covers:

Fee structure: Setting the MDR charged per transaction, a percentage that varies by card type, channel, and the merchant’s risk and volume profile, is negotiated at onboarding with periodic reviews for established accounts.
Settlement management: Managing the settlement cycle and providing transaction-level reconciliation data that merchants need to match payment records against bank credits.
Dispute support: Supporting merchants through chargeback disputes, including documentation requirements, evidence submission windows, and network-imposed timelines.

A merchant without an acquirer relationship cannot accept card payments.

How a Card Transaction Works (Step-by-Step)

A card transaction moves through five parties in a specific sequence. The whole chain completes in a few seconds for most domestic transactions. What follows is the operational reality behind that speed.

1. Customer Initiates Payment

The customer presents their card physically at a POS terminal via tap, dip, or digitally at an online checkout by entering card credentials. The terminal or payment page captures and encrypts the card data immediately. A transaction request is packaged and sent upstream.

2. Merchant Sends Request to Acquirer

The merchant’s payment system, POS software, and payment gateway transmit the encrypted transaction data to the acquirer. For online transactions, tokenisation reduces PCI-DSS scope (i.e., fewer systems handle raw card data, so fewer systems need to be in scope).

3. Acquirer Sends Request to Card Network

The acquirer identifies the relevant card network from the card’s BIN (Bank Identification Number) and routes the authorisation request accordingly via the card scheme, viz. Visa, Mastercard, RuPay, or Amex. The acquirer is a member of these networks, which is part of what qualifies it to route on behalf of merchants.

4. Card Network Routes Request to Issuer

The network receives the request and identifies the issuing bank from the BIN range. It forwards the authorisation request to the issuer’s processing system.

5. Issuer Approves or Declines Transaction

The issuer runs its checks, such as card validity, available funds, fraud scoring, and authentication status, and returns a response code. Approval carries an authorisation number. Decline carries a reason code that indicates whether it’s a hard decline or a retrievable soft decline.

6. Authorisation Sent Back to Merchant

The response travels back through the same chain in reverse:

issuer → card network → acquirer → merchant terminal or checkout page.

The merchant’s system receives the outcome, and either confirms the transaction or notifies the customer of the decline. The round trip, under normal conditions, takes well under five seconds.

7. Settlement and Funds Transfer

Authorised transactions sit in a pending state until end-of-day batch processing. The acquirer submits the day’s batch to the card network, which debits the issuing bank and credits the acquirer.

The acquirer then deposits the net amount, which is the gross transaction value minus MDR, into the merchant’s account, typically on a T+1 or T+2 basis depending on the acquirer’s settlement terms.

Key Stakeholders in a Payment Transaction

1. Role of Card Networks

Visa, Mastercard, RuPay, and American Express are the card networks that sit between issuers and acquirers. They don’t hold customer accounts or merchant accounts. What they do is:

Provide the communication infrastructure that connects any issuing bank to any acquiring bank on the same network, globally.
Define the operating rules, fee structures, and security standards that all participants must follow for cards issued under the respective schemes.
Route each authorisation request to the correct issuer based on card BIN data.
Facilitate interbank settlement between issuers and acquirers after batches are processed.
Facilitate dispute and chargeback management.

The network brand on a card (Visa logo, Mastercard logo) doesn’t mean that Visa or Mastercard issued that card. It means the card can transact anywhere on that network’s acceptance infrastructure.

2. Role of Payment Processors

Payment processors handle the technical transmission layer. They route encrypted transaction data between the merchant’s systems and the acquirer, manage the authorisation request protocol formatting, and provide the terminal software or payment gateway APIs that merchants integrate.

In practice, many acquirers operate their own processing infrastructure, while others contract with specialist processors. Enterprise merchants should understand which model their acquirer uses, as it affects integration complexity, SLA accountability, and who to call when something breaks.

3. Role of Merchants

Merchants initiate the transaction request, but their obligations don’t stop there:

Integrating with acquirers and processors to enable transaction routing across their sales channels.
Maintaining checkout environments that meet PCI-DSS requirements, which vary significantly based on whether card data ever touches the merchant’s own servers.
Managing chargeback disputes with documentation and evidence, within the timeframes that card networks impose.
Monitoring authorisation rates and decline patterns closely enough to identify and fix revenue leakage.

4. Role of Customers

Customers set the whole chain in motion. Their immediate obligations are straightforward: present valid credentials, complete authentication where required, and maintain available funds.

Issuer vs Acquirer: Key Differences

The issuer and acquirer perform entirely different functions despite appearing in the same transaction.

The issuer is accountable to the cardholder as it manages their account, extends credit, and makes the authorisation call.
The acquirer is accountable to the merchant as it routes transactions, holds the merchant account, and delivers settlement.

One institution can technically perform both roles, but the operational logic of each remains distinct.

Transaction Responsibilities

When an authorisation request is in flight:

The issuer receives it, runs its checks, and returns the outcome.
The acquirer generates it on the merchant’s behalf, routes it through the network, and delivers the response back to the merchant.

The direction of accountability is opposite. The issuer is answering a question about the cardholder. The acquirer is asking that question on the merchant’s behalf.

Risk and Fraud Management Roles

Fraud risk sits differently on each side.

The issuer manages cardholder credit risk, the possibility that the customer can’t or won’t repay the credit extended. It also carries card fraud liability: if a stolen card is used and the issuer approved the transaction, the issuer typically bears that loss. Chargeback disputes funnel back to the issuer as well, which is why issuer fraud detection models are so sophisticated.

The acquirer’s risk exposure runs through the merchant. High chargeback rates, fraudulent merchant activity, and data breaches occurring at the merchant level all land on the acquirer’s balance sheet if the merchant can’t cover the costs. This is why acquirers vet merchants at onboarding and monitor transaction patterns throughout the relationship.

Issuer vs Acquirer Comparison Table

Aspect	Issuer Bank	Acquirer Bank
Primary relationship	Cardholder	Merchant
Core function	Issue cards, authorise transactions.	Enables card acceptance and settles funds.
Risk exposure	Cardholder credit risk, card fraud.	Merchant fraud, chargebacks, compliance breaches.
Revenue source	Interest income, interchange fees received.	MDR is charged to merchants.
Chargeback role	Adjudicates customer disputes, initiates reversal.	Receives dispute notification, processes merchant debit.
Settlement direction	Releases funds to the acquirer via the card network.	Receives funds from the network and credits the merchant account.
Infrastructure managed	Cards, account management, online banking.	POS terminals, payment gateways, merchant accounts.
Regulatory framework	Regulatory and card scheme issuance norms, PCI-DSS, and KYC.	Merchant acquiring licence, PCI-DSS, and network compliance.

Benefits of Issuer–Acquirer Payment Infrastructure

Secure Payment Authorisation

The issuer–acquirer structure builds security in at multiple layers rather than relying on any single control point:

Multi-factor authentication at the issuer level, including PIN, OTP, and biometric, depending on the transaction type and channel.
3D Secure for card-not-present transactions, where physical card verification isn’t possible.
Real-time fraud scoring against cardholder behaviour profiles at the issuer, before authorisation is granted.
Encrypted data transmission throughout, from terminal to acquirer, acquirer to network, network to issuer.
Tokenisation replaces raw card numbers at the point of capture, so breaches at the merchant level can’t expose live card credentials.

Faster Transaction Processing

Sub-two-second authorisation is now table stakes at checkout. The issuer–acquirer framework achieves this through:

Parallel processing of fraud checks and balance verification within the issuer’s authorisation system.
Optimised routing between acquirers and card networks, with direct connections for high-volume transaction pairs.
Cloud-based processing infrastructure at major issuers, replacing legacy mainframe systems that introduced latency.

For enterprise merchants handling peak loads such as a flash sale, a travel booking window, or a payroll run, those response times matter. Authorisation delays at checkout translate directly to abandonment.

Global Payment Network Connectivity

Because card networks operate globally, the issuer–acquirer framework handles cross-border acceptance without any additional integration work on the merchant side.

A card issued by any member bank can be used to transact at any merchant connected to the same network, anywhere in the world, subject to the card product configuration at the issuer and the card network end. Multi-currency settlement, conversion, and cross-border interbank clearing are all managed through the network layer, which is transparent to both the issuer and the acquirer below it.

Better Fraud Prevention

Fraud intelligence now runs across both sides of the transaction. Issuers deploy ML-based models that flag deviation from a cardholder’s established patterns before approving. Acquirers monitor merchant-level chargeback ratios and transaction patterns for signs of fraudulent merchant activity.

Card networks aggregate signals across the entire ecosystem, identifying fraud rings operating simultaneously across multiple issuers and acquirers that neither side could detect alone.

Fee Structure in Card Transactions

Interchange Fees

Interchange is paid by the acquirer to the issuer on every approved transaction. It compensates the issuer for the credit risk it’s absorbing and the fraud liability it’s carrying on the cardholder’s behalf.

Interchange rates are set by card networks, not by individual banks, and they vary based on several factors: card type (credit carries a higher interchange than debit), merchant category code, and whether the transaction is card-present or card-not-present.

In India, regulatory intervention has eliminated MDR on specific transaction types. Since January 2020, MDR has been set at zero for RuPay Debit Card and BHIM-UPI transactions. Alongside this, businesses with annual turnover above ₹50 crore are mandated to offer RuPay debit cards and UPI QR as accepted payment modes under Rule 119AA of the Income Tax Rules.

The combined effect has been to eliminate the interchange-driven cost layer on these transaction types, while leaving Visa, Mastercard, and other card scheme MDR untouched, a structural distortion the Payments Council of India has flagged repeatedly to the government on behalf of the ecosystem’s banking and acquiring participants.

Merchant Discount Rate (MDR)

MDR is the total fee charged by the acquirer to the merchant for transaction processing. It bundles:

Interchange, passed through to the issuer.
Card network assessment fees.
The acquirer’s own margin for processing and infrastructure.
Gateway or terminal costs, where included.

Rates differ by card type, merchant category, channel, and the merchant’s volume and risk profile. Large enterprise merchants with high card volumes and clean chargeback histories typically negotiate considerably lower MDR than small or new businesses. The negotiation happens with the acquirer, within the constraints that interchange floors impose.

Network Processing Fees

Card networks charge assessment fees on gross transaction volumes processed across their rails. These are non-negotiable, set by the network, applied uniformly to all acquirers, and are passed through as part of the merchant’s MDR. They’re small as a percentage of transaction value but add up at enterprise volumes.

Settlement Fees

Settlement fees cover the operational cost of moving funds from the issuer to the acquirer to the merchant account. This can include per-transaction processing charges, currency conversion costs on cross-border transactions, and batch processing fees for end-of-day settlement runs. The specific structure varies by acquirer and is typically detailed in the merchant agreement.

Who Determines Transaction Fees?

Role of Card Networks

Card networks sit at the top of the fee-setting hierarchy. They define interchange schedules, such as what acquirers must pay issuers per transaction type, and the assessment fees charged to acquirers for using the network. They also publish rules that constrain how MDR is structured and communicated to merchants. Banks and merchants negotiate within this framework; they don’t negotiate around it.

Role of Issuer Banks

Issuers influence the interchange side through the card products they design. Premium credit cards with rewards programmes command higher interchange than basic debit cards; the network allows this because the issuer is taking on more risk and absorbing the reward cost. Issuers also earn interest on revolving balances, which is a separate and often larger revenue stream than interchange, particularly on credit cards.

Role of Acquirer Banks

Acquirers set the MDR charged to each merchant within the constraints of pass-through interchange and network fees. How much margin the acquirer adds depends on the merchant’s risk profile, channel mix, card type distribution, and negotiated volume. For enterprise merchants, this margin is where most of the fee negotiation happens.

Role of Regulators

RBI has shaped this fee structure directly in India. The Zero MDR mandate on RuPay debit cards and BHIM-UPI transactions, effective since January 2020 through amendments to the Payments and Settlement Systems Act, eliminated MDR on those specific rails entirely.

RBI’s broader oversight under the Act governs how payment system operators can charge fees across the ecosystem. NPCI sets its own interchange structures for RuPay, which differ from Visa and Mastercard rates. The regulatory picture evolves continuously, and enterprise finance teams need to track these changes because they affect net payment costs materially.

How Businesses Integrate with Payment Infrastructure

1. Merchant Onboarding Process

Before any card transaction can be processed, the acquirer runs due diligence on the merchant.

KYC documentation: business registration, GST, director identity, bank account verification.
Risk assessment: industry category, projected transaction volumes, average ticket size, and chargeback history if the business has prior acquiring relationships.
MCC assignment: The merchant category code determines applicable interchange rates and which card network rules apply.
Account setup and settlement parameter configuration.

Merchants in high-risk categories, such as gaming, travel, subscription commerce, and pharmaceuticals, face extended due diligence. Some acquirers require reserve accounts, effectively holding a portion of settlement funds as a buffer against potential chargeback claims.

2. Payment Gateway Integration

For online merchants, the gateway is the technical interface between the checkout and the acquirer’s processing infrastructure. Integration choices carry real implications:

Hosted payment pages push card data entry to the gateway’s own domain, taking the merchant’s systems largely out of PCI-DSS scope.
API integration gives merchants full control over the checkout UI, but requires managing PCI-DSS compliance for any environment where card data transits.
Pre-built plugins for platforms like Shopify, Magento, or Salesforce Commerce Cloud reduce development effort but constrain customisation.

Gateway reliability and latency directly affect authorisation rates. A gateway that introduces 300ms of additional latency on every transaction, or that returns vague decline codes, costs merchants real money in conversion. This is worth examining carefully when selecting or reviewing an acquirer relationship.

3. API-Based Payment Processing

Enterprise businesses increasingly run payment operations through direct API integrations rather than hosted gateway configurations. The use cases driving this:

Real-time authorisation and decline handling are embedded in proprietary applications, like OMS, ERP, and procurement platforms.
Automated reconciliation between payment data and internal financial systems without manual export steps.
Subscription and recurring billing with custom retry logic based on decline reason codes
Multi-currency transaction management and cross-border routing at scale.

Acquirers with mature API infrastructure make this straightforward. Those still operating on legacy gateway architectures introduce friction that compounds at enterprise transaction volumes.

4. Compliance and Security Requirements

Every business processing card payments operates under PCI-DSS. The compliance tier, ranging from a self-assessment questionnaire to a full Qualified Security Assessor audit, is determined by annual transaction volume.

Beyond PCI-DSS, Indian businesses processing card payments need to stay current on:

RBI tokenisation mandates: Card-on-file data must be tokenised using network-issued tokens rather than stored as plain card numbers. This mandate applies to payment aggregators, payment gateways, and merchants. Card networks and issuing banks are excluded and may retain PAN (Primary Account Number) data within their own regulated systems.
Data localisation requirements: Payment data on Indian customers must reside in India.
Additional Factor of Authentication: RBI’s AFA mandate applies to card-not-present and recurring payment scenarios.
3D Secure version requirements: 3DS2 provides significantly more context to the issuer’s risk engine than 3DS1, which matters for authorisation rates.

Challenges in Card Payment Processing

Fraud and Chargebacks

Fraud and chargebacks are the two largest operational cost drivers in card payment processing, and they’re linked.

Card-not-present fraud, where card credentials are stolen and used in digital transactions without the physical card, accounts for the majority of card fraud in e-commerce.

Friendly fraud, where a legitimate cardholder disputes a valid transaction, has grown significantly alongside digital commerce volumes. Both create chargebacks.

Card networks impose chargeback ratio thresholds, typically around 1% of monthly transaction volume. Merchants that breach these thresholds face fines, heightened monitoring programmes, and ultimately the risk of losing their acquiring relationship.

Cross-Border Payment Complexity

International card transactions create friction because:

Cross-border interchange rates are consistently higher than domestic equivalents.
Currency conversion happens at the network level or the issuer level, depending on the card product, and the rate isn’t always disclosed clearly to the cardholder.
Regulatory requirements vary by jurisdiction, data residency rules, transaction reporting obligations, and AML/KYC standards differ across markets.
Some card schemes apply additional cross-border assessment fees on top of standard network charges.

For multinational merchants or businesses with international customer bases, managing these costs requires specific attention in acquirer fee negotiations and in how pricing is structured for different countries.

Payment Authorisation Failures

Not every valid transaction gets approved. The common failure modes:

Insufficient funds or credit availability on the cardholder’s account, a hard decline, not retriable.
Issuer-side fraud holds are placed on the account due to unusual activity patterns.
Technical failures at the issuer, acquirer, or network are less common, but they happen during peak periods.
Credential mismatches: wrong PIN, expired card dates, incorrect CVV entries, etc.
Soft declines requesting additional authentication rather than outright declining.

Enterprise merchants tracking authorisation rates by issuer, by card type, and by channel can often identify specific failure patterns that have fixable root causes. A drop in authorisation rates on cards from one specific issuer, for instance, might indicate an issuer-side fraud rule change that requires a technical adjustment on the merchant side.

Regulatory Compliance Requirements

Compliance in card payments is not a one-time exercise.

PCI-DSS releases new versions; v4.0 introduced substantive changes to authentication and monitoring requirements. RBI updates tokenisation mandates, data localisation rules, and AFA requirements on its own schedule. Card networks issue operating regulation updates periodically that affect how acquirers and merchants must handle specific transaction types.

For enterprise finance and treasury teams, staying current on these changes requires an ongoing relationship with both the acquirer and internal compliance functions.

Real-World Use Cases of Issuer and Acquirer Banks

1. Retail and E-commerce Payments

In physical retail, the acquirer provisions and manages the POS infrastructure, which includes terminals, software, connectivity, and ensures that card acceptance works across tap, chip, and swipe. The issuer’s role is entirely in the authorisation response. The merchant never interacts with the issuer directly.

In e-commerce, the same functional separation holds, but the acquirer’s payment gateway replaces the terminal. Transaction data captured at checkout flows to the acquirer’s gateway, through the card network to the issuer, back to the gateway, and returns an outcome to the checkout page, with the same sub-two-second expectation as in-store.

2. Subscription Billing Payments

Recurring billing, such as monthly SaaS fees, insurance premiums, and utilities auto-pay, works on stored card tokens rather than card credentials re-entered at each cycle. The acquirer initiates each charge on the agreed date against the stored token; the issuer authorises it against the current available funds.

Where subscription billing gets complicated is in failed payment recovery. When an issuer returns a soft decline for insufficient funds or the card has expired, the acquirer’s retry logic determines when to attempt the charge again.

Network tokenisation has materially improved recovery rates here because tokens stay valid even when underlying card numbers change due to renewal or reissuance.

3. International Payment Processing

When a cardholder using an Indian-issued card transacts at a merchant in another country, the card network bridges the two acquiring and issuing banks across borders. Currency conversion is applied at the network level or by the issuer, depending on the card product’s foreign exchange terms.

Settlement between issuer and acquirer happens in the network’s designated settlement currency, typically USD, and the acquirer handles conversion to the merchant’s local currency on the receiving end.

4. ATM and Card Withdrawals

ATM cash withdrawals use the same authorisation chain as card payments. The ATM operator’s bank acts as the acquirer; the cardholder’s bank is the issuer. The transaction routes through the relevant card network, such as Visa, Mastercard, or NFS for domestic RuPay transactions, and the issuer authenticates via PIN and verifies available balance before authorising the withdrawal.

When the cardholder uses their own bank’s ATM, the institution is both issuer and acquirer. The authorisation flow is internal, and interbank settlement isn’t required, which is part of why on-us ATM withdrawals are typically free while off-us transactions carry charges.

Future of Payment Infrastructure

Growth of Digital Payment Networks

Card volumes will keep growing, but the nature of card transactions is changing. Co-branded card programmes are extending formal credit access into previously underserved segments. Contactless and mobile wallet payments are displacing cash in mid-value transaction categories where cash once dominated. New acceptance form factors, like wearables, connected devices, Apple Pay/Samsung Pay, and embedded commerce environments, are pulling card credentials into transaction contexts that didn’t exist five years ago.

For acquirers, this means the acceptance infrastructure of the future needs to handle not just physical plastic but token-based digital credentials across device types that haven’t all been invented yet.

AI-Based Fraud Detection

Rules-based fraud systems are giving way to ML models at both the issuer and acquirer levels. The practical difference is significant:

Rules engines respond to known fraud patterns; ML models identify unknown ones.
Rules require manual updates when fraud tactics change; models retrain continuously.
Rules tend to over-block legitimate transactions (false positives); well-tuned models reduce this materially.

For enterprise merchants, the downstream benefit is higher authorisation rates on legitimate transactions because issuer fraud models that generate fewer false positives decline fewer valid purchases.

Real-Time Payment Authorisation

The industry is actively pushing authorisation latency lower. Direct API connections between high-volume acquirers and major issuers eliminate network routing latency for the most common transaction pairs. Cloud-based issuer processing infrastructure is replacing legacy mainframe systems. Real-time settlement pilots in several markets are beginning to compress the T+1/T+2 settlement window for merchants.

For treasury teams managing working capital, a shift from T+2 to same-day settlement has real liquidity implications.

Embedded Finance and Open Banking

Open banking APIs and embedded finance frameworks are restructuring how payment acceptance is delivered. Payment infrastructure is increasingly packaged as API modules that platforms embed into their own products, rather than merchants navigating separate gateway integrations. ERPs, procurement tools, and fleet management platforms are processing payments without directing users to separate payment interfaces.

For enterprise finance functions, embedded payments reduce operational friction and tighten the connection between payment execution and financial reporting. The reconciliation problem that has historically consumed significant finance team bandwidth is much smaller when payment data flows directly into the systems of record.

Best Practices for Businesses in Payment Processing

Optimise Payment Authorisation Rates

Authorisation rates are a direct revenue metric. Every percentage point of improvement on a high-volume merchant account translates to real transaction value recovered.

Practical levers worth examining:

Network tokenisation (Visa Token Service, Mastercard MDES) for stored card credentials, tokens update automatically when cards are reissued or expire, eliminating a significant category of avoidable declines.
3DS2 with intelligent step-up logic, applying additional authentication only where the issuer’s risk model requires it, rather than on every transaction.
Retry logic calibrated to decline reason codes. For example, soft declines warrant a retry with appropriate timing, and hard declines do not. Retrying them wastes authorisation attempts and can flag the merchant to network monitoring.
Issuer-level decline analysis to identify patterns, a disproportionate decline rate from one issuer often points to a specific technical or compliance issue that can be addressed.

Choose Reliable Payment Infrastructure

The acquirer relationship is not a commodity. How an acquirer performs during a peak transaction period, how quickly its support team responds to settlement discrepancies, and how its API documentation handles edge cases; these factors matter more than headline MDR rates in most enterprise contexts.

Evaluation criteria worth weighting:

Network uptime SLAs with actual historical performance data, not just contractual commitments.
Settlement timing flexibility for treasury management purposes.
API maturity means documentation quality, versioning discipline, and developer support responsiveness.
Chargeback management tooling and the quality of the acquirer’s dispute resolution support.
Support for the specific card types, currencies, and channels the business actually needs, not just a broad claim of coverage.

Ensure Secure Transaction Processing

PCI-DSS compliance is mandatory, not a differentiator. But how a business implements security beyond the baseline compliance floor determines its real exposure:

Tokenisation should be applied at every point where card data is stored, such as CRM, subscription management, and ERP. Raw card numbers stored anywhere are a liability.
End-to-end encryption between merchant systems and the payment gateway protects against man-in-the-middle exposure.
Penetration testing and vulnerability assessments on payment-adjacent infrastructure should be scheduled.
Incident response procedures for potential data breaches need to be documented, tested, and ready to execute. Regulators and card networks expect them, and the response window after a confirmed breach is short.

Monitor Payment Analytics

Payment data is operational intelligence that most enterprise finance teams underuse. The metrics worth tracking consistently:

Authorisation rate by issuer: Identifies where transaction declines are concentrated, which often points to specific remediation actions.
Decline reason code distribution: Separates hard declines from soft declines and surfaces patterns that indicate fixable problems versus irretrievable failures.
Chargeback rate by channel and merchant category: Surfaces fraud exposure patterns before they breach network thresholds and trigger acquirer penalties.
Settlement timing performance against SLA: Confirms funds arrive per contractual terms and flags discrepancies before they affect working capital planning.

Conclusion:

The issuer–acquirer relationship is the structural backbone of card-based commerce. Neither party can function in isolation; the issuer needs a connected merchant ecosystem to give its cards utility; the acquirer needs issuers willing to authorise transactions for merchant revenue to flow. Every card transaction, whether completed at a POS terminal or an online checkout, is the product of both institutions working in coordination.

For enterprise finance and payments professionals, the distinction matters operationally. Authorisation rates, settlement timing, chargeback liability, and compliance obligations all trace back to how well this infrastructure is understood and managed.

The businesses that treat payment infrastructure as a strategic concern, rather than a back-office cost, tend to run cleaner operations and recover more revenue from every transaction they process.

Issuer vs. Acquirer Explained: Who Does What in a Card Transaction?