Card Issuing & Acquiring: The Complete Guide for Enterprise Decision-Makers

Every time a customer swipes a card, taps their phone, or enters payment details online, two distinct but interdependent financial institutions spring into action: the issuing bank and the acquiring bank. Yet despite their critical role in global commerce—processing trillions of dollars annually—most enterprise IT leaders, CTOs, and digital transformation managers have only a vague understanding of how these systems work together, what technology underpins them, or how to evaluate and integrate them effectively.

Card issuing and acquiring form the backbone of modern payment infrastructure. Understanding their roles, responsibilities, and technological ecosystems is essential for any organisation building, integrating, or optimising payment systems. This guide provides the technical depth and business context you need to make informed decisions about your payment infrastructure.

What Is Card Issuing & Acquiring, and Why Should Your Organisation Care?

The Two Sides of Every Card Transaction

Card issuing and acquiring are two complementary but distinct functions in the payment ecosystem. At its core, the distinction is simple: the issuing bank is the financial institution that provides payment cards to consumers and businesses (the cardholder’s bank), while the acquiring bank is the financial institution that enables merchants to accept those cards (the merchant’s bank).

In a typical card transaction, the issuing bank authorises payment from the cardholder’s account, and the acquiring bank facilitates the settlement of funds into the merchant’s account. These two institutions operate on opposite sides of the transaction, each managing different risks, compliance obligations, and customer relationships.

The Business Impact of Understanding Your Payment Infrastructure

For enterprises, understanding card issuing and acquiring is not merely academic. It directly impacts:

• Vendor Selection: Choosing the right issuing or acquiring partner requires evaluating technology capabilities, compliance certifications, integration flexibility, and cost structure. A poor choice can result in integration delays, compliance gaps, and higher processing costs.
• Cost Optimisation: Interchange fees, processing costs, and network fees vary significantly across providers. Understanding the fee structure and negotiating terms requires knowledge of how issuing and acquiring economics work.
• Compliance & Risk Management: Both issuing and acquiring involve strict regulatory requirements (PCI DSS, AML/KYC, fraud prevention). Misunderstanding these obligations can expose your organisation to fines, data breaches, and reputational damage.
• Digital Transformation: Modern payment infrastructure increasingly relies on APIs, real-time processing, and embedded finance. Evaluating whether a vendor supports these capabilities requires understanding the technical landscape.
• System Integration: Whether you’re building a fintech platform, modernising your e-commerce infrastructure, or implementing corporate card programs, integration complexity depends on the issuing/acquiring architecture you choose.

The following sections provide the technical and strategic context you need to navigate these decisions with confidence.

How Does Card Issuing Work? A Technical Deep Dive

The Role of the Issuing Bank

An issuing bank is a financial institution licensed by a card network (Visa, Mastercard, American Express, or Discover) to issue payment cards to consumers and businesses. The issuing bank holds the cardholder’s account and is responsible for authorising or declining transactions based on account status, available funds or credit, and fraud risk assessment.

The issuing bank’s responsibilities extend beyond simple transaction authorisation. They include:

• Card Issuance & Management: Creating physical or virtual cards, managing card lifecycle (activation, replacement, cancellation), and supporting multiple card types (debit, credit, prepaid, corporate).
• Account Management: Maintaining cardholder accounts, processing deposits and withdrawals, managing credit lines or prepaid balances, and providing account statements and reporting.
• Transaction Authorisation: Real-time decision-making on whether to approve or decline a transaction based on available funds, credit limits, fraud signals, and merchant category codes.
• Fraud Detection & Prevention: Deploying machine learning models and rule-based systems to identify suspicious transactions, blocking high-risk payments before they are authorised.
• Cardholder Support: Handling disputes, processing chargebacks, managing fraud claims, and providing customer service (e.g., lost card replacement, PIN resets).
• Regulatory Compliance: Adhering to PCI DSS (Payment Card Industry Data Security Standard), KYC (Know Your Customer), AML (Anti-Money Laundering), and other regulatory requirements.

Consider a corporate card program: the issuing bank provides physical and virtual cards to employees, maintains centralized account management, processes real-time transactions, detects fraudulent usage patterns (e.g., unusual geographic locations or merchant categories), and handles disputes when employees contest charges. The issuing bank bears the financial liability if a cardholder’s account is compromised through no fault of the merchant.

Card Issuing Infrastructure & Technology

Modern card issuing is increasingly driven by cloud-based, API-first platforms that enable rapid card issuance, real-time processing, and sophisticated fraud detection. Understanding the technology stack is critical for organisations evaluating issuing solutions.

The technology stack of an issuing platform typically includes:

• Card Management System (CMS): Manages card lifecycle, activation, deactivation, replacement, and PIN management. Modern systems support instant virtual card generation and dynamic spend controls.
• Authorization Engine: Real-time decision system that evaluates transaction requests against account status, fraud rules, and velocity checks. Uses machine learning for anomaly detection.
• Core Banking Integration: Connection to the issuing bank’s core banking system for account updates, balance inquiries, and fund transfers. Typically via SFTP, APIs, or message queues.
• Fraud Detection System: Machine learning models trained on historical transaction data to identify suspicious patterns (unusual geography, merchant category, transaction amount, velocity). May include 3D Secure or biometric authentication.
• Reporting & Analytics: Real-time dashboards for transaction monitoring, cardholder behaviour analysis, fraud trend detection, and compliance reporting.
• Card Network Integration: Direct or indirect connections to Visa, Mastercard, Amex networks for transaction routing, settlement, and compliance.

For organisations evaluating issuing platforms, key technical considerations include API maturity (RESTful or GraphQL), webhook support for real-time event notifications, SDKs for common programming languages, sandbox environments for testing, and comprehensive documentation for integration.

Transaction Authorisation: How Issuers Approve or Decline Payments

When a cardholder initiates a payment, the issuing bank must make a real-time decision: authorise or decline. This decision is made in milliseconds and involves multiple layers of evaluation.

The authorisation process begins when a transaction request reaches the issuer’s authorisation engine. The engine evaluates:

• Account Status: Is the account active, suspended, or closed? Is the cardholder in good standing?
• Available Funds or Credit: Does the cardholder have sufficient balance (debit) or available credit limit (credit card)?
• Fraud Signals: Is the transaction consistent with the cardholder’s typical spending patterns? Does the merchant category, geography, or amount trigger fraud rules?
• Velocity Checks: Has the cardholder exceeded transaction frequency limits (e.g., 5 transactions per minute)?
• Card Network Rules: Are there card network restrictions on the merchant category (e.g., some networks restrict gambling or adult content)?
• Regulatory Restrictions: Are there country-specific or sanction-related restrictions on the transaction?

If all checks pass, the issuer authorises the transaction and returns an authorisation code to the merchant’s acquirer. If any check fails, the transaction is declined with a specific decline code (e.g., “Insufficient Funds,” “Suspected Fraud,” “Card Expired”). The cardholder may receive a notification and have the option to retry or use an alternative payment method.

Modern issuing platforms increasingly use machine learning to improve authorisation accuracy. Rather than simple rule-based decisions (e.g., “decline if transaction amount > $1,000”), ML models evaluate hundreds of features (cardholder profile, merchant profile, historical behaviour, network graph analysis) to predict fraud probability in real-time. This reduces both false positives (declining legitimate transactions) and false negatives (approving fraudulent ones).

Common Misconceptions About Card Issuing

Misconception 1: Card Networks Issue Cards A common misunderstanding is that Visa or Mastercard issue cards directly to consumers. In reality, Visa and Mastercard are networks that set rules and standards. Banks are the ones that issue cards on behalf of these networks. A bank may issue Visa-branded cards, Mastercard-branded cards, or both, but the bank—not the network—holds the cardholder’s account and bears the liability.

Misconception 2: Issuers and Acquirers Are Interchangeable Some people assume that any bank can serve as both an issuer and an acquirer interchangeably. While it’s true that large banks often hold both roles, the functions are distinct and require different infrastructure, compliance frameworks, and business relationships. A bank may excel at issuing but lack the merchant relationships or acquiring infrastructure to be a competitive acquirer, or vice versa.

Misconception 3: The Issuer Bears All Fraud Liability While issuers generally bear liability for fraudulent transactions, this liability is not absolute. If a merchant fails to comply with card network rules (e.g., not verifying CVV, not using EMV terminals), the merchant or acquiring bank may bear some liability. The concept of “liability shift” determines who bears the cost of fraud in different scenarios.

How Does Card Acquiring Work? A Technical Deep Dive

The Role of the Acquiring Bank

An acquiring bank (or acquirer) is a financial institution that enables merchants to accept card payments. The acquiring bank maintains the merchant’s account, processes card transactions on the merchant’s behalf, manages fund settlement, and ensures compliance with card network rules and regulations.

The acquiring bank’s responsibilities include:

• Merchant Onboarding & Account Management: Underwriting merchants, establishing merchant accounts, managing merchant profiles, and maintaining merchant relationships.
• Transaction Processing: Routing transactions from the merchant’s point-of-sale (POS) system through card networks to the appropriate issuing bank for authorisation.
• Fund Settlement: Collecting authorised transactions, batching them for clearing, and depositing net funds into the merchant’s bank account (typically within 1–2 business days).
• Fraud Prevention & Monitoring: Implementing fraud detection systems to identify suspicious merchant activity, protecting both the acquirer and the card networks.
• Compliance & Risk Management: Ensuring merchants comply with PCI DSS, AML/KYC requirements, and card network rules. Managing chargeback disputes and merchant liability.
• Merchant Support & Reporting: Providing merchant service representatives, transaction reporting, settlement reconciliation, and dispute resolution support.

Consider a large e-commerce retailer: the acquiring bank provides the infrastructure to accept Visa, Mastercard, and American Express payments on the retailer’s website. The acquiring bank routes each transaction to the appropriate issuing bank, collects authorisation responses, batches transactions for settlement, and deposits funds into the retailer’s account daily or weekly. If a customer disputes a charge (chargeback), the acquiring bank investigates and either upholds or reverses the chargeback based on evidence provided by the merchant.

Acquiring Infrastructure & Technology

Acquiring infrastructure is more distributed and integration-heavy than issuing infrastructure. An acquiring bank must integrate with thousands of merchants across different industries, each with different POS systems, e-commerce platforms, and payment requirements.

The core components of acquiring infrastructure include:

• Payment Gateway: The merchant-facing interface that accepts payment data, tokenises sensitive information, and routes transactions to the acquiring bank’s processor. Modern gateways are cloud-based, support multiple payment methods (cards, wallets, bank transfers), and provide webhooks for real-time transaction notifications.
• Authorization Router: Routes transaction requests to the appropriate card network and issuing bank based on card type (Visa, Mastercard, Amex). Handles network communication protocols (ISO 8583 or modern REST APIs).
• Settlement Engine: Batches authorised transactions, calculates merchant settlement amounts (accounting for interchange fees, processing fees, chargebacks), and generates settlement files for deposit into merchant accounts.
• Fraud Detection System: Monitors merchant transactions for suspicious patterns (e.g., unusually high chargeback rates, unusual merchant category shifts, velocity anomalies). Flags high-risk merchants for manual review.
• Chargeback Management System: Tracks chargeback disputes, manages evidence collection, communicates with merchants, and processes chargeback reversals or confirmations.
• Reporting & Analytics: Provides merchants with transaction reports, settlement reconciliation, chargeback analytics, and fraud trend analysis. Often includes dashboards for real-time monitoring.

For merchants, the primary integration point is the payment gateway. Modern gateways provide:

• REST APIs: Programmatic access to initiate payments, refunds, and queries. Enables custom payment flows and integration into e-commerce platforms.
• Pre-built Integrations: Plugins for popular e-commerce platforms (Shopify, WooCommerce, Magento, custom platforms) to simplify setup.
• Hosted Payment Pages: PCI-compliant payment forms that can be embedded in merchant websites, eliminating the need for merchants to handle raw card data.
• Webhooks: Real-time event notifications (transaction authorised, settlement completed, chargeback received) allowing merchants to trigger downstream business logic (e.g., order fulfilment, invoice generation).
• Tokenisation: Converting sensitive card data into non-sensitive tokens, enabling secure storage and reuse for recurring payments or one-click checkout.

The Acquiring Side of Transaction Processing

From the merchant’s perspective, the acquiring process appears simple: customer enters payment details, transaction is approved, funds are deposited. Behind the scenes, the acquiring bank orchestrates a complex set of operations.

When a merchant submits a transaction through their payment gateway, the acquiring bank:

1. Validates the Transaction: Checks that the transaction data is complete and correctly formatted. Performs basic fraud checks (card number format, CVV validity).
2. Routes to Card Network: Sends the transaction to the appropriate card network (Visa, Mastercard, Amex) with merchant and transaction details.
3. Receives Authorisation Response: The card network forwards the transaction to the issuing bank, which authorises or declines. The response is returned to the acquiring bank in milliseconds.
4. Returns Response to Merchant: The acquiring bank communicates the authorisation result to the merchant’s POS system or payment gateway (approved with authorisation code, or declined with reason code).
5. Batches for Settlement: Throughout the day, the acquiring bank collects all authorised transactions and prepares them for settlement. Typically, transactions are batched and submitted to the card network for clearing at the end of the business day.
6. Clearing & Settlement: The card network clears the batch (ensuring all transactions are valid and balances are correct) and initiates fund transfer from issuing banks to the acquiring bank. The acquiring bank then deposits net funds into the merchant’s account (T+1 or T+2).

Throughout this process, the acquiring bank is responsible for reconciling transactions, managing exceptions (declined transactions, duplicates, reversals), and providing accurate settlement reporting to the merchant.

Interchange Fees and the Cost of Acquiring

One of the most misunderstood aspects of acquiring is the fee structure. Merchants often see a single “processing fee” on their statement, but the cost of acquiring is actually composed of multiple components.

Interchange Fees: These are fees paid by the acquiring bank to the issuing bank for each transaction. They are set by the card networks (Visa, Mastercard) and vary based on card type (credit vs. debit), merchant category, transaction amount, and region. For example, a Visa credit card transaction at a restaurant might have an interchange rate of 2.2% + $0.10, while a debit card transaction at a supermarket might be 0.5% + $0.22. Interchange fees are the largest component of payment processing costs for merchants.

Card Network Fees: Visa, Mastercard, Amex, and Discover charge assessment and processing fees to acquiring banks for the privilege of accepting their cards. These fees are typically small (0.1–0.3% of transaction volume) but are often passed through to merchants.

Acquiring Bank Markup: The acquiring bank adds its own markup on top of interchange and network fees to cover operational costs, fraud prevention, customer support, and profit margin. This markup varies based on merchant size, transaction volume, and competitive dynamics.

Merchant Discount Rate (MDR): The total fee visible to the merchant, typically expressed as a percentage of transaction value plus a per-transaction fee. For example, “2.9% + $0.30 per transaction.” This MDR includes interchange, network fees, and the acquiring bank’s markup.

For enterprises, understanding this fee structure is critical for cost optimisation. Large merchants can negotiate lower interchange rates or volume discounts with acquiring banks. Some merchants use multiple acquirers to optimise fees across different card types or merchant categories.

What Is the Complete Card Transaction Flow?

The Five-Step Payment Journey

To fully understand card issuing and acquiring, it’s essential to follow a transaction from initiation to final settlement. The payment journey consists of five distinct phases:

1. Submission: The cardholder initiates a payment at a merchant (online, in-store, or over the phone). The merchant’s POS system or payment gateway collects payment data (card number, expiration date, CVV, cardholder name, transaction amount). For security, this data is immediately encrypted and tokenised; the merchant’s system never stores the raw card data.

2. Authorization: The merchant’s payment gateway submits the transaction to the acquiring bank, which routes it through the appropriate card network to the issuing bank. The issuing bank’s authorization engine evaluates the transaction (as described earlier) and responds with an authorisation code (approved) or decline code (declined). This entire process typically takes 100–500 milliseconds. The merchant receives the response and either completes the transaction (approved) or prompts the customer to use an alternative payment method (declined).

3. Authentication: For certain transactions (e.g., high-value, high-risk, or international), the card network may require additional authentication. This often involves 3D Secure (3DS), which prompts the cardholder to authenticate via their issuing bank (e.g., password, one-time code, biometric). Authentication adds security but may slightly increase decline rates or checkout friction.

4. Clearing: At the end of each business day, the merchant’s acquiring bank batches all authorised transactions and submits them to the card network. The card network validates the batch (ensuring all transactions are legitimate and balances are correct) and forwards the batch to the respective issuing banks. Issuing banks confirm they have sufficient funds and are ready to settle. This process typically occurs overnight and is completed within a few hours.

5. Settlement: Once clearing is complete, funds are transferred from issuing banks to the card network, and then from the card network to the acquiring bank. The acquiring bank calculates the net settlement amount for each merchant (total authorised amount minus interchange fees, chargebacks, and refunds) and deposits funds into the merchant’s bank account. Settlement typically occurs within 1–2 business days (T+1 or T+2).

How Issuing and Acquiring Banks Work Together

While issuing and acquiring banks operate independently, they are tightly integrated through card networks. The card network serves as the intermediary, ensuring standardised communication and secure fund transfers.

The communication between issuer and acquirer occurs through standardised protocols. Historically, this was the ISO 8583 protocol, a binary message format used for decades in payment processing. Modern payment networks increasingly use REST APIs and JSON-based protocols for flexibility and ease of integration.

When an acquiring bank submits a transaction to a card network, the message includes:

• Card number (PAN — Primary Account Number)
• Transaction amount and currency
• Merchant information (ID, category, location)
• Cardholder information (name, address, CVV)
• Transaction type (purchase, refund, reversal)
• Timestamp and sequence number

The card network routes this message to the appropriate issuing bank based on the card number (the first 6 digits, called the Bank Identification Number or BIN, identify the issuer). The issuing bank processes the authorisation request and returns a response message with:

• Authorisation code (if approved)
• Response code (e.g., “00” for approved, “05” for declined)
• Reason for decline (if applicable)
• Additional fraud indicators or warnings

This entire exchange happens in real-time, with the card network ensuring reliable, secure message delivery and maintaining audit logs for compliance and dispute resolution.

Settlement and Fund Movement: The Financial Side

While the authorization and clearing phases happen quickly (within hours), settlement—the actual movement of funds—takes longer due to banking infrastructure constraints.

In most markets, settlement occurs on a T+1 or T+2 basis, meaning merchants receive funds 1–2 business days after the transaction is authorised. This delay exists because:

• Batch Processing: Transactions are batched and submitted in bulk, typically once per day, rather than individually. This reduces network overhead and operational costs.
• Clearing House Operations: Clearing houses (operated by card networks or banking consortiums) aggregate transactions from thousands of merchants and issuers, validate them, and orchestrate fund transfers. This process takes time.
• Banking Infrastructure: Actual fund transfers between banks occur through banking infrastructure (e.g., ACH in the US, SEPA in Europe), which operates on daily cycles rather than in real-time.
• Chargeback Window: Card networks maintain a window (typically 2–3 days) during which chargebacks can be initiated. Delaying settlement allows time for chargebacks to be identified and netted against settlement amounts.

Emerging real-time payment systems (such as RTP in the US or Instant Payments in Europe) are beginning to compress settlement timelines, enabling T+0 (same-day) settlement. However, these systems are not yet universally available and are typically used for specific transaction types or high-value payments.

What Happens When a Transaction Is Declined?

Not every transaction is approved. Declines occur for various reasons, and understanding why—and how to recover from them—is important for merchants and cardholders alike.

Common Decline Reasons:

• Insufficient Funds: The cardholder’s account balance or available credit is insufficient for the transaction amount.
• Card Expired: The card’s expiration date has passed.
• Incorrect CVV: The cardholder entered an incorrect CVV, suggesting they may not have the card in hand.
• Suspected Fraud: The issuer’s fraud detection system flagged the transaction as suspicious (unusual geography, merchant, amount, or velocity).
• Lost or Stolen Card: The card has been reported as lost or stolen and is blocked by the issuer.
• Velocity Limit Exceeded: The cardholder has exceeded transaction frequency limits (e.g., too many transactions in a short period).
• Merchant Category Restriction: The card network or issuer restricts transactions in certain merchant categories (e.g., gambling, adult content).
• Geographic Restriction: The transaction is in a country or region where the card is not permitted to be used.

When a transaction is declined, the merchant’s POS system receives a decline code (a standardised numeric or alphanumeric code) that indicates the reason. The merchant can display this reason to the customer (e.g., “Your bank declined this transaction. Please contact your bank.”) or, for certain decline reasons, prompt the customer to retry or use an alternative payment method.

For merchants, high decline rates are problematic because they result in lost sales. For issuers, declining too many legitimate transactions (false positives) damages customer experience and may cause customers to switch banks. Modern issuing platforms use machine learning to balance fraud prevention with authorisation approval rates, aiming to minimise both fraud losses and false declines.

What Are the Key Differences Between Issuing and Acquiring?

Role & Responsibility Comparison

While issuing and acquiring are complementary functions, they differ significantly in their roles, responsibilities, and risk profiles. Understanding these differences is critical for evaluating vendors and designing integrated payment systems.

Regulatory & Compliance Differences

Issuing and acquiring operate under different regulatory regimes and compliance frameworks, each designed to protect different stakeholders.

Issuer Compliance Focus: Issuers must comply with consumer protection regulations, including fraud liability limits (in many jurisdictions, cardholders are not liable for unauthorised transactions), dispute resolution timelines, and cardholder communication requirements. They must also comply with AML/KYC regulations for account opening and transaction monitoring. PCI DSS compliance is required to protect cardholder data stored in their systems.

Acquirer Compliance Focus: Acquirers must ensure merchants comply with card network rules and regulations. This includes PCI DSS compliance (merchants must not store raw card data), proper transaction documentation, and correct merchant categorisation. Acquirers must also monitor merchants for suspicious activity (e.g., unusually high chargeback rates, unusual transaction patterns) and may terminate merchant accounts that pose excessive risk. AML/KYC compliance is required for merchant onboarding and ongoing monitoring.

Both issuers and acquirers must comply with PCI DSS, but for different reasons: issuers to protect cardholder data in their systems, and acquirers to ensure merchants handle data securely and to protect themselves from liability.

Technology Stack Differences

The technology stacks of issuing and acquiring platforms differ significantly, reflecting their different operational requirements.

Issuing Technology Stack: Focuses on real-time transaction authorisation, fraud detection, and account management. Core systems include core banking platforms (for account management), card management systems (for card lifecycle), authorisation engines (for real-time decision-making), and fraud detection systems. Integration is primarily with card networks (for transaction routing) and internal systems (for account updates). Latency is critical; authorisation decisions must be made in milliseconds.

Acquiring Technology Stack: Focuses on transaction routing, settlement, and merchant support. Core systems include payment gateways (merchant-facing), authorisation routers (for network routing), settlement engines (for fund movement), and merchant reporting systems. Integration is extensive: with merchants (thousands of different POS systems and e-commerce platforms), with card networks, with issuing banks, and with clearing houses. Throughput and reliability are critical; the system must handle millions of transactions per day without errors.

An issuing platform prioritises latency and real-time decision-making, while an acquiring platform prioritises throughput, reliability, and integration flexibility.

Can a Bank Be Both an Issuer and an Acquirer?

Yes. In fact, most large banks hold both roles. A bank may issue Visa and Mastercard credit cards to consumers (issuing) while also providing merchant acquiring services to businesses (acquiring). Examples include major global banks like JPMorgan Chase, Bank of America, and HSBC, which are among the largest issuers and acquirers globally.

However, holding both roles presents challenges:

• Operational Complexity: Issuing and acquiring require different technology stacks, business processes, and compliance frameworks. Integrating these into a single organisation requires careful architecture to avoid conflicts.
• Conflict of Interest: An issuer benefits from high interchange fees (paid by acquirers), while an acquirer wants to minimise interchange fees (paid to issuers). A bank holding both roles may face pressure to balance these conflicting interests.
• Competitive Disadvantage: A bank that is both an issuer and acquirer may be perceived as having conflicts of interest, which can damage its reputation with merchants (who want lower fees) or cardholders (who want better card benefits).

For this reason, many successful payment companies specialise in either issuing (e.g., Revolut, N26, which are digital banks focused on card issuing) or acquiring (e.g., Square, Stripe, which are payment processors focused on merchant acquiring). Specialisation allows these companies to optimise their technology, operations, and business models for their specific focus area.

What Is the Role of Card Networks in Issuing & Acquiring?

Understanding Visa, Mastercard, American Express, and Discover

Card networks—Visa, Mastercard, American Express, and Discover—are often confused with issuing or acquiring banks. In reality, they serve a distinct role: they are the infrastructure and rule-setters that enable issuers and acquirers to communicate and settle funds.

Card networks do not:

• Issue cards directly to consumers (banks do)
• Acquire transactions from merchants (banks do)
• Hold cardholder accounts or merchant accounts
• Bear fraud liability for individual transactions

Instead, card networks:

• Set rules and standards for card issuance, transaction processing, and settlement
• Operate the infrastructure that routes transactions between issuers and acquirers
• Manage clearing and settlement processes
• Enforce compliance with network rules
• Collect fees from issuers and acquirers for the privilege of using the network

A helpful analogy: card networks are like postal services. They don’t create the letters (cards) or receive the packages (transactions); they simply provide the infrastructure to deliver messages between senders (issuers) and receivers (acquirers).

How Card Networks Facilitate Issuer-Acquirer Communication

Card networks maintain vast, globally distributed networks of computers and communication infrastructure to route transactions in real-time. When an acquiring bank submits a transaction to a card network, the network must:

1. Identify the Issuer: Using the card number (specifically, the Bank Identification Number or BIN), the network identifies which issuing bank issued the card.
2. Route the Transaction: The network forwards the transaction to the issuing bank’s systems via secure, high-speed connections.
3. Return the Response: The issuing bank’s authorisation system processes the transaction and returns a response (approved or declined) to the card network.
4. Deliver to Acquirer: The card network forwards the response back to the acquiring bank, which delivers it to the merchant’s POS system.

This entire process happens in milliseconds, thanks to card networks’ sophisticated infrastructure. Visa and Mastercard operate multiple data centres globally, with redundancy to ensure 99.99%+ uptime. They use advanced routing algorithms to direct transactions to the nearest issuing bank systems, minimising latency.

Historically, card networks used proprietary binary protocols (ISO 8583) for communication. Modern networks increasingly support REST APIs and JSON-based protocols, enabling easier integration with modern software systems and reducing the need for specialised payment software.

Card Network Fees and Economics

Card networks generate revenue by charging fees to issuers and acquirers. These fees include:

• Assessment Fees: Annual or per-transaction fees charged to banks for the privilege of issuing or acquiring cards on the network. Typically 0.1–0.3% of transaction volume.
• Interchange Fees (set by networks, collected by issuers): While interchange fees are technically set by card networks and collected by issuing banks, they are a significant source of revenue for the networks themselves, as they influence the overall economics of the payment system.
• Processing Fees: Fees for processing transactions, clearing, and settlement. These are typically small but add up across billions of transactions.
• Compliance & Certification Fees: Fees for PCI DSS certification, network compliance audits, and security assessments.

For large issuers and acquirers, these fees are significant operational costs. For this reason, large banks often negotiate volume discounts with card networks, and some large acquirers (like Stripe or Square) have negotiated special arrangements with networks to optimise their cost structure.

What Are the Modern Trends in Card Issuing & Acquiring?

Virtual Cards and Embedded Finance

Virtual cards—digital-only card numbers that exist only in software—are one of the fastest-growing segments of card issuing. Unlike physical cards, virtual cards can be generated instantly, customised for specific purposes (e.g., single-use, merchant-locked, spend-limited), and managed entirely through software.

Virtual cards are particularly valuable for:

• B2B Payments: Companies issue virtual cards to employees for expense management or to vendors for payment. Each card can have spend limits, merchant restrictions, and expiration dates, providing granular control.
• Fraud Prevention: Single-use virtual cards eliminate the risk of card reuse or data breach; if a virtual card number is compromised, the card is already expired or locked to a specific merchant.
• Subscription Management: Customers can issue unique virtual cards for each subscription service, simplifying cancellation and preventing unwanted recurring charges.

Embedded Finance refers to the integration of financial services (including card issuing) into non-financial platforms. For example, a SaaS platform might offer whitelabel card issuing to its users, enabling them to issue cards to their own customers without needing to partner with a bank directly. Embedded finance is enabled by BaaS (Banking-as-a-Service) providers who provide the underlying issuing infrastructure via APIs.

Open Banking and API-First Architectures

Open banking regulations (such as PSD2 in Europe) mandate that banks open their APIs to third-party developers, enabling new payment solutions and integrations. This has accelerated the shift toward API-first payment architectures.

Modern payment platforms increasingly offer:

• RESTful APIs: Replacing legacy ISO 8583 or SFTP-based integrations with modern REST APIs that are easier to integrate with modern software systems.
• Webhooks: Real-time event notifications (transaction authorised, settlement completed, chargeback received) enabling merchants and platforms to react immediately to payment events.
• Microservices Architecture: Breaking down monolithic payment systems into smaller, independently deployable services (authorisation, settlement, fraud detection) that can be scaled and updated independently.
• Multi-Currency & Multi-Network Support: Modern platforms support multiple card networks (Visa, Mastercard, Amex, local networks), multiple currencies, and multiple settlement methods, providing merchants with flexibility.

For organisations building payment systems, the shift to API-first architectures means greater flexibility, faster integration, and easier vendor switching. Rather than being locked into a single vendor’s proprietary system, organisations can mix and match best-of-breed components (issuing from one vendor, acquiring from another, fraud detection from a third).

Real-Time Payment Systems

Traditional payment settlement (T+1 or T+2) is increasingly seen as a competitive disadvantage in a real-time economy. Emerging real-time payment systems enable funds to move between accounts in seconds, not days.

Examples include:

• RTP (Real-Time Payments): Operated by The Clearing House in the US, RTP enables 24/7 fund transfers in seconds. It’s increasingly adopted for B2B payments, payroll, and peer-to-peer transfers.
• Instant Payments: Mandated in Europe via SEPA Instant Credit Transfer, enabling fund transfers in seconds across European banks.
• Faster Payments: Operated by Faster Payments Service in the UK, enabling same-day fund transfers.

Real-time payment systems bypass traditional card networks and clearing houses, operating directly between banks. For merchants, this means faster access to funds, reducing working capital requirements. For consumers, it means faster money movement and reduced settlement delays.

Blockchain and Distributed Ledger Technology

While still emerging, blockchain technology is beginning to play a role in payment settlement, particularly for cross-border payments and cryptocurrency transactions.

Potential applications include:

• Cross-Border Settlement: Using blockchain to enable direct settlement between banks without intermediaries, reducing settlement time and cost for international payments.
• Cryptocurrency Card Issuing: Issuing cards that are backed by cryptocurrency (e.g., stablecoins) rather than traditional bank accounts, enabling instant settlement and programmable payments.
• Smart Contracts: Automating complex payment logic (e.g., conditional payments, escrow, multi-signature approvals) through smart contracts on blockchain networks.

Blockchain adoption in mainstream payment processing remains limited, but several major payment companies (including Stripe, which offers cryptocurrency payment processing) are exploring these technologies for future payment infrastructure.

How Should Your Organisation Evaluate Issuing & Acquiring Solutions?

Key Vendor Selection Criteria

Selecting an issuing or acquiring partner is a significant decision with long-term implications for your organisation’s payment infrastructure. Key evaluation criteria include:

• Technology Maturity: Is the platform built on modern, scalable architecture? Does it support the latest payment methods, security standards, and integration patterns? Can it handle your current transaction volume and future growth?
• API Quality & Documentation: Are APIs well-designed, thoroughly documented, and easy to integrate? Are SDKs available for your technology stack? Is there a sandbox environment for testing?
• Compliance & Security: Is the vendor PCI DSS compliant? Do they undergo regular security audits? What compliance certifications do they hold (SOC 2, ISO 27001, etc.)? How do they handle data protection and breach notification?
• Scalability & Reliability: What are their SLA commitments? Can they handle traffic spikes during peak periods? What is their uptime history? Do they have redundancy and disaster recovery plans?
• Cost Structure: What are the fees? Are there volume discounts? How transparent is the pricing? Are there hidden fees or unexpected charges?
• Integration Flexibility: Can you integrate with your existing systems? Do they support multiple payment methods, currencies, and settlement methods? Can you customise the platform for your specific needs?
• Support & Operations: What level of customer support is available? Are there dedicated account managers for enterprise customers? What is the response time for critical issues?
• Roadmap & Innovation: Are they investing in new features and technologies? Do they have a clear product roadmap? Are they responsive to customer feedback?

Integration Considerations for Your Payment Stack

Integrating issuing or acquiring solutions into your existing technology stack requires careful planning. Key considerations include:

• API Design: Ensure the vendor’s APIs align with your architecture. Do they use REST, GraphQL, or proprietary protocols? Are the APIs versioned, allowing for backward compatibility as the vendor evolves?
• Event-Driven Architecture: Modern payment systems should support webhooks or message queues for real-time event notifications. This enables your downstream systems (order management, accounting, analytics) to react immediately to payment events.
• Data Consistency: How do you ensure data consistency between your systems and the payment platform? What happens if there are network failures or timeouts? Do they provide idempotency keys to prevent duplicate processing?
• Reporting & Analytics: What reporting and analytics capabilities does the vendor provide? Can you export transaction data for analysis? Do they provide real-time dashboards or only batch reports?
• Testing & Sandbox: Do they provide a sandbox environment for testing? Can you test different scenarios (declined transactions, chargebacks, fraud)? What test data is available?

Risk Management & Compliance in Issuing & Acquiring

Payment systems are high-risk environments, and compliance failures can result in significant fines, reputational damage, and loss of payment processing privileges. Key compliance considerations include:

• PCI DSS Compliance: If you are storing, processing, or transmitting card data, you must comply with PCI DSS. The level of compliance required depends on your transaction volume and how you handle card data. Many organisations use tokenisation to avoid storing raw card data, reducing compliance burden.
• AML/KYC Compliance: Both issuers and acquirers must comply with AML/KYC regulations. If you are issuing cards or acquiring for high-risk merchants, you must have robust customer due diligence and transaction monitoring processes.
• Fraud Controls: Implement fraud detection systems to identify suspicious transactions and merchants. Monitor chargeback rates and take action if they exceed acceptable thresholds.
• Data Governance: Establish policies for data retention, access control, and breach notification. Ensure that only authorised personnel have access to sensitive payment data.
• Audit & Monitoring: Regularly audit your payment processes and systems. Monitor transaction logs for anomalies. Conduct penetration testing and security assessments.

Cost Optimisation Strategies

Payment processing is often one of the largest operational costs for merchants and payment platforms. Cost optimisation strategies include:

• Interchange Negotiation: For large merchants or acquirers, negotiate lower interchange rates based on transaction volume and mix. Some card networks offer reduced rates for specific merchant categories or transaction types.
• Fee Benchmarking: Compare your current fees with competitors. If your acquiring bank’s fees are significantly higher than market rates, consider switching vendors or renegotiating terms.
• Settlement Optimisation: Negotiate faster settlement (T+0 or same-day) if available. Faster settlement reduces working capital requirements and improves cash flow.
• Payment Method Diversification: Offer alternative payment methods (bank transfers, digital wallets, buy-now-pay-later) that may have lower fees than card payments.
• Fraud Reduction: Implement robust fraud detection to reduce chargebacks and fraud losses. Each chargeback typically costs the merchant $20–$100 in fees and operational costs.

Frequently Asked Questions

What is the difference between a card issuer and an acquirer?

The key difference is which side of the transaction they operate on. An issuing bank provides cards to cardholders and authorises transactions from the cardholder’s account. An acquiring bank enables merchants to accept card payments and settles funds into the merchant’s account. In simple terms: issuers work on behalf of cardholders, acquirers work on behalf of merchants.

What does an acquiring bank do?

An acquiring bank enables merchants to accept card payments. Their responsibilities include: maintaining merchant accounts, routing transactions to card networks, obtaining authorisation from issuing banks, batching transactions for clearing and settlement, depositing funds into merchant accounts, managing chargebacks, and ensuring merchant compliance with card network rules.

What does an issuing bank do?

An issuing bank provides payment cards to cardholders and is responsible for: issuing and managing cards, maintaining cardholder accounts, authorising transactions in real-time, detecting fraud, managing chargebacks, and providing cardholder support. The issuing bank bears liability for unauthorised transactions and must comply with consumer protection regulations.

How does card payment processing work?

Card payment processing involves five steps: (1) Submission—the cardholder initiates a payment; (2) Authorisation—the acquiring bank routes the transaction to the issuing bank, which approves or declines; (3) Authentication—for high-risk transactions, additional authentication may be required; (4) Clearing—at the end of the day, transactions are batched and validated; (5) Settlement—funds are transferred from issuing banks to the acquiring bank to the merchant’s account, typically within 1–2 business days.

Can a bank be both an issuer and an acquirer?

Yes. Large banks often hold both roles. For example, JPMorgan Chase issues credit cards to consumers and provides merchant acquiring services to businesses. However, holding both roles presents operational complexity and potential conflicts of interest. Many successful payment companies specialise in either issuing or acquiring to optimise their technology and business model.

What is a payment facilitator, and how does it relate to acquiring?

A payment facilitator (PayFac) is a company that simplifies merchant onboarding by acting as an intermediary between merchants and acquiring banks. Rather than each merchant establishing a direct relationship with an acquiring bank, the PayFac onboards merchants and processes their transactions, then settles with the acquiring bank. PayFacs enable faster merchant onboarding and lower operational costs, particularly for small merchants.

What are interchange fees?

Interchange fees are fees paid by the acquiring bank to the issuing bank for each card transaction. They are set by card networks (Visa, Mastercard) and vary based on card type, merchant category, transaction amount, and region. Interchange fees are the largest component of payment processing costs for merchants and are a significant revenue source for issuing banks.

How is a chargeback handled?

When a cardholder disputes a transaction, they file a chargeback request with their issuing bank. The issuing bank notifies the acquiring bank, which notifies the merchant. The merchant has an opportunity to provide evidence that the transaction was legitimate (order confirmation, shipping proof, cardholder signature). The issuing bank reviews the evidence and either upholds the chargeback (funds are returned to the cardholder) or reverses it (funds remain with the merchant). The entire process typically takes 30–90 days.

What is PCI DSS compliance?

PCI DSS (Payment Card Industry Data Security Standard) is a set of security standards that organisations handling card data must comply with. Requirements include encryption of sensitive data, secure network architecture, regular security testing, and access controls. The level of compliance required depends on transaction volume and how card data is handled. Many organisations use tokenisation to avoid storing raw card data, reducing compliance requirements.

What are virtual cards?

Virtual cards are digital-only card numbers that exist only in software, without a physical card. They can be generated instantly, customised for specific purposes (single-use, merchant-locked, spend-limited), and managed entirely through software. Virtual cards are valuable for fraud prevention, expense management, and subscription management.

What are the latest trends in payment processing?

Key trends include: (1) Virtual cards and instant issuance; (2) Open banking and API-first architectures; (3) Real-time payment systems enabling same-day or instant settlement; (4) Embedded finance enabling card issuing within third-party platforms; (5) Blockchain and cryptocurrency payment processing; (6) AI-powered fraud detection and authorisation optimisation.