What is a credit card processing network?
A credit card processing network is the infrastructure that carries authorization and settlement messages between the bank that issued a cardholder’s card and the bank that holds the merchant’s account. Visa, Mastercard, American Express, and Discover are the four networks that handle the overwhelming majority of this traffic globally.
Key stat: Those four networks moved 828.10 billion card purchase transactions in 2025, up 7.1% over 2024 (Nilson Report, Issue 1310, June 2026). Visa alone accounted for 40.76% of that volume (Nilson Report, June 2026).
The network doesn’t touch a merchant’s checkout page, API, or codebase. A gateway or PSP does that, then hands the transaction to the network on the merchant’s behalf. That handoff is where most of the confusion about “processing” starts, which is what the rest of this article sorts out.
The building blocks: issuer, network, acquirer, and where the gateway or PSP fits
Four roles show up in every card transaction, and mixing them up is the single most common mistake in how teams talk about payments.
- The issuer is the bank or fintech that issued the cardholder’s card, holds the account, and makes the approve or decline call.
- The network, Visa, Mastercard, Amex, or Discover, is the rail that carries the authorization message between issuer and acquirer and sets the rules both sides follow.
- The acquirer is the bank that holds the merchant’s account and submits transactions onto the network on the merchant’s behalf.
- The gateway or PSP is the software layer a merchant or platform actually integrates with: it formats the transaction, applies fraud rules, and routes it to an acquirer, which routes it onto the network.
A developer never calls Visa’s API. They call a gateway or PSP’s API, and everything past that point is infrastructure they don’t touch directly. For a full breakdown of the gateway and PSP roles, see Payment Processor vs Payment Gateway: Key Differences.
One wrinkle matters here: Visa and Mastercard run an open, four-party model where issuer and acquirer are always separate banks. American Express and Discover run a closed, three-party model where the network is also the issuer, a distinction that resurfaces below when we get to decline handling. Payment Card Network: How It Works & Why Routing Matters covers the four-party model, network fees, and network tokenization in more depth than fits here.
How a transaction actually moves: the authorization message flow, step by step
Most explainers stop at “the transaction gets approved.” For a developer designing retries, timeouts, and idempotency handling, the sequence matters more than the summary. In simplified form:
- Your application sends the transaction to your gateway or PSP.
- The gateway formats the request and applies its own fraud and validation rules. A malformed request or a rule violation can get rejected here, before the network ever sees it.
- The gateway routes the request to an acquirer.
- The acquirer submits the authorization request onto the card network.
- The network forwards the request to the card’s issuing bank.
- The issuer runs its own risk scoring, checks available funds or credit, and returns an approve or decline.
- The response travels back through the same path: issuer to network to acquirer to gateway to your application.
The full round trip commonly falls in the 150ms to 5,000ms range. Issuer-side processing speed varies by an order of magnitude depending on the issuer’s own architecture: Qonto, a European card issuer, reports its own authorization system responds in an average of 15ms, against a stated industry average of 150 to 300ms for third-party issuer-processing systems (Qonto engineering blog, 2025). That figure is issuer-side latency specifically, not the full round trip, and it’s a reminder that the network itself usually isn’t the bottleneck. The issuer’s own processing stack is.
Every scheme enforces a hard timeout on this exchange.
Key stat: Mastercard’s Stand-In Processing (STIP) takes over the authorization decision if the issuer doesn’t respond within 7 seconds, using pre-configured parameters so the transaction doesn’t fail outright on an issuer-side outage (Intelica).
That’s a network-level failover mechanism, but a blunt one: issuer-configured stand-in rules, not your application’s own retry logic. What happens after authorization, when the money actually moves, is a separate stage with its own failure modes; see Payment Authorization vs Settlement: How They Differ.
Processing network vs. payment gateway vs. PSP vs. acquirer: who does what
These four terms get used interchangeably, which is exactly what causes integration mistakes. The functional split:
| Role | What it does | Who your code talks to |
|---|---|---|
| Network (Visa, Mastercard, Amex, Discover) | Carries authorization and settlement messages between issuer and acquirer; sets scheme rules | Never directly |
| Acquirer | Holds the merchant’s account; submits transactions onto the network | Rarely directly, usually through a gateway or PSP |
| Gateway | Formats and transmits transaction data; applies fraud rules before submission | Directly, via API or SDK |
| PSP | Provides the merchant-facing account, dashboard, and API; often bundles gateway and acquiring functions | Directly, via API or SDK |
A PSP is a company a merchant contracts with directly. The network is the underlying rail every PSP eventually routes through, not something a merchant signs up for on its own. Third-Party Payment Gateway vs. Direct PSP Integration goes further into how the gateway and PSP layers differ when you’re choosing an integration path.
The major processing networks: Visa, Mastercard, Amex, Discover, and regional rails
Visa and Mastercard operate the open, four-party model described above. American Express and Discover’s closed, three-party structure gives them tighter control over the authorization decision but a smaller card-issuing footprint than Visa or Mastercard.
Outside the US, regional rails carry significant volume on their own terms: China UnionPay, India’s RuPay, and France’s Cartes Bancaires all operate independently of the four majors, with their own rules and, in some cases, their own tokenization and routing requirements. A platform expanding into those markets needs a PSP or gateway that already supports them; building direct network connectivity per market isn’t realistic for most teams. Payment Card Network covers how network-level routing and fees change once cross-border rails are involved.
Network tokenization plays an increasing role across all of these rails:
- Network tokens lift authorization rates by 4.6% globally for card-not-present transactions compared to raw card numbers (Visa, 2025)
- Half of Visa’s digital card transactions are now tokenized, carrying roughly a 5-percentage-point higher completion rate and a 40% lower fraud rate than PAN-based transactions (Payments Dive, 2025-09-10)
- Mastercard reports a 3 to 6-percentage-point increase in completed spend on tokenized transactions (Payments Dive, 2025-09-10)
For how network tokens differ from vault tokens, see Network Tokenization: What It Is, How It Works, and Why It Matters.
Where processing networks introduce latency, declines, and single points of failure
Not every failure happens at the same layer, and lumping them together makes debugging harder than it needs to be.
| Failure layer | What triggers it |
|---|---|
| Gateway-level rejection | A malformed request, a triggered fraud rule, or a validation failure gets stopped at your gateway or PSP before the network is involved |
| Network-level failure | A timeout or outage on the rail itself, what STIP and equivalent mechanisms exist to paper over |
| Issuer-level decline | Insufficient funds, risk scoring, an expired card, or a mismatched CVV, decided by the issuing bank and relayed back through the network |
The gateway didn’t make that call, and neither did the network. It just carried the answer.
Card-not-present authorization rates run about 10 percentage points lower than in-person transactions, and “do not honour” is the single most common decline code, spanning reasons from insufficient funds to fraud suspicion (Stripe, “Optimizing authorization rates”). Domestic authorization rates typically run in the mid-to-high 90 percent range, with cross-border transactions performing measurably lower, largely because cross-border traffic trips more issuer-side risk rules (Gr4vy, 2026). None of that is a network defect; it’s the network relaying decisions made upstream and downstream of it. The single point of failure worth building around usually sits at your gateway or PSP layer, not the network layer.
How Orchestra’s routing layer sits on top of processing networks
Orchestration doesn’t replace the network. It sits above the PSP and acquirer layer, deciding which PSP or acquirer a given transaction should route through, and that PSP or acquirer still settles over the same Visa, Mastercard, Amex, or Discover rails described above.
Orchestra’s routing layer applies four routing strategies, configurable without code changes:
- Cost-based
- Geographic
- Performance
- Hybrid
Reported impact: an average 15% cost reduction and 8 to 12% higher approval rates on challenging transactions, with routing decisions made in under 50ms.
BIN-based routing is a concrete example: the card’s issuing bank identification number carries enough information to route intelligently before a transaction is sent, one input among several an orchestration layer can act on.
def select_processor(txn):
bin_info = lookup_bin(txn.card_number[:6])
candidates = psps_supporting(bin_info.country, bin_info.card_network)
return best_match(candidates, criteria=[bin_info, txn.currency, txn.amount])See Card BIN Routing: The Routing Decision Your PSP Doesn’t Show You for how that decision gets made and why most PSPs make it silently on your behalf.
Failover works the same way structurally as STIP, but with your own business logic instead of scheme-configured defaults: when a primary processor declines or goes down, Orchestra routes the transaction to a backup processor instantly, built around your approval-rate or cost targets rather than the network’s scheme defaults. For where orchestration fits against direct processing relationships more broadly, see Payment Orchestration vs. Payment Processing.
Frequently Asked Questions
What is a credit card processing network?
A credit card processing network, like Visa, Mastercard, American Express, or Discover, is the rail that carries authorization and settlement messages between the bank that issued the cardholder’s card and the bank that holds the merchant’s account. It doesn’t touch the merchant’s software directly; gateways and PSPs do that.
What’s the difference between a credit card processing network and a payment gateway?
The network is the infrastructure that moves transaction messages between issuer and acquirer. The gateway is the software layer a merchant or platform integrates with to submit a transaction and get it onto that infrastructure. A merchant never talks to Visa’s rails directly; they talk to a gateway or PSP, which talks to the network on their behalf.
Is a processing network the same thing as a PSP?
No. A PSP (payment service provider) is a company that gives merchants an API or dashboard to accept payments; it routes transactions to acquirers and networks under the hood. The processing network is the underlying rail all PSPs eventually route through, not a service a merchant contracts with directly.
How does a transaction move through the processing network?
In simplified form: the merchant’s gateway sends the authorization request to an acquirer, the acquirer routes it onto the card network, the network forwards it to the card’s issuing bank, and the approval or decline travels back the same path in reverse, typically in under a second.
Which companies operate credit card processing networks?
Visa and Mastercard operate open-loop, four-party networks with separate issuing and acquiring banks. American Express and Discover operate closed-loop, three-party networks where they act as both network and issuer. Regional rails like China UnionPay, RuPay, and Cartes Bancaires carry significant volume outside the US.
Does a payment orchestration platform replace the processing network?
No. Orchestration sits above the network, not in place of it. Orchestra routes a transaction to the PSP or acquirer best suited for a given payment, but that PSP or acquirer still settles the transaction over the same Visa, Mastercard, Amex, or Discover rails.
Why do declines happen at the network or issuer level instead of the gateway?
A gateway can reject a transaction for formatting or fraud-rule reasons before it ever reaches the network. But most declines (insufficient funds, risk scoring, expired card) are issuer decisions returned through the network. A gateway just relays that response; it doesn’t make the call.
What’s the difference between a credit card network and a credit card issuer?
The network (Visa, Mastercard) is the shared infrastructure that routes authorization messages; the issuer is the bank or fintech that issued the cardholder’s card, holds the account, and makes the approve or decline decision. On Visa and Mastercard’s four-party model, network and issuer are always separate entities. On Amex and Discover’s three-party model, the network is also the issuer.
