US Card Ecosystem: Issuers, Acquirers, Networks and Merchants. A practitioner foundation for the US card ecosystem across cardholders, issuers, merchants, acquirers, Visa and Mastercard four-party networks, American Express and Discover models, debit routing, processors, payment facilitators, PCI responsibilities, identifiers, economics, reconciliation and bank operations.
A card payment looks simple from the customer side. A person taps a card, inserts a chip, enters card details online, or uses a phone wallet. A few seconds later the screen says approved or declined. Behind that small interaction sits one of the most interconnected operating ecosystems in banking: cardholders, merchants, issuers, acquirers, card networks, debit networks, processors, gateways, payment facilitators, independent sales organizations, token services, fraud platforms, terminal providers, settlement banks, sponsor banks, service providers, and multiple legal and contractual relationships.
That ecosystem is the subject of Chapter 27.
Chapter 27 is deliberately a participant-and-operating-model foundation. Chapter 28 will go deeply into the authorization lifecycle. Chapter 29 will go deeply into clearing, interchange, settlement and merchant funding. Chapter 30 will separate credit, debit, prepaid, EBT and closed-loop value. Branch 7 will then go further into POS, e-commerce, stored credentials, disputes, refunds and card fraud. This chapter therefore explains enough transaction flow to show what each participant does, but it does not steal the detailed mechanics from those later chapters.
The central learning principle is simple:
A card transaction is not one relationship and not one system. It is a coordinated chain of commercial, technical, financial and risk relationships in which different parties own different truths.
A merchant owns the sale. An acquirer owns the merchant-acquiring relationship and card-acceptance responsibility under the applicable network model. An issuer owns the cardholder account and authorization decision. A network provides rules, routing and network services between participating institutions. A processor may execute technology on behalf of an issuer or acquirer without becoming the regulated financial institution that owns the underlying customer relationship. A payment facilitator can simplify merchant onboarding but normally sits under an acquiring relationship and does not erase the acquirer’s network accountability. The payment data may move through several systems before money is settled and the merchant is funded.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–2, Sections 4–10 and Sections 12–15. For the next 10 minutes, use the chapter’s three diagrams to identify issuer, acquirer, network and service-provider responsibilities. Use 10 minutes to walk one purchase across the participants in Section 12, then spend the final 5 minutes explaining: Who owns the decision, the merchant relationship and the financial evidence at each stage of a purchase? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- Why the US card ecosystem must be learned as a system
- The core participant map
- Cardholders and the issuer relationship
- Issuers: product, risk, authorization and account ownership
- Merchants and the acceptance relationship
- Acquirers and merchant acquiring
- Visa and Mastercard four-party network model
- American Express, Discover and other network models
- Debit networks and US routing choice
- Processors, gateways, ISOs, payment facilitators and service providers
- Identifiers and reference data that hold the ecosystem together
- How a purchase crosses the ecosystem end to end
- Economics, fees and commercial ownership
- Security, PCI, fraud and compliance responsibility
- Reconciliation, reporting, controls and real-bank operations
- Architecture, testing, role checklist and authoritative references
1. Why the US card ecosystem must be learned as a system
The first mistake people make when learning cards is to think that the card brand is the bank. It usually is not. A Visa or Mastercard logo on a card does not mean Visa or Mastercard issued the customer’s credit or debit account. In the common four-party model, the issuer is the financial institution that has the relationship with the cardholder and issues the card credential, while the acquirer is the institution or acquiring organization that supports the merchant’s acceptance of the card. Visa or Mastercard provides the network, rules, routing and related services that connect the two sides.
The second mistake is to think that the merchant sends the transaction directly to the issuer. In a simple conceptual flow, the merchant passes the transaction into its acceptance stack, which may include a terminal, gateway, processor or payment facilitator. The merchant-side provider forwards it through the acquiring side. The relevant card network routes the authorization request to the issuer or its processor. The issuer makes the approval decision and sends a response back through the network and acquiring path to the merchant.
The third mistake is to treat every company in the path as a bank. Many are technology or payment-service companies. An acquiring processor may perform switching, merchant configuration and clearing-file functions for an acquirer. An issuing processor may maintain card-account processing technology for an issuer. A gateway may securely connect a merchant’s website or app to an acquiring processor. A payment facilitator may onboard sponsored merchants or submerchants and provide a simplified merchant experience. Those parties can be operationally critical without owning the legal issuer or acquirer role for the transaction.
The fourth mistake is to believe that approval equals settlement. It does not. Authorization answers whether the transaction should be approved at that moment. Clearing later communicates the financial transaction information used to calculate obligations. Settlement moves money between participating financial institutions under the network arrangement. Merchant funding is then the acquirer-side process of paying the merchant according to the merchant agreement. These concepts will be unpacked in Chapters 28 and 29; Chapter 27 uses them only to explain participant responsibility.
Finally, there is no single US card model. Visa and Mastercard are commonly described as four-party networks. American Express has historically operated an integrated model and also supports issuer and acquirer partners through its global network. Discover operates Discover Network and PULSE and also participates through issuing, acquiring and network partnerships. Debit cards can be enabled on more than one unaffiliated network, which introduces routing choices that do not exist in the same way for a typical credit-card purchase.
A bank-grade understanding therefore begins with roles, not logos.
2. The core participant map
At the center of the ecosystem are four business roles: cardholder, merchant, issuer and acquirer. Around them sit the network and multiple enablement roles.
The cardholder is the person or business using a card or payment credential. The cardholder may be using a physical card, a tokenized credential in a device wallet, a stored credential at a merchant, a virtual card, or another card-network-enabled form factor. The cardholder relationship is normally with the issuer, not with the merchant acquirer.
The merchant provides goods or services and accepts the card credential as a means of payment. The merchant has an acceptance relationship that may be directly with an acquirer or indirectly through a payment facilitator or another approved structure. The merchant is responsible for presenting the transaction accurately, following acceptance rules, protecting payment data, handling customer-facing order fulfilment and maintaining evidence for disputes.
The issuer provides the card account or credential to the cardholder. Depending on product, the issuer may extend credit, give access to deposit funds, maintain prepaid value, or support another account structure. The issuer manages cardholder onboarding, account controls, credential lifecycle, limits, fraud controls, authorization decisioning, statementing, billing or account posting, and customer disputes.
The acquirer supports merchant participation in card acceptance. It is responsible for the acquiring relationship under the applicable network framework, merchant onboarding and monitoring, transaction submission, clearing and settlement obligations on the merchant side, and merchant funding directly or through permitted service structures. The acquirer may perform these functions itself or use acquiring processors and other service providers.
The payment card network links participating issuers and acquirers, maintains operating rules and technical standards, switches or routes transaction messages, calculates or facilitates clearing and settlement obligations, maintains acceptance and network programs, and provides network-level security and risk capabilities. It does not automatically own the customer or merchant account simply because its brand appears on the card.
Around these roles sit issuing processors, acquiring processors, gateways, payment facilitators, ISOs, terminal providers, token service providers, fraud vendors, 3-D Secure components, digital wallets, settlement banks, sponsor institutions and other third parties. The practical challenge is that a single company can perform more than one of these functions, while a large bank may perform several functions internally.
A useful architecture technique is to model each party with two labels: business role and technical component. “Acquirer” is a business/network role. “Acquiring switch” is a technical component. “Issuer” is a role. “Card management system” is a component. “Payment facilitator” is a commercial/service-provider role. “Gateway API” is a component. Keeping those labels separate prevents architecture diagrams from turning vendors into legal roles by accident.
3. Cardholders and the issuer relationship
The cardholder is not merely the person holding plastic. In modern card processing, the credential can be represented physically or digitally. The underlying cardholder relationship includes identity, account ownership, product terms, security credentials, limits, funding or credit arrangements, card status, billing, servicing, dispute rights and fraud treatment.
For a credit card, the issuer normally extends or manages a revolving or charge-credit relationship under applicable terms. For a debit card, the card provides access to a deposit or transaction account. For prepaid, the value and legal account model may differ. Those differences matter operationally, but Chapter 30 owns the deep comparison. Chapter 27 focuses on the common ecosystem principle: the issuer is the cardholder-side financial institution in the standard network model.
The issuer generally controls whether a credential is active, blocked, expired, replaced, tokenized, limited or restricted. The issuer also maintains cardholder contact data, authentication methods, fraud strategies and authorization controls. When the cardholder reports a card lost or stolen, disputes a transaction, changes an address, requests a replacement or asks why a transaction was declined, the issuer or its designated servicing provider normally owns that customer interaction.
A cardholder may never know which processor the issuer uses. That is intentional. The issuing processor may maintain card records, authorization logic, transaction posting and statement data, but the customer relationship remains with the issuer. A bank architecture should therefore distinguish issuer of record from issuer processor.
Digital wallets add another layer. A wallet can hold a tokenized representation of the card credential, but the issuer still owns the underlying card account. The wallet provider may act as a token requestor and provide device-level user experience, while a network token service and issuer participate in provisioning and lifecycle decisions. Chapter 32 will treat this in depth. For Chapter 27, the lesson is that a wallet is an overlay around a card credential, not a replacement for issuer and network roles.
For reconciliation, the issuer’s financial truth includes authorization holds, posted transactions, fees, payments, reversals, refunds, chargebacks and settlement obligations. Cardholder-facing truth and network financial truth must ultimately reconcile, but they are held in different records and can move at different times.
4. Issuers: product, risk, authorization and account ownership
An issuer is responsible for far more than printing cards. It operates or sponsors the card program, owns the account relationship, participates in one or more networks, controls card credentials, makes or sponsors authorization decisions, receives clearing data, funds settlement obligations, posts transactions, bills or debits the customer, manages fraud and handles disputes.
From a systems perspective, a large issuer may have a card management platform, authorization engine, fraud engine, customer/account platform, tokenization interface, network gateway, clearing interface, settlement and GL processing, rewards platform, dispute platform, statement engine, collections platform and customer-service tools. Smaller issuers may outsource several of those capabilities to an issuing processor.
The issuer’s authorization role will be explained in Chapter 28, but the ownership boundary must be clear here. The network can route an authorization request and provide risk signals, but the issuer or its authorized processor generally makes the account-level approval decision. The issuer checks matters such as credential status, available funds or credit, account restrictions, fraud signals, velocity, merchant category, geographic or channel controls and other issuer policies.
An issuer can participate directly with a network or through sponsorship/service arrangements permitted by that network. Visa’s licensing materials distinguish licensed issuer and merchant-acquirer participation, and Mastercard similarly governs customers and service providers through its rules. The exact commercial and regulatory model varies, so a bank should never infer network membership solely from a processor connection.
Issuing banks also own portfolio economics. Interchange received, credit losses, fraud losses, rewards, funding costs, interest, fees and operational costs influence product design. Chapter 29 will explain interchange mechanics; Chapter 27 only needs the economic responsibility boundary: the issuer receives or pays network-related amounts according to the card and transaction type, and those economics should not be confused with the merchant’s total acceptance price.
From a BA perspective, issuer requirements should state whether the bank is issuer of record, sponsor issuer, program manager or processor. Those are different responsibilities. A requirement saying “the issuer will validate” is incomplete if the solution does not say which component performs the validation, who owns the decision and which entity is legally accountable.
5. Merchants and the acceptance relationship
The merchant is where the commercial sale originates. The merchant decides what is being sold, the amount, currency, order reference, tax and fulfilment conditions. The merchant also chooses which payment methods to accept, subject to applicable law, card-network rules and its acquiring agreement.
Card acceptance can happen at a physical POS terminal, unattended kiosk, mobile POS device, website, app, call centre, recurring-billing platform or other approved channel. Each channel changes the data and risk profile. Card-present acceptance involves EMV/contactless or other physical-presentment methods. Card-not-present acceptance relies on remotely supplied credentials and additional authentication/risk controls. Chapters 31 and 32 will cover these channels in depth.
The merchant relationship is usually governed by a merchant agreement with an acquirer or, for a sponsored merchant/submerchant, through a payment facilitator model supported by an acquirer. The agreement defines commercial pricing, permitted activity, funding, reserves where applicable, chargebacks, prohibited practices, data-security responsibilities, termination rights and other operational obligations.
Merchant onboarding is a control activity, not just sales administration. The acquiring side needs to establish that the merchant is a legitimate business, correctly classify the merchant category, understand expected volume and channels, assess fraud and chargeback risk, capture settlement-account details and maintain appropriate ongoing monitoring. In payment-facilitator models, some onboarding activity may be delegated, but the acquirer retains network responsibilities specified by the relevant network rules.
The merchant must also maintain good transaction data. Merchant name, merchant location, MCC, terminal or e-commerce indicators, order references and transaction descriptors affect issuer decisions, cardholder recognition, fraud monitoring, disputes and reporting. Poor descriptors create customer confusion and can increase disputes even when the underlying sale is legitimate.
Merchant reporting is another critical relationship. The merchant does not normally reconcile only against the amount a customer saw at checkout. It reconciles sales, refunds, chargebacks, fees, adjustments and merchant funding. That is why acquiring statements and settlement reports are business-critical artifacts, not administrative documents.
6. Acquirers and merchant acquiring
The acquirer sits on the merchant side of the network. In a simple four-party model, it connects the merchant into the network, submits transactions, receives network responses, participates in clearing and settlement, and pays the merchant according to the merchant agreement.
“Acquirer” should not be used as a synonym for every company that sells card acceptance. A merchant may buy services from a gateway, ISO, processor or payment facilitator, but the network acquirer remains a defined role. Discover describes an acquirer as the bank, financial institution or payments company that helps a business process transactions. Visa and Mastercard rules place explicit obligations on acquirers for merchant and service-provider activity.
The acquiring operating model normally includes merchant underwriting/onboarding, merchant ID configuration, terminal/e-commerce configuration, transaction acceptance, risk monitoring, clearing submission, fee calculation, settlement reconciliation, merchant funding, reserves where contractually applicable, disputes/chargebacks and merchant servicing.
A large acquirer can own the entire technology stack. Another acquirer may use an acquiring processor for switching, clearing, reporting and merchant-system functions. A sponsor bank may provide network membership and settlement while a processor or platform handles most operational technology. The solution architect must identify which party owns each state transition and financial obligation.
Acquirer controls must protect both the network and merchant portfolio. Merchant fraud, transaction laundering, excessive disputes, illegal activity, data compromise, abnormal volume and insolvency can create acquiring losses. Acquirer risk management therefore begins before the first transaction and continues throughout the merchant relationship.
For financial control, an acquirer must reconcile at multiple layers: network clearing, network settlement, processor positions, merchant-level sales/refunds/chargebacks, fees, reserves and merchant funding. A merchant can be correctly funded while the network position is wrong, or network settlement can be correct while an individual merchant is misfunded. Both dimensions need independent control.
7. Visa and Mastercard four-party network model
Visa and Mastercard are the clearest examples of the standard four-party card-network model used in education. The four parties are cardholder, issuer, merchant and acquirer, with the network connecting issuer and acquirer.
Visa describes a card purchase as involving issuer, cardholder, acquirer and merchant. Mastercard similarly describes its core network as linking card issuers and merchant acquirers and refers to the model as a four-party payments network. The network does not generally issue the customer’s card account or become the merchant’s acquiring bank merely because it switches the transaction.
The four-party model should be visualized as two customer relationships joined by a network. On the left: cardholder ↔ issuer. On the right: merchant ↔ acquirer. Between issuer and acquirer: network rules, routing, clearing and settlement services. The authorization request travels from merchant/acquirer toward the issuer; the response comes back. Clearing later communicates the financial presentment. Settlement settles the obligations between participating institutions. Merchant funding completes the acquirer-to-merchant economic leg.
This separation explains why the issuer can decline a transaction even when the merchant wants to accept it. It also explains why the merchant normally contacts its acquirer or provider for acceptance problems rather than contacting the cardholder’s issuing bank. The network creates interoperability between institutions that otherwise have no bilateral customer relationship.
The network also maintains rules, programs, data standards, dispute frameworks, security requirements, network-level risk controls, tokenization capabilities, acceptance programs and other services. Visa’s public rules and Mastercard’s public rules show that participation includes far more than message routing.
The same institution can sometimes perform both issuing and acquiring businesses, but the transaction roles are still conceptually distinct. A bank may issue cards to consumers and separately acquire merchants. Systems and ledgers should not collapse those lines of business merely because the legal entity is the same.
8. American Express, Discover and other network models
The US market should not be taught as if every card follows the same organizational model. American Express publicly describes itself as having experience across issuer, acquirer and network roles, while also supporting issuer and acquirer partners on its network. This creates a model that can be more integrated than a classic four-party structure while still allowing partner participation.
Discover also has a broader network structure. Discover Global Network includes Discover Network, Diners Club International and PULSE. Discover can therefore appear in credit-card acceptance, issuing partnerships, network alliances and debit-network contexts. The exact transaction path depends on the credential and network arrangement.
This matters for analysts because participant labels must come from the actual transaction path, not from brand assumptions. A learner might see an American Express card and assume the same issuer/acquirer separation as Visa. Another might see a Discover-branded debit transaction and ignore PULSE routing. Both assumptions can lead to wrong message-routing, settlement or reporting designs.
Private-label and closed-loop programs create another variation. A retailer may issue or sponsor value that is accepted only within a controlled merchant group. Those arrangements may not use a general-purpose network in the same way. Chapter 30 will handle closed-loop value and product structures in detail.
The right design pattern is to model network role, issuer role and acquirer role independently, then map which legal entity performs each role for the specific product. This makes the architecture resilient to different brands and partnerships.
For operational reporting, the bank should also retain the actual network identifier and route used for each transaction. “Card transaction” is too generic for reconciliation. Network, product, funding type, acceptance channel and settlement service influence downstream controls.
9. Debit networks and US routing choice
The US debit-card ecosystem adds a layer that many global card explanations miss: a debit card can be enabled for processing over multiple networks, and Regulation II contains network-exclusivity and routing provisions.
The Federal Reserve’s Regulation II materials explain that issuers and networks may not restrict debit-card processing to fewer than two unaffiliated networks, and may not inhibit a merchant’s ability to direct routing over a network enabled to process the transaction. This is a major architectural difference from treating a debit card as if one front-of-card brand always dictates the only processing route.
US debit routing can involve global networks and domestic debit networks such as PULSE, STAR, NYCE and others depending on card enablement, merchant/acquirer support and transaction characteristics. PIN debit, PINless debit and signature-style debit experiences can follow different network paths and rules. Chapter 30 will explain debit products in more depth, while Chapter 29 will cover economics and settlement.
From an acquiring perspective, routing logic must know which networks are enabled for the card/account range and which are available for that merchant and transaction. The route must also respect regulation, network rules, merchant configuration, risk controls and technical availability.
From an issuer perspective, network enablement is a product and compliance design decision. The issuer must maintain network participation and routing capabilities consistent with applicable requirements. The processor must not accidentally disable competitive routing through an implementation choice that contradicts the issuer’s regulatory obligations.
Debit routing is therefore not simply “send Visa debit to Visa.” That shortcut is educationally wrong and operationally dangerous.
10. Processors, gateways, ISOs, payment facilitators and service providers
Modern card acceptance is heavily intermediated. The merchant may never contract directly with the technical system that ultimately sends a network message, and the acquirer may not operate every system itself.
An acquiring processor provides transaction-processing technology on the merchant/acquirer side. Typical functions can include terminal or merchant configuration, message switching, authorization connectivity, clearing-file preparation, settlement reporting and merchant statements. The processor may act on behalf of one or many acquirers.
An issuing processor provides card-account and transaction technology for issuers. It may maintain card records, authorization processing, transaction posting, token interfaces, statements or other card-platform functions. The issuer remains responsible for its program and regulatory obligations even when technology is outsourced.
A payment gateway connects a merchant’s digital or physical commerce environment to acquiring/payment-processing services. In e-commerce, it may tokenize credentials, format authorization requests, integrate fraud services and manage connectivity. Gateway does not automatically mean acquirer.
An independent sales organization (ISO) may market acquiring services, support merchant onboarding or provide merchant-facing services under registered arrangements. Exact permitted activities depend on network and acquirer arrangements. Visa’s third-party-agent framework includes ISO activity among registered agent types.
A payment facilitator is a more specific model. Mastercard defines a payment facilitator as a service provider registered by an acquirer to facilitate transactions for submerchants. Visa rules similarly define acquirer/payment-facilitator/sponsored-merchant relationships and place contractual and oversight obligations on the acquirer. The merchant experience may appear to be “one platform account,” but underneath it sits an acquiring relationship and network governance.
A service provider can include entities that store, process or transmit cardholder data or affect the cardholder-data environment. PCI SSC explicitly includes payment gateways, PSPs and ISOs in relevant service-provider discussions. This introduces shared-responsibility questions that must be documented rather than assumed.
The crucial control principle is:
outsourcing a function does not automatically outsource accountability.
A bank must know who can change merchant configuration, who holds encryption keys, who owns network certification, who produces clearing files, who releases settlement, who stores cardholder data, who operates fraud rules and who responds to incidents.
11. Identifiers and reference data that hold the ecosystem together
Cards work because many participants agree on common identifiers and reference data. A production system cannot route or reconcile transactions reliably using merchant names and bank names alone.
The PAN or tokenized payment credential identifies the card/account relationship within the relevant scheme rules. The leading digits historically associated with a BIN are increasingly described as an IIN/BIN range; Visa notes that licensed BINs may be six to eight digits and carry attributes such as issuer, product and licensed country. Systems should therefore not hard-code six-digit assumptions where eight-digit ranges are supported.
An issuer identification range supports routing and product recognition. It does not by itself prove that a transaction is genuine. Fraud engines still need contextual information because a valid BIN can be used in fraudulent credentials.
A Merchant ID (MID) identifies the merchant relationship within an acquiring environment. Large merchants may have multiple MIDs by legal entity, location, channel, region or business line. Payment facilitators may maintain submerchant identifiers beneath a master relationship.
The Merchant Category Code (MCC) classifies merchant activity. MCC influences risk, interchange qualification, controls, rewards, compliance and reporting. Incorrect MCC assignment can therefore have financial and regulatory consequences.
Terminals, devices, gateways and transactions have additional identifiers: terminal ID, acquirer reference number or equivalent network reference, authorization code, retrieval reference, transaction identifier, clearing identifiers, token requestor IDs and other network-specific values. Chapter 28 and 29 will show how these move through lifecycle states.
Reference data must be versioned and governed. Network BIN tables, merchant configurations, network participation, product attributes, routing tables, currency rules, MCC definitions and service-provider relationships all change. A bank should be able to explain which reference-data version influenced a transaction decision.
12. How a purchase crosses the ecosystem end to end
Consider a customer buying a laptop at a US merchant. The customer presents a card or device credential. The merchant captures the sale amount and credential through its acceptance environment. The merchant’s gateway or terminal sends the transaction to the acquiring processor/acquirer. The acquiring side identifies the network route and sends an authorization request through the network. The network routes the request to the issuer or issuer processor. The issuer evaluates the card/account and returns an approval or decline. That response flows back to the merchant.
At this point, the customer may leave with the laptop, but the financial lifecycle is not finished. The approved transaction is later captured/presented for clearing. The network and participants calculate financial obligations. Settlement moves inter-institution value according to the network process. The acquirer funds the merchant according to the merchant agreement, net of applicable fees, adjustments, reserves or other items. The issuer posts the transaction to the cardholder account.
The exact timing and files/messages differ by network, product and processor. Chapter 29 will go deeply into those mechanics. What Chapter 27 must establish is the ownership chain:
- merchant owns the sale and presentment accuracy;
- acquirer owns the merchant-side acquiring relationship and submission responsibilities;
- network owns network switching/rules and inter-participant framework;
- issuer owns the cardholder account and authorization/account posting side;
- processors execute delegated technology functions;
- settlement and merchant funding are separate financial events.
When a transaction is declined, the merchant usually receives a response through the acquiring route; it does not call the issuer’s core banking system. When a clearing record is missing, the processor and acquirer investigate presentment. When a cardholder disputes the purchase, the issuer begins the cardholder-side dispute process and the network/acquirer/merchant side may need to provide evidence. Each problem enters the ecosystem at a different ownership point.
A bank-grade case-management platform should therefore store participant identifiers for every transaction. Without issuer, acquirer, network, merchant and processor context, operational teams cannot route exceptions correctly.
13. Economics, fees and commercial ownership
Card economics are often oversimplified into the phrase “merchant fee.” In reality, different amounts compensate different roles.
The merchant discount rate or merchant service charge is what the merchant pays under its acquiring/processing agreement. It may include interchange, network fees, processor/acquirer margin, gateway or platform fees and other service charges depending on pricing model.
Interchange is generally a transfer between acquiring and issuing sides under network rules. In a typical purchase, the issuer receives interchange from the acquiring side, though the exact economics depend on network, product, transaction type and regulatory rules. Regulation II places specific limits and conditions on interchange received by covered debit-card issuers, with exemptions and a fraud-prevention adjustment framework.
Network fees are separate network charges and should not be labelled interchange. The Federal Reserve’s Regulation II materials explicitly distinguish interchange transaction fees from network fees in the debit context.
Processor, gateway, payment-facilitator and service fees are commercial charges for technology and services. They may be bundled into the merchant price or separately contracted.
The acquiring side also bears merchant credit and operational exposure. If a merchant fails after taking payment for future delivery, or generates excessive chargebacks, the acquirer can be exposed under network and contractual rules. That risk is one reason acquiring underwriting, reserves and monitoring exist.
The issuer bears different economics: funding/credit cost, fraud losses, rewards, customer servicing, credit losses for credit products, processing costs and network charges. The cardholder may pay interest or fees depending on product terms. None of those should be automatically described as network revenue.
For BAs, the practical rule is to model fee components individually. A single field called CARD_FEE is rarely sufficient for finance and reconciliation. At minimum, architecture should be capable of distinguishing gross transaction amount, interchange, network assessments/fees, acquiring/processing charges, merchant net funding and other adjustments.
14. Security, PCI, fraud and compliance responsibility
Card security is shared across the ecosystem. PCI DSS applies to entities that store, process or transmit cardholder data and to entities that can affect the security of the cardholder-data environment. PCI SSC explicitly identifies merchants, processors, acquirers, issuers and service providers within the intended audience.
A merchant that outsources payment processing does not automatically become free of responsibility. PCI SSC explains that merchants using third parties must still ensure appropriate service-provider compliance, maintain responsibility allocations and validate their own applicable compliance obligations.
Issuers protect credentials and accounts through onboarding, authentication, card lifecycle, authorization controls, fraud detection and post-transaction monitoring. Acquirers protect the ecosystem through merchant underwriting, transaction monitoring, data-security programs, fraud controls and service-provider oversight. Networks provide network-level standards, security programs, tokenization capabilities, dispute frameworks and risk controls.
Tokenization reduces exposure of the underlying account number in supported flows, but it adds participants and lifecycle events. Token service provider, token requestor, wallet provider, issuer and merchant/acquirer systems may all play a role. Chapter 32 will teach this architecture in detail.
EMV chip, contactless and 3-D Secure similarly belong to the broader card-security architecture, but their detailed processing is intentionally deferred. Chapter 27’s goal is to show who owns which control boundary.
Compliance responsibilities also include merchant legality, sanctions and prohibited activity, privacy, consumer-protection requirements, network rules and debit-routing requirements. A card network’s rulebook is not a substitute for law, and legal compliance does not remove network-contract obligations. Banks and merchants operate under both.
Security architecture should therefore include a responsibility matrix: data storage, encryption, tokenization, key management, PCI scope, fraud decisioning, merchant monitoring, incident response, breach reporting, credential replacement and dispute handling. Every outsourced component needs a named owner.
15. Reconciliation, reporting, controls and real-bank operations
The card ecosystem produces several different financial and operational truths. Real-bank operations must reconcile them rather than trust a single report.
On the issuer side, the bank reconciles authorization activity, clearing presentments, settlement obligations, cardholder posting, reversals, refunds, disputes, fees and GL positions. An authorization can exist without a corresponding clearing record. A clearing transaction can differ in final amount from the authorization in permitted scenarios. A refund is not the same object as reversing an authorization hold.
On the acquiring side, the bank or processor reconciles merchant transactions, network clearing, settlement, fees, chargebacks, refunds, adjustments, reserves and merchant funding. Merchant funding may be netted across many transaction types, so operations need transaction-to-batch-to-funding lineage.
Network reconciliation sits between those two sides. The network’s clearing and settlement reports provide authoritative inter-participant data according to network rules. Processor data must reconcile to those reports. Internal ledgers must reconcile to processor and network data. Customer/merchant statements must reconcile to the financial ledger.
A mature operating model maintains separate queues for authorization anomalies, clearing rejects, settlement breaks, merchant funding exceptions, cardholder posting failures, duplicate presentments, unmatched refunds and dispute-related financial items. Calling all of them “card exceptions” makes root-cause analysis difficult.
Reporting also serves different audiences. Cardholders need understandable statements. Merchants need sales and funding reports. Treasury needs settlement positions. Finance needs fee and GL reporting. Fraud needs risk and loss reporting. Compliance needs PCI, merchant-risk and regulatory evidence. Product teams need approval rates, decline reasons, acceptance, spend and portfolio economics.
Controls should include maker-checker or equivalent governance for sensitive merchant and card configuration, strong access controls, segregation of duties, approved network/reference-data changes, settlement sign-off, funding controls, duplicate prevention, file completeness controls and incident management.
The real operational lesson is that cards are continuous even when some financial processes are batch-oriented. Authorization runs around the clock. Clearing and settlement cycles may follow network schedules. Merchant funding follows agreements and business calendars. Disputes and fraud cases follow their own timelines. Operations must manage all of these clocks at once.
16. Architecture, testing, role checklist and authoritative references
A bank-grade card architecture should separate at least these domains: cardholder/customer, card product and card management, authorization, fraud, network connectivity, merchant/acquiring, payment gateway, clearing, settlement, accounting, merchant funding, disputes, data/token security, reporting and operational case management. Smaller organizations may buy many of these as services, but the logical responsibilities still exist.
The canonical participant data model should capture issuer, acquirer, network, merchant, processor and service-provider identifiers separately. Do not use one field called BANK. Do not use one field called CARD_NETWORK to represent issuer, route and product simultaneously. Maintain explicit fields for issuer/network/product/routing and preserve network references through authorization, clearing, settlement and dispute lifecycles.
Testing must cover role boundaries, not only message success. A useful Chapter 27 test pack includes: correct issuer routing by BIN/IIN; correct merchant/acquirer mapping; invalid or suspended merchant; wrong MCC; payment-facilitator/submerchant mapping; service-provider outage; multiple debit-network availability; merchant routing preference; network failover restrictions; processor duplicate; missing clearing presentment; merchant-funding mismatch; tokenized credential with correct issuer relationship; merchant data-security configuration; and reconciliation across processor/network/ledger reports.
For Business Analysts, confirm participant roles, contracts, process ownership, financial ownership, identifiers, exception owners, reports and regulatory/network-rule boundaries.
For Architects, model business roles separately from technical services, maintain end-to-end identifiers, isolate PCI-sensitive zones, support multiple networks, design for processor substitution and provide independent reconciliation points.
For Developers, implement network/processor adapters without leaking vendor-specific assumptions into the canonical card model, preserve idempotency and correlation, protect sensitive data and make participant/reference-data decisions observable.
For Testers, verify happy paths and cross-party failure paths, including mismatched issuer/acquirer data, wrong merchant configuration, network unavailability, duplicate messages and financial breaks.
For Operations, maintain clear ownership for authorization, clearing, settlement, merchant funding, fraud, disputes and reconciliation queues; never close a case solely because the customer-facing UI looks correct.
For Fraud and Compliance, maintain issuer-side and acquirer-side control responsibilities, merchant monitoring, PCI governance, data-compromise response and regulatory routing controls.
For Treasury and Finance, reconcile settlement obligations, merchant funding, interchange/network fees, processor charges and GL positions independently.
The deepest lesson from Chapter 27 is that a card payment is a coordinated ecosystem. When a bank knows exactly which party owns the customer, merchant, credential, route, approval, clearing, settlement, funding, data and exception, later card chapters become much easier to understand.
Authoritative references
Visa Rules and Policy
https://www.visa.com/en-us/support/visa-rules
Visa Core Rules and Visa Product and Service Rules — public edition
https://cis.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf
Visa licensing program
https://partner.visa.com/site/programs/licensing-program.html
Visa Account Information Security / PCI information
https://corporate.visa.com/en/resources/security-compliance.html
Visa BIN Attribute Sharing Service
https://www.visa.com/en-us/products/visa-bin-attribute-service
Mastercard Rules and compliance programs
https://www.mastercard.com/us/en/business/support/rules.html
Mastercard Rules — public document
https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf
American Express Global Network
https://network.americanexpress.com/globalnetwork/v4
American Express — acquirer network model
https://network.americanexpress.com/globalnetwork/v4/partners/acquirers/power-of-the-network/
Discover Global Network
https://www.discoverglobalnetwork.com/
Discover — Find an Acquirer
https://www.discoverglobalnetwork.com/resources/businesses/find-an-acquirer/
Discover Network / Diners Club / PULSE model
https://www.discoverglobalnetwork.com/our-network/our-unique-network/
Federal Reserve — Regulation II: Debit Card Interchange Fees and Routing
https://www.federalreserve.gov/paymentsystems/regii-about.htm
Federal Reserve — Regulation II regulatory text
https://www.federalreserve.gov/frrs/regulations/regulation-ii-debit-card-interchange-fees-and-routing.htm
Federal Reserve — Regulation II FAQs
https://www.federalreserve.gov/paymentsystems/regii-faqs.htm
PCI Security Standards Council — PCI DSS
https://www.pcisecuritystandards.org/standards/pci-dss/
PCI SSC — acquirers and service-provider responsibilities
https://www.pcisecuritystandards.org/faqs/1284/
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.