How Card Network Works
Every card payment relies on a card network acting as the central messaging layer between the merchant's bank and the cardholder's bank. The network does not hold money — it routes encrypted authorization messages and enforces the rulebook that all participants agree to follow when they join the scheme. Understanding this flow is essential for troubleshooting declines, optimizing authorization rates, and correctly attributing transaction costs.
Cardholder initiates payment
The customer presents a card — physical, digital wallet, or card-on-file — at checkout. The terminal or payment page captures the primary account number (PAN), expiry date, and CVV, then passes this data to the merchant's payment stack for processing.
Acquirer sends authorization request
The merchant's acquirer packages the transaction data into a standardized ISO 8583 message and forwards it to the card network identified by the card's Bank Identification Number (BIN). The acquirer is the licensed bank or processor that holds the merchant's account.
Network routes to the issuer
The card network receives the authorization request and routes it in real time to the issuer — the bank or fintech that issued the card to the cardholder. The network applies routing logic, fraud screening rules, and velocity checks at this stage before the message reaches the issuer.
Issuer approves or declines
The issuing bank evaluates available funds or credit, fraud signals, 3D Secure authentication results, and any velocity blocks on the account. It returns a response code — approved, declined, or referred — to the network within milliseconds.
Network relays the response
The network forwards the issuer's response back to the acquirer and on to the merchant's terminal or checkout page. The full round trip — from the moment the card is presented to the moment the customer sees a result — typically takes under two seconds.
Clearing and settlement
At end of day, the network facilitates clearing: transaction records are exchanged between acquirers and issuers, interchange fees are calculated against each transaction, and net settlement files are sent to banks so funds physically move between accounts — usually within one to two business days.
Why Card Network Matters
The card network layer is not an optional abstraction — it is the single most influential factor in whether a payment succeeds, how much it costs, and who carries liability when something goes wrong. Merchants, PSPs, and developers who treat the network as a black box routinely leave margin on the table and misdiagnose preventable failures.
Global reach drives revenue. Visa alone operates in over 200 countries and territories, processing more than 276 billion transactions in fiscal year 2023. Mastercard reported over $9 trillion in gross dollar volume for the same period. Without network rails, cross-border ecommerce at scale is simply not possible — no alternative infrastructure comes close to the acceptance footprint of the major schemes.
Fee structures shape margins. Card networks publish the interchange tables that determine scheme fees and the interchange rates that flow between banks. In the European Economic Area, interchange on consumer credit cards is capped at 0.3% by regulation; in the United States, premium credit cards can carry interchange above 2.5%. The network you accept, and the card type your customer uses on that network, directly determines your cost per transaction.
Security standards are network-mandated. PCI DSS compliance, 3D Secure 2.x liability shifts, and tokenization requirements are all governed or strongly shaped by card network rules. A misconfigured 3DS flow can shift chargeback liability from the issuer to the merchant overnight, turning an otherwise manageable dispute rate into a significant financial exposure.
Industry projection
The Nilson Report (2024) projects that card payments will account for 46% of all global point-of-sale transactions by 2027, up from 42% in 2022. Optimizing your card network strategy is a long-term margin lever, not a one-time ops task.
Card Network vs. Payment Processor
Merchants frequently conflate card networks with payment processors. The two are distinct layers with different roles, commercial relationships, and technical interfaces. Mixing them up leads to misdirected escalations and incorrect cost attribution.
| Dimension | Card Network | Payment Processor |
|---|---|---|
| Role | Sets rules; routes auth messages; settles funds between banks | Connects merchant to networks; handles technical integration |
| Examples | Visa, Mastercard, Amex, UnionPay, Discover | Stripe, Adyen, Worldpay, Braintree, Checkout.com |
| Direct merchant contract? | No — works through acquirers | Yes — merchant contracts with processor or acquirer |
| Revenue model | Scheme fees charged to issuers and acquirers | Merchant discount rate (MDR), gateway and processing fees |
| Controls interchange? | Yes — publishes rate tables for every card type | No — passes interchange through to merchant on cost-plus pricing |
| Owns card brand? | Yes | No |
| Handles disputes? | Defines chargeback rules, timelines, and liability shifts | Manages the operational dispute workflow on the merchant's behalf |
| Network failover? | N/A — each network is independent | Can route across networks with smart routing configuration |
The practical implication: when a payment is declined, the root cause may lie at the network level (e.g., a country block or scheme-level fraud score), the processor level (e.g., a misconfigured MID or capability gap), or the issuer level (e.g., insufficient funds or a security hold). Effective debugging requires knowing which layer owns the problem.
Types of Card Network
Not all card networks operate on the same model or serve the same market. Understanding the distinctions helps merchants configure acceptance correctly and gives developers the context to route transactions optimally across different geographies and use cases.
Open-loop networks operate a four-party model: cardholder, issuer, acquirer, and the network itself. The network does not issue cards or acquire merchants — it governs the rails and collects scheme fees from both sides. Visa and Mastercard are the definitive examples, together holding over 65% of global purchase transaction volume.
Closed-loop networks own both ends of the transaction. American Express and Discover historically issued cards directly and acquired most of their merchants, allowing them to capture more margin per transaction and maintain a direct data relationship with both parties. Both networks have since opened their rails to third-party issuers and acquirers, partially converging with the open-loop model.
Regional networks serve specific geographies with competitive pricing or regulatory advantages. China UnionPay (CUP) is the world's largest network by card count, with over 9 billion cards issued. India's RuPay, Brazil's Elo, and Canada's Interac operate primarily within their home markets and are frequently mandated by local regulation for domestic debit transactions.
Debit-specific networks such as Interac (Canada) and NETS (Singapore) process debit transactions separately from the international schemes. In the United States, the Durbin Amendment requires most debit cards to carry at least two unaffiliated network logos, which enables least-cost routing — merchants can instruct their acquirer to choose the cheaper eligible debit network on every transaction.
Best Practices
Optimizing your card network strategy requires different actions depending on whether you are a merchant configuring payment acceptance or a developer building payment infrastructure. Both perspectives matter for reducing cost and maximizing authorization rates.
For Merchants
Enable least-cost routing on debit. Where regulations and your acquirer support it, configure your terminal or PSP to route debit transactions over the cheapest eligible network. In Australia and the United States, LCR on dual-network debit cards has been shown to reduce per-transaction processing costs by 30–60 basis points at scale.
Monitor decline codes segmented by network. Not all declines are equal and not all originate at the same layer. A "Do Not Honour" (response code 05) from the issuer is a fundamentally different problem from an "Invalid Transaction" (12) at the network level. Building dashboards that split decline data by network, response code category, and card type accelerates root-cause analysis.
Request interchange-plus pricing. Some acquirers bundle network fees into an opaque flat MDR. Pushing for interchange-plus or cost-plus pricing gives full visibility into what each network actually costs you per card type and transaction method — essential data for routing decisions and fee negotiations.
Verify network coverage before entering new markets. Visa and Mastercard alone do not guarantee full coverage in every geography. Entering Brazil without Elo acceptance, or China without UnionPay, means turning away a material share of local cardholders. Map network market share against your target geographies before launch.
For Developers
Parse BIN data accurately. The first 6–8 digits of a card number (the Bank Identification Number) identify the network, issuer, card type, and country of issuance. Use a current BIN database to display the correct network logo, apply the right 3DS flow, and route to an acquirer with the strongest acceptance rates for that combination.
Implement network tokenization. Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) replace raw PANs with network tokens that automatically update when a card is reissued. This materially reduces failed recurring charges and shrinks the chargeback surface area by keeping payment credentials current without any cardholder action.
Build network-aware retry logic. ISO 8583 response codes are standardized across networks, but schemes layer proprietary sub-codes on top. Classify every decline as a hard decline (do not retry), a soft decline (retry after a delay), or a do-not-retry (permanent block). Retrying hard declines burns authorization attempts and can trigger issuer-level velocity blocks that harm your approval rate across all future transactions.
Use network-specific test card ranges. A processor sandbox that approves every transaction will not surface network-level edge cases such as cross-border country restrictions, 3DS challenge triggers, or scheme-specific velocity rules. Request network-branded test card ranges and simulate real decline scenarios before going live.
Common Mistakes
Even experienced payment teams make costly errors at the card network layer. These mistakes are frequently invisible until they show up as unexplained margin erosion, elevated decline rates, or compliance fines.
1. Conflating the network with the issuer. A Visa card is not issued by Visa — it is issued by a licensed member bank that carries the Visa brand. Billing disputes, fraud claims, and card blocks are handled by the issuer, not the network. Routing customer complaints or operational escalations to the wrong party wastes time and delays resolution for cardholders.
2. Ignoring annual scheme fee updates. Card networks publish fee schedule changes every year, often in October or November for a January effective date. Merchants on interchange-plus pricing see these changes directly; those on bundled pricing absorb them silently. Failing to model the impact of fee changes quarterly can leave finance teams with unexplained cost increases at year-end.
3. Missing network compliance mandates. Visa and Mastercard issue mandatory technical mandates on rolling deadlines — 3DS 2.x adoption, EMV liability shift compliance, network token requirements, and recurring indicator mandates. Missing a deadline can trigger liability shifts that expose merchants to disputes they would otherwise win, or attract fines passed through by acquirers.
4. Operating with no network failover. Card networks occasionally experience partial outages that affect specific routing paths or geographies. A payment stack that sends all traffic through a single network with no fallback strategy will experience unnecessary revenue loss during these events. Even a simple alerting threshold on network-level error rates — triggering manual rerouting — is better than no plan at all.
5. Applying a uniform surcharge across all networks. Surcharging regulations differ by network: Visa and Mastercard enforce separate surcharge caps and disclosure rules, and some regional networks prohibit surcharging entirely. Applying a blanket surcharge without verifying the rules per network and per geography risks violating the scheme's merchant agreement, potentially resulting in fines or suspension of acceptance rights.
Card Network and Tagada
Tagada is a payment orchestration platform, which means it operates directly above the card network layer and makes network selection a first-class routing concern. Every decision Tagada makes — which acquirer to engage, which network rail to prefer, when to retry on an alternate path — is driven by real-time network performance signals and configurable routing rules.
With Tagada's smart routing engine, merchants can define least-cost routing policies per card network, BIN range, transaction type, and geography — reducing combined scheme and interchange costs without any manual acquirer negotiation. Network failover is automatic: if one rail returns elevated error rates, Tagada reroutes in-flight transactions to the next eligible path within milliseconds, protecting authorization rates during partial outages.
For developers integrating with Tagada, the platform normalizes network-specific response codes into a unified decline taxonomy, so retry logic and customer-facing messaging do not need to be rebuilt for each network individually. Network tokenization via Visa Token Service and Mastercard Digital Enablement Service is managed at the platform level, removing token lifecycle complexity — provisioning, updates on card reissue, and cryptogram generation — from the merchant's scope entirely.