Card Payment Networks

Visual overview

Card Payment Networks at a glance — Visa, Mastercard, authorization flows, chargebacks.

Visa, Mastercard, and the Infrastructure Behind Every Swipe

Card payment networks constitute one of the most visible and pervasive components of modern financial infrastructure, connecting cardholders, merchants, issuers, acquirers, processors, and network operators across markets around the world. Every card tap or swipe that occurs in mere seconds represents the culmination of extraordinarily complex technological, operational, and commercial arrangements connecting millions of merchants with billions of cardholders through thousands of financial institutions. Understanding how these networks function, how they generate revenue, how they manage risk, and how they continue evolving provides essential context for banking professionals whose institutions participate in card issuing, merchant acquiring, or both sides of this massive payment ecosystem.

The four-party model represents the foundational architecture of major card networks, establishing distinct roles and economic relationships among participants. The cardholder initiates transactions by presenting their card for payment at merchant locations or online. The merchant agrees to accept card payments and maintains a relationship with an acquirer to process these transactions. The issuer, typically the cardholder's bank, provides the card to the customer, extends credit in the case of credit cards, maintains the underlying demand deposit account in the case of debit cards, and bears the credit risk of cardholder default or fraud. The acquirer, typically the merchant's bank, maintains the relationship with merchants, processes their card transactions, and ensures settlement of funds to merchant accounts. The card network itself, such as Visa or Mastercard, operates the technical infrastructure that routes authorization messages between acquirers and issuers, sets the rules governing participation, and facilitates the clearing and settlement of transactions. While the model is termed four-party, the network itself constitutes a fifth essential participant that enables the entire ecosystem to function.

The global card network landscape features distinct players with different market positions and strategic approaches. Visa maintains its position as the largest global network by transaction volume and market capitalization, with its brand accepted at tens of millions of merchant locations worldwide. Mastercard operates as the second major global network with similar acceptance reach and product offerings, with competition between the two driving innovation and pricing pressure. UnionPay dominates the Chinese domestic market and has expanded internationally, particularly in Asian markets and among merchants serving Chinese tourists and businesses, surpassing Visa and Mastercard in raw transaction count though not in value. American Express operates a differentiated three-party model where it serves as both issuer and acquirer for many transactions, allowing greater control over the customer experience but limiting merchant acceptance due to higher fees, positioning it primarily in premium customer segments. RuPay represents India's domestic card network, developed to ensure domestic transaction processing and reduce dependence on foreign networks for domestic payments. JCB dominates the Japanese market with growing international presence, particularly in Asian tourism corridors. Diners Club, historically significant as an early charge card pioneer, now operates as a niche product primarily through corporate travel programs.

The authorization process that occurs when a cardholder presents their card for payment demonstrates the remarkable speed and complexity of modern payment systems. When a cardholder taps their card at a merchant terminal, the point-of-sale device reads the card data from the chip or magnetic stripe and initiates an authorization request that travels to the acquirer processor. The acquirer forwards this request through the card network to the issuing bank. The issuer's systems perform multiple validation checks in real time: verifying the card's validity and status, confirming available credit or funds sufficient for the transaction, assessing fraud risk using sophisticated algorithms and machine learning models, and validating any authentication requirements such as PIN entry or one-time passwords. Upon satisfactory validation, the issuer generates an approval code and transmits it back through the same chain to the merchant terminal. This entire sequence typically completes in under three seconds, despite potentially traversing multiple countries and systems, demonstrating the extraordinary engineering that underlies seemingly simple everyday transactions.

The economics of card payments involve multiple fee flows that ultimately derive from the merchant discount rate paid by merchants for the privilege of accepting card payments. The merchant service charge or merchant discount rate varies significantly by market, merchant category, card product, acceptance channel, transaction type, regulation, scheme pricing, acquirer economics, and merchant negotiation power; there is no single global percentage range that accurately describes every card transaction. This merchant payment splits among network participants according to established formulas. Interchange is generally a transfer from the acquiring side to the issuing side under the applicable scheme rules, but the level and economic purpose vary by market and product. In some jurisdictions it is capped by regulation; in others scheme schedules and commercial arrangements play a larger role. It should therefore be analysed separately from scheme fees, processor fees, acquirer margin, taxes, and other merchant-service components. Network and processing fees fund the infrastructure, rules, security, acceptance, and services provided by the scheme and processors. The acquirer or payment-service-provider margin covers merchant onboarding, servicing, processing, fraud and chargeback operations, risk, and other costs. These components vary materially by geography, product, volume, and commercial agreement, so fixed global basis-point assumptions should not be treated as universal facts. This fee structure explains why issuers aggressively compete for cardholder relationships despite substantial marketing and reward costs: the interchange revenue generated by card spending creates a profitable business even after accounting for credit losses and operating expenses.

Interchange fee regulation has become a significant policy issue as merchants and regulators have challenged the level of these fees across major markets. The United States maintains relatively high interchange rates, particularly for premium credit cards, with debit interchange capped by post-financial crisis legislation at substantially lower levels than credit. The European Union imposed aggressive interchange caps of twenty basis points for debit and thirty basis points for credit, dramatically reducing merchant costs but also compressing issuer revenue and potentially reducing card reward generosity. India's domestic card and UPI ecosystems have distinct pricing and policy arrangements that have changed over time. RuPay, card-on-UPI use cases, debit, credit, prepaid, and merchant categories should therefore be assessed against the current NPCI, RBI, government, and scheme rules rather than one timeless interchange assumption. Australia has regulated interchange downward over multiple review cycles, seeking to balance payment system efficiency with ensuring continued card network investment. These regulatory differences create significant variations in card economics across markets and influence strategic decisions about product positioning and geographic focus.

Chargebacks represent the dispute resolution mechanism through which cardholders can contest transactions they believe to be unauthorized, fraudulent, or involving merchant misconduct. When a cardholder disputes a transaction, the issuer follows the applicable legal, scheme, and product process. Whether provisional credit is provided, when it is provided, and which evidence is required depend on the jurisdiction, transaction type, scheme rules, and issuer policy. The issuer then initiates a chargeback through the card network to the acquirer, who debits the merchant's account for the disputed amount plus associated fees. The merchant may contest the chargeback by providing evidence that the transaction was legitimate, a process called representment, triggering a review that may result in the chargeback being reversed if the merchant prevails or confirmed if the issuer's original decision stands. Excessive dispute or fraud ratios can trigger scheme monitoring, higher costs, reserves, remediation requirements, restrictions, or termination depending on the applicable programme and circumstances. Merchant risk teams should therefore monitor chargeback and fraud performance against the current scheme thresholds rather than rely on one universal percentage. The chargeback system shifts significant liability risk from cardholders to merchants and issuers, creating the consumer trust that underlies card payment adoption.

Card security has evolved through multiple technological layers designed to prevent fraud while maintaining transaction convenience. EMV chip technology, named for Europay, Mastercard, and Visa who developed the standard, replaces the static data stored on magnetic stripes with dynamic authentication codes generated uniquely for each transaction, effectively eliminating counterfeit card fraud at physical terminals. Contactless payment using near-field communication enables tap-to-pay transactions that combine convenience with security through tokenization and transaction limits. Card verification values, the three-digit codes on card backs, provide verification for card-not-present transactions that cannot use chip authentication. EMV 3-D Secure supports risk-based card-not-present authentication and can enable frictionless or challenge flows depending on the transaction and issuer decision. EMVCo maintains multiple specification versions and updates; practitioners should use the currently supported EMV 3DS version and scheme implementation requirements rather than treating the label '3-D Secure 2.0' as a timeless current version. Tokenization replaces actual card numbers with device-specific tokens in mobile wallet implementations, ensuring that compromised tokens cannot be used on other devices or for other transactions. Artificial intelligence fraud scoring analyzes transaction patterns in real time to identify anomalous behavior requiring additional verification or blocking. Geo-blocking prevents transactions from unexpected locations that may indicate compromised cards being used far from cardholder locations.

Card-not-present fraud is a major and persistent security challenge as e-commerce and remote commerce grow. EMV chip technology materially reduces the usefulness of copied static magnetic-stripe data for counterfeit transactions at properly configured chip terminals, while remote channels require different controls such as EMV 3-D Secure, tokenisation, merchant risk controls, device and behavioural analytics, issuer fraud scoring, and strong customer authentication where required. The relative share of fraud by channel changes by country, period, and measurement methodology, so global percentage claims should be sourced to a defined reporting period rather than treated as permanent facts.

Emerging trends continue reshaping card payment networks as technology evolves and consumer preferences shift. Tap-to-phone technology enables merchants to accept contactless card payments using only their smartphones, eliminating the need for dedicated point-of-sale terminals and democratizing card acceptance for micro-merchants and mobile businesses. Click-to-pay standards aim to streamline online checkout by eliminating the need for cardholders to enter card details on merchant websites, reducing friction and improving conversion rates. Card-as-a-Service platforms enable fintech companies and non-financial brands to issue virtual and physical cards through banking partnerships, expanding card issuance beyond traditional financial institutions. Cryptocurrency cards bridge digital assets to traditional payment rails by allowing consumers to spend crypto holdings through standard Visa or Mastercard acceptance networks. Real-time settlement initiatives seek to reduce the traditional delay between transaction authorization and final settlement, improving liquidity management for merchants and potentially reducing systemic risk in payment systems.

Card Economics Should Be Read as a Flow of Responsibilities

The economics of a card transaction are easier to understand when the fee components are tied to responsibilities rather than memorised as percentages. The merchant pays its acquirer or payment service provider under a commercial agreement. The acquiring side bears merchant onboarding, settlement, dispute, fraud, and servicing costs. The network charges for access to its rules, routing, clearing, security, and related services. Interchange transfers value between the acquiring and issuing sides according to the applicable scheme and regulatory framework. The issuer funds authorization infrastructure, card servicing, fraud protection, rewards where offered, dispute operations, and, for credit cards, lending capital and credit risk.

This means a change in interchange regulation can affect issuer economics without changing the network fee. A merchant acquiring price can fall because a large merchant negotiates a lower acquirer margin even if underlying interchange is unchanged. A high-risk merchant may pay more because the acquirer needs reserves, monitoring, or delayed funding even when the card product is identical. Card economics should therefore be modelled by component, market, product, channel, and merchant segment.

Merchant Reserves Protect Against Future Claims

An acquirer can pay a merchant today and receive chargebacks or refunds weeks or months later. Where future-delivery risk or merchant financial weakness is material, the acquirer may retain a reserve or delay part of settlement under the merchant agreement.

A travel business is a clear example. Customers may pay months before the service is delivered. If the merchant fails before travel occurs, the acquiring side can face a wave of disputes after the merchant has already received the original proceeds. A rolling reserve, delayed settlement, guarantee, or other risk mitigant can reduce this exposure.

Reserves should be governed transparently. The acquirer needs defined triggers, calculation, release conditions, merchant communication, and accounting. Holding excessive funds without contractual or risk justification creates conduct and commercial risk; holding too little can create a loss when the merchant fails.

Partial Capture, Incremental Authorization, and Tips Need State Discipline

Card transactions do not always move from one authorization to one identical clearing item. A hotel can authorize an estimated stay amount and later increase it as charges accrue. A restaurant can authorize the meal and later include a tip according to local rules. An e-commerce merchant can authorize an order and capture individual shipments separately.

Systems therefore need to link several related events to the same commercial purchase while protecting against over-capture. The issuer must know how much remains reserved, what has already been posted, and whether an incremental request is permitted. The acquirer must ensure the merchant does not capture more than authorised except where network rules specifically allow an adjustment.

Poor state management creates customer pain: duplicate holds, available balance remaining blocked after final posting, or a purchase appearing twice. These are not cosmetic defects; they are money-integrity defects.

Network Tokens Have Their Own Lifecycle

A payment token can be created, activated, suspended, resumed, replaced, or deleted independently of the physical card. If a customer loses a phone, the issuer may suspend the device token while leaving the underlying plastic card active. If the underlying card is replaced because of expiry, token services may update the relationship according to scheme and wallet arrangements.

The bank should therefore store the relationship among account, PAN, token, device, wallet, and token requestor. Fraud controls can then identify whether an unusual transaction came from a long-established token on a trusted device or a newly provisioned token created shortly before suspicious activity.

Token lifecycle events also need customer-service visibility. Telling a customer only that 'the card is active' is insufficient if the wallet token is suspended or provisioning failed.

Card Replacement Is Not Always Transaction Termination

Customers often assume that replacing a card number stops every recurring transaction. Account updater and token services can, under applicable programme rules, allow participating merchants or wallets to receive updated credential information so legitimate subscriptions continue. This improves convenience but can surprise customers trying to cancel a service.

The correct cancellation path is normally to cancel the merchant agreement or subscription, not to rely solely on card replacement. Issuers should explain this clearly while still providing mechanisms to manage merchant or token relationships where their products support them.

For fraud replacement, the bank should decide which tokens and recurring credentials remain trusted. Automatically carrying every old relationship to a new card can preserve convenience but may also preserve a compromised channel if the fraud source is not understood.

Scheme Monitoring Is a Control Framework, Not One Percentage

Card networks maintain programmes for excessive fraud, disputes, data quality, merchant risk, and other behaviours. Thresholds and remediation can differ by scheme, market, merchant type, and programme version.

An acquiring bank should therefore consume current scheme bulletins and monitoring rules into its risk platform. The bank needs early-warning thresholds below formal programme limits so it can contact merchants before the scheme imposes additional obligations. Merchant remediation can include stronger authentication, improved billing descriptors, customer-service changes, fraud rules, restricted products, or termination.

The issuer side also needs network compliance. Excessive authorization errors, poor dispute quality, inaccurate data, or missed operational deadlines can create fees and customer harm even when fraud losses are low.

Card Incidents Require Issuer and Acquirer Views

Imagine a processor defect causes some merchants to submit the same clearing file twice. The network receives two presentments for transactions that were legitimately authorized only once.

On the issuer side, customers can see duplicate posted debits and immediately complain. The issuer must identify the pattern, protect customers, and decide whether to reverse provisionally according to the applicable process. On the acquiring side, merchants may receive duplicate funding unless the processor or acquirer stops it. Settlement positions can become overstated, and reconciliation breaks appear across both sides.

The incident team needs network data, processor file identifiers, merchant batches, authorization references, clearing records, settlement totals, and customer postings. Simply turning off the processor can stop new damage but does not repair transactions already duplicated. Recovery requires controlled reversal or correction events that preserve the original financial history.

Card Profitability Should Include Risk and Capital

A card portfolio can generate substantial gross revenue and still be unattractive after rewards, fraud, credit loss, servicing, acquisition expense, processor fees, dispute cost, and capital. Credit-card economics should therefore be viewed over the customer lifecycle rather than by interchange alone.

A rewards product with high spend can look excellent until the reward cost and low revolving balances are included. A high-interest portfolio can look profitable until delinquency and charge-offs rise. A debit portfolio can generate lower direct revenue but provide valuable deposit relationships and payment engagement.

Funds transfer pricing, credit-loss estimates, customer acquisition cost, lifetime value, and operational cost should all be part of product decisions.

Issuer and acquirer operating responsibilities

For banking institutions, card network participation creates both significant opportunities and substantial responsibilities. Issuing banks generate revenue through interchange, interest on revolving balances, and various card fees, while investing heavily in customer acquisition through marketing, rewards programs, and product innovation. They must manage credit risk through sophisticated underwriting and portfolio monitoring, fraud risk through real-time detection systems and customer dispute handling, and operational risk through robust processing capabilities. Acquiring banks build merchant relationships through sales forces and service capabilities, managing the complexity of merchant onboarding, transaction processing, and risk monitoring. Both issuing and acquiring require substantial technology investment, regulatory compliance, and operational expertise that differentiates large-scale participants from smaller competitors. As card payments continue growing globally while facing disruption from alternative payment methods, banks must continuously adapt their strategies to maintain competitiveness in this dynamic sector.

Operating Metrics That Reveal Whether the Card Business Is Healthy

A card operation should not be managed only by total purchase volume. Issuers need approval rates, fraud losses, false-decline rates, authorization latency, token-provisioning success, active-card ratios, utilization, delinquency, dispute ageing, reversal performance, and customer complaints. Acquirers need merchant activation, authorization success, settlement timeliness, fraud and dispute behaviour, refund patterns, reserve exposure, funding breaks, and merchant attrition. Both sides need reconciliation breaks, processor availability, network incidents, scheme compliance, and financial-control metrics.

The metrics interact. Raising fraud rules can reduce fraud loss while increasing false declines and customer abandonment. Relaxing issuer controls can improve approval rates while increasing loss. Funding merchants faster can improve merchant experience while increasing acquirer exposure to future chargebacks. The correct objective is therefore not to maximize one metric but to manage the economic and customer trade-offs deliberately.

A world-class card organisation also segments metrics by country, product, merchant category, token or PAN, card-present versus card-not-present, authentication method, processor, and fraud type. A healthy portfolio average can hide a serious problem in one e-commerce merchant segment or one newly launched wallet. Early segmentation lets the bank intervene before the issue becomes a scheme programme, financial loss, or customer-service crisis.

Operational reporting should also connect the stages of the transaction. A fall in approval rate can come from issuer fraud rules, processor latency, network outages, bad merchant data, or exhausted customer funds. A rise in disputes can originate in fraud, unclear merchant descriptors, delayed refunds, subscription practices, or product confusion. The useful metric is therefore not only the number but the root cause and the team that can change it. When card operations, product, fraud, credit, finance, and technology share this causal view, they can improve customer experience without weakening financial control.

Deep Dive: A Card Transaction Is Three Different Financial Events

The most useful way to understand card payments is to separate authorization, clearing, and settlement. A cardholder may see one purchase, but the issuer, acquirer, merchant, and network process several related events over time. Authorization decides whether the issuer is willing to support the transaction at that moment. Clearing presents the final transaction details and calculates the obligations between participants. Settlement moves the resulting interbank value. Confusing these stages explains many common card problems: a transaction can be authorized but never cleared, cleared for a different amount, reversed after authorization, or disputed long after settlement.

This separation also explains why the balance shown to a customer can behave unexpectedly. A hotel can place an authorization hold for an estimated amount, then later clear the actual bill. A fuel station can request a preauthorization before the final purchase amount is known. An e-commerce merchant can obtain authorization today and capture later. The issuer therefore needs both posted transactions and pending authorizations in its account or credit-limit logic.

Authorization is a real-time risk decision

When an authorization request reaches the issuer, the issuer is deciding whether to approve a proposed use of the card credential. The decision can consider:

• card status and expiry;
• available credit or account funds;
• transaction amount and currency;
• merchant and merchant category;
• card-present or card-not-present channel;
• chip, contactless, PIN, CVV, token, or 3DS data;
• recent transaction velocity;
• device or wallet information where available;
• fraud score;
• country and geographic behaviour;
• account restrictions and customer controls.

The decision normally needs to happen in seconds. This makes card authorization one of banking’s clearest examples of automated decisioning at scale.

An approval code does not mean the issuer has already transferred money to the merchant. It means the issuer has approved the transaction subject to subsequent clearing and scheme rules. The issuer can place a hold against the cardholder’s balance or credit line so the same spending capacity is not reused.

Available balance and posted balance are different for cards

Suppose a debit-card customer has ₹20,000. A merchant obtains a ₹5,000 authorization. The customer may still have a booked balance of ₹20,000 but only ₹15,000 available.

If the merchant later clears ₹4,800, the issuer posts the ₹4,800 transaction and releases the remaining ₹200 authorization amount. If the merchant never submits the transaction, the authorization can expire or be reversed according to the applicable rules and issuer process.

This is why customers sometimes complain that money is “blocked” even though the merchant says the transaction failed. The final purchase may indeed have failed while the authorization hold remains until the issuer receives a reversal or the hold expires.

A good issuer can explain the difference clearly and release invalid holds as quickly as scheme and risk rules allow.

Reversals are essential to customer experience

If an authorization was approved but the merchant cannot complete the transaction, a reversal can tell the issuer to release the reserved amount.

This is common at ATMs, petrol stations, e-commerce checkouts, and POS terminals when communication or merchant processing fails after authorization.

The operational challenge is message uncertainty. A terminal may not know whether the issuer received the original authorization response. The merchant or acquirer must avoid creating a duplicate while also ensuring stale holds are removed.

Issuers should reconcile authorization, reversal, and clearing events by stable transaction identifiers and matching logic. A reversal should not accidentally release a hold for a different legitimate transaction.

Stand-in processing protects availability but changes risk

Card networks or processors can provide stand-in authorization under defined arrangements when the issuer is temporarily unavailable. Instead of every transaction failing during an issuer outage, the network applies agreed limits and rules to approve or decline some transactions on the issuer’s behalf.

This improves customer availability but transfers control. The issuer should define appropriate stand-in parameters and monitor what was approved while its own systems were unavailable.

When connectivity returns, stand-in transactions need to flow into the issuer’s risk and account systems. A poorly governed stand-in limit can create unexpected credit or fraud exposure during an outage.

The design question is therefore not simply “Do we support stand-in?” but which transaction types, values, and risk conditions can safely be approved without the issuer’s live decision engine?

Clearing determines what the merchant is actually claiming

The authorization request is often an estimate or reservation. Clearing is the financial presentment that tells the system what the merchant is claiming for settlement.

The clearing record contains transaction data required by the scheme and participants. It can include final amount, currency, merchant information, transaction date, interchange-related data, fees, and references linking back to the authorization.

The issuer validates the presentment, posts the cardholder transaction according to product rules, and includes the item in reconciliation and settlement accounting.

A mismatch between authorization and clearing is not automatically wrong. Hotels, car rentals, tips, incremental authorizations, and partial shipments can legitimately change the amount under applicable rules. The issuer must understand the transaction context and scheme rules before deciding whether a variance is acceptable.

Settlement is usually based on net obligations

Card schemes process enormous transaction volumes. Rather than move interbank money separately for every purchase, clearing calculates obligations across participating issuers and acquirers and produces settlement positions under the network’s model.

An issuer owes value for purchases made by its cardholders. An acquirer is owed value for transactions accepted by its merchants, adjusted for refunds, chargebacks, fees, and other clearing events. The scheme or settlement arrangement calculates the amounts and settlement occurs through designated banking relationships.

This is why authorization success does not prove merchant funding. The merchant normally receives money after the acquiring side processes the cleared transaction and applies its own funding schedule, reserves, fees, or risk holds.

Merchant funding is not identical to network settlement

An acquirer or payment service provider may fund a merchant according to a contract such as same day, next day, or another schedule. The network settlement timing can be different.

The acquirer therefore manages a funding position between what it pays merchants and what it receives through card settlement. It may also hold reserves for high-risk merchants, delay suspicious transactions, or deduct fees and chargebacks.

Merchant complaints about “settlement” often refer to merchant payout rather than card-network interbank settlement. Operations and customer service need to distinguish the two.

The acquirer is underwriting the merchant as well as processing payments

Merchant acquiring creates financial risk because the acquirer can become responsible for cardholder claims even after it has already paid the merchant.

Suppose a travel merchant sells future holidays, receives card payments, and then becomes insolvent before providing the service. Cardholders may dispute the transactions. If the acquirer has already funded the merchant, it can face significant exposure.

Merchant onboarding therefore includes more than KYC. Acquirers assess business model, expected volume, average ticket, delivery timeframe, refund policy, chargeback history, financial strength, website and product, ownership, fraud risk, and prohibited or high-risk activity.

High-risk merchants may require rolling reserves, delayed settlement, lower limits, or enhanced monitoring.

Merchant category codes affect more than reporting

Merchant category codes classify the type of business. They can influence interchange treatment, cardholder rewards, regulatory treatment, fraud models, issuer controls, scheme programmes, and whether certain card products can be used.

Incorrect MCC assignment can therefore create pricing, compliance, and risk problems.

An acquirer should assign the code based on the merchant’s actual primary business rather than whichever code creates the cheapest economics. Scheme audits and monitoring can identify misclassification.

Card credentials are not the same as the underlying account

A card number or token is a credential that allows a payment request to be associated with an account relationship. The underlying account may be a credit-card account, debit account, prepaid balance, commercial-card account, or another permitted product.

This distinction matters when cards are replaced. A physical card can expire or be reissued while the underlying account remains open. Recurring merchants or wallets may receive updated credentials through scheme services, depending on the arrangement.

Systems should therefore separate customer, account, card, credential, device token, and wallet relationships rather than treating the PAN as the customer’s permanent identity.

Tokenisation reduces exposure of the primary credential

Payment tokenisation can replace a primary account number with a token used in a defined domain such as a specific device, wallet, merchant, or use case.

If the token is compromised, its usefulness can be restricted compared with exposing the original PAN. Token lifecycle controls can suspend or delete a token without necessarily replacing the underlying card.

Mobile wallets commonly use device-related payment tokens, but tokenisation also supports card-on-file and e-commerce use cases.

Risk systems need to understand token context. A token transaction may carry different device, cryptographic, or assurance data from a PAN-based transaction. Fraud models should use that information rather than flatten every credential back to the same old card number before decisioning.

Contactless payment is still an EMV card transaction

Contactless card payments use near-field communication to exchange payment data between the card or device and terminal. The underlying transaction still follows scheme authorization, clearing, and settlement rules.

Contactless does not mean “no security”. EMV contactless transactions use cryptographic data and transaction rules. Authentication can vary by amount, market, card product, device, and local regulation.

Mobile-wallet contactless transactions can add device authentication and tokenisation. The risk model is therefore different from simply reading a static magnetic stripe.

Magnetic stripe fallback deserves careful control

Chip cards can sometimes fall back to magnetic-stripe processing when chip reading fails and the scheme or issuer permits it. Fraudsters can try to exploit fallback because magnetic-stripe data is easier to copy than chip transaction data.

Issuers therefore monitor fallback rates, geography, merchant, terminal capability, and card history. Repeated fallback on a chip-capable card can be suspicious.

Acquirers also need to monitor terminals that generate unusually high fallback traffic because the problem may be configuration, hardware failure, or fraud.

Card-not-present transactions require a different trust model

In e-commerce, the merchant cannot insert or tap the physical card. The system relies on data and authentication to establish confidence.

Controls can include CVV, address or identity signals where available, merchant fraud screening, device information, behavioural analytics, velocity, tokenisation, and EMV 3-D Secure.

The absence of a physical chip does not mean every online transaction should receive an OTP. Modern authentication aims to use risk information so low-risk transactions can proceed with less friction while higher-risk transactions receive a challenge.

The exact liability and authentication consequences depend on regulation, scheme rules, transaction type, and implementation.

EMV 3-D Secure is an authentication protocol family

EMV 3DS enables merchants, issuers, payment-system components, and access-control systems to exchange information for cardholder authentication in remote commerce.

The protocol supports frictionless outcomes where the issuer can make a confident risk decision from available data and challenge outcomes where additional cardholder interaction is required.

Practitioners should avoid calling every modern implementation “3-D Secure 2.0”. EMVCo maintains formal specification versions and bulletins; institutions need to follow the versions and scheme mandates currently applicable to their market and integration.

The business requirement should focus on authentication result, data quality, exemption or regulatory treatment where relevant, challenge experience, liability implications, and failure handling rather than one marketing version label.

Wallet provisioning is a high-risk identity event

Adding a card to a digital wallet creates a new payment credential. Fraudsters therefore target provisioning.

The issuer should evaluate whether the person adding the card is genuinely the cardholder. Controls can include account login, device history, OTP, app confirmation, risk scoring, customer contact, and other verification depending on the wallet and issuer model.

A criminal who successfully provisions a stolen card into their own wallet can then make tokenised transactions that appear technologically strong. Tokenisation protects the credential, but it does not fix weak identity verification at provisioning.

This demonstrates a broader payments lesson: a secure transaction can still be fraudulent if the wrong person was granted the credential.

Credential-on-file and recurring payments need lifecycle controls

Merchants can store card credentials or tokens for future transactions under applicable rules. Recurring subscriptions, utility payments, ride-hailing, and e-commerce accounts depend heavily on this model.

The system should distinguish a customer-initiated transaction from a subsequent merchant-initiated transaction where the cardholder is not actively present. The original customer agreement, credential storage, mandate or consent, transaction indicators, and cancellation handling matter.

Card replacement creates complexity because a recurring service may continue through account-updater or token services. A customer may believe replacing the physical card stops a subscription when the merchant legitimately receives updated credentials under the service arrangement.

Customer communication and merchant cancellation controls therefore matter as much as card reissuance.

Credit cards combine payment risk with lending risk

A credit-card issuer makes two decisions that should not be confused.

The authorization system decides whether to approve each transaction. The credit-risk function decides how much revolving exposure to offer the customer and whether the customer can repay over time.

A transaction can be genuine and authorized but still contribute to future credit loss if the customer cannot repay. Fraud losses and credit losses are different risk categories even though both affect the card portfolio.

Credit-card portfolio management therefore includes underwriting, limit assignment, utilization, minimum payment behaviour, delinquency, collections, interest, fees, rewards, and expected credit loss alongside payment operations.

Debit cards create immediate deposit-account implications

A debit-card authorization usually checks funds in or access to a deposit account. Holds therefore affect the customer’s available balance immediately.

Offline or delayed clearing can create overdraft or insufficient-funds scenarios if the customer spends funds elsewhere before the final item posts, depending on product and authorization design.

Issuer systems need clear rules for holds, partial reversals, preauthorizations, tips, foreign-currency adjustments, and delayed presentment so customer balances remain understandable and accurate.

Foreign-currency card purchases contain an FX lifecycle

When a cardholder buys in a different currency from the card account, the final account amount depends on scheme conversion, issuer pricing, transaction timing, and product terms.

Authorization can be performed using an indicative converted amount while clearing occurs later at the applicable conversion basis. The final posted amount can therefore differ from the pending amount even when the merchant did not change the purchase price.

Customer-service teams should distinguish merchant amount, transaction currency, settlement currency, card-account currency, scheme FX rate, issuer margin, and any fee.

Dynamic currency conversion changes who performs the conversion

A merchant or ATM can sometimes offer to convert the transaction into the cardholder’s home currency at the point of interaction. This is dynamic currency conversion.

The customer should receive clear information about the offered rate and charges under applicable rules. If the cardholder accepts DCC, the merchant-side provider performs the conversion rather than leaving conversion to the card scheme and issuer in the usual way.

DCC should not be silently selected because it changes the economics of the transaction.

Disputes begin with classification

A cardholder saying “I don’t recognise this” can mean several things. The transaction may be true third-party fraud, a forgotten merchant, an unclear billing descriptor, a family member’s purchase, a duplicate, an incorrect amount, a subscription, or a merchant-service dispute.

Correct classification matters because each path has different evidence and scheme rules.

Issuer staff should not automatically label every complaint fraud. Doing so can unnecessarily block cards, damage merchants, and send the case into the wrong process.

Chargebacks are structured scheme processes

A chargeback is not simply the issuer “taking money back”. It is a dispute process governed by card-network rules, reason codes, timeframes, evidence requirements, and rights for issuers, acquirers, and merchants.

The merchant may respond with evidence in a representment process. Further stages can exist depending on the network and case. Financial liability can shift as evidence is evaluated.

Operations systems therefore need case status, deadlines, document storage, reason codes, financial postings, merchant communication, cardholder communication, and audit history.

Missing a scheme deadline can create financial loss even if the bank’s substantive position was strong.

Refund and chargeback are different

A merchant refund is a new merchant-initiated financial transaction returning value to the cardholder. A chargeback is a dispute mechanism initiated through the issuer and scheme process.

Customers sometimes initiate a chargeback while a merchant refund is already in flight. If both post, the cardholder could receive duplicate value unless the case is reconciled correctly.

Dispute teams should therefore check refund and clearing data before finalising the financial outcome.

Friendly fraud and first-party misuse complicate disputes

Some disputes involve a genuine cardholder denying a transaction they or someone they authorised actually made. This is sometimes described as first-party misuse or friendly fraud.

Merchants can provide evidence such as account login, delivery, device, service usage, customer communication, or prior transaction history according to the applicable dispute rules.

Issuers need to protect genuine fraud victims without treating every cardholder assertion as automatically conclusive when contrary evidence exists.

Merchant monitoring should be behavioural

Acquirers monitor merchants for sudden volume changes, fraud, dispute ratios, unusual ticket size, cross-border activity, prohibited goods, transaction laundering, excessive refunds, split transactions, and other risk signals.

A merchant approved as a small clothing retailer should not suddenly process large volumes of online gaming transactions without review.

Merchant monitoring is therefore the acquiring equivalent of customer transaction monitoring in banking. Onboarding tells the acquirer what business it expects; ongoing monitoring tests whether reality still matches that profile.

Transaction laundering hides the real merchant

A prohibited or high-risk business can attempt to process payments through another merchant account. The card network and acquirer may see a low-risk merchant name while the actual goods or services come from a different business.

Detection requires website review, transaction data, merchant relationships, customer complaints, device or domain data, and monitoring of business-model change.

KYC alone cannot solve this because the merchant may have been legitimate at onboarding and changed later.

BIN and issuer identification data are routing controls

Card credentials include information used by networks and processors to identify the issuer range and route transactions. BIN-range management therefore affects authorization routing, product identification, token services, fraud rules, and reporting.

Changes must be coordinated across issuers, processors, networks, token providers, and internal systems. Hard-coded assumptions about fixed BIN length or product meaning create migration problems as card-numbering practices evolve.

Reference data should be consumed from authoritative sources and updated through controlled processes.

Card processing architecture is highly distributed

An issuer may use separate providers for authorization, card management, fraud, 3DS access control, tokenisation, dispute processing, statement generation, and core accounting. An acquirer may use gateways, processors, terminal managers, fraud providers, merchant platforms, and settlement systems.

This creates third-party dependency risk. A card programme can fail even if the bank’s own core systems are healthy because a processor, network connection, token service, or authentication provider is unavailable.

Contracts need service levels, incident escalation, security obligations, change control, audit rights, capacity management, and exit planning. Outsourcing technology does not outsource regulatory or customer accountability.

Reconciliation must connect authorization, clearing, settlement, and customer books

Authorization logs explain what was approved. Clearing files explain what was presented. Settlement reports explain the interbank financial position. Customer and merchant ledgers explain what was posted.

These records should reconcile.

A cleared transaction with no prior authorization can be legitimate in some transaction types but deserves appropriate handling. An authorization with no clearing item should eventually expire or reverse. A settlement amount should equal the applicable cleared obligations adjusted for fees and other network items.

Card operations therefore needs several reconciliations, not one daily total.

General-ledger accounting needs event-level clarity

Card transactions can create postings for cardholder receivables, deposit debits, merchant settlement, interchange, scheme fees, FX, rewards, chargebacks, refunds, interest, and credit losses.

If the accounting model is not aligned with the transaction lifecycle, suspense balances accumulate.

A chargeback, for example, can create a provisional customer credit before final liability is resolved. Finance needs to know whether the amount is recoverable from the acquirer or merchant, whether a provision is needed, and when the case becomes final.

Testing should include financial failure paths

A high-quality card test pack should cover much more than approval and decline.

It should test timeout after authorization, duplicate presentment, reversal, partial reversal, clearing without matching authorization, incremental authorization, refund, foreign currency, token transaction, wallet provisioning, 3DS frictionless and challenge outcomes, card lost or stolen, expired card, offline or fallback conditions where supported, chargeback, representment, merchant settlement hold, and processor outage.

For every scenario, testers should verify the cardholder balance or credit line, merchant position, issuer/acquirer accounting, settlement report, fees, fraud state, and case history.

A complete card purchase scenario

A customer taps a tokenised debit card in a mobile wallet for a restaurant purchase. The terminal sends the transaction to the acquirer. The network routes it to the issuer. The issuer validates the token and transaction data, checks available funds and fraud score, and approves ₹2,000.

The issuer places a ₹2,000 hold on the customer’s account. The restaurant later adds an allowed tip and submits the final transaction for ₹2,200 under the relevant acceptance rules. The clearing record reaches the issuer and is matched to the authorization. The issuer posts ₹2,200 to the customer and releases the original hold appropriately.

The network clearing process calculates obligations between issuer and acquirer. Settlement occurs through the network’s settlement arrangements. The acquirer funds the merchant under the merchant agreement, net of applicable fees.

Weeks later, if the customer disputes the charge, the issuer opens a case. The original authorization, token information, clearing record, merchant descriptor, receipt evidence, and scheme timelines become part of the investigation. The old transaction is not deleted; the dispute creates a new financial and operational lifecycle around it.

What excellence looks like

A world-class card operation understands cards as linked but distinct authorization, clearing, settlement, dispute, and credit processes. It preserves the relationship between credential, token, account, customer, merchant, and device. It controls merchant onboarding and ongoing activity, protects wallet provisioning, uses current EMV and 3DS specifications rather than outdated shorthand, and reconciles every stage back to customer and merchant books.

The deepest insight is that the card network does more than route a purchase. It provides a rules framework for trust among parties that usually have no direct relationship with one another. The cardholder trusts the issuer, the merchant trusts the acquirer, the issuer and acquirer rely on the network, and the network rules define how authorization, fraud, clearing, settlement, disputes, and financial responsibility fit together.