How Payment Processor Works
A payment processor sits at the center of every card transaction, orchestrating a rapid sequence of messages between four parties — the merchant, the card network, the issuing bank, and the acquiring bank — typically within two to three seconds. Understanding the step sequence helps merchants diagnose authorization failures and choose the right processing stack.
Customer Initiates Payment
The cardholder presents a card (physical or virtual) at a POS terminal or online checkout. The payment gateway captures and encrypts the card data, then forwards it securely to the payment processor.
Processor Routes to Card Network
The processor identifies the card network (Visa, Mastercard, Amex, Discover) from the card BIN and transmits an authorization request message (ISO 8583 format) to that network's switch.
Issuer Approves or Declines
The issuer — the cardholder's bank — receives the request, checks available funds, fraud signals, and account status, then returns an authorization code or decline reason back through the network.
Response Delivered to Merchant
The processor relays the issuer's decision to the gateway and POS terminal in real time. An approval triggers an authorization hold on the cardholder's account. A decline surfaces an error code to the merchant.
Capture and Batch Settlement
At end of day (or in real time for some integrations), the merchant sends a capture request for all approved authorizations. The processor batches these and submits them to the acquirer for clearing and settlement through the card network. Funds move from the issuing bank to the acquiring bank, then into the merchant's account — typically within one to two business days.
Authorization ≠ Settlement
Authorization only places a hold on funds. Settlement is the actual movement of money. A transaction can be authorized but never captured — common in hospitality pre-authorizations — meaning the merchant never receives funds despite an approval.
Why Payment Processor Matters
Choosing and configuring a payment processor correctly has a direct, measurable impact on revenue. A single percentage-point improvement in authorization rates can translate to millions of dollars for mid-market merchants, and processor downtime directly causes cart abandonment.
Global card payment transaction volume reached $67 trillion in 2023, according to Nilson Report data, making the payment processor one of the highest-throughput infrastructure components in commerce. On the cost side, U.S. merchants paid an estimated $172 billion in card acceptance fees in 2023 (Federal Reserve Payments Study), the bulk of which flow through processors as interchange, network fees, and processing margins. Authorization failure rates average 8–15% for card-not-present transactions (Mastercard benchmarks), and a significant share of those declines are recoverable through processor-level retry logic, network tokens, and account updater services — tools that are only available if your processor supports them.
Authorization Rate Benchmarks
Top-performing ecommerce merchants achieve authorization rates above 90% on domestic transactions. Below 85% is a red flag that typically indicates processor configuration issues, missing 3DS optimization, or a mismatch between the merchant category code (MCC) and the business type.
Payment Processor vs. Payment Gateway
Merchants frequently use "processor" and "gateway" interchangeably, but they describe different layers of the payment stack. The distinction matters when troubleshooting failures, negotiating contracts, and architecting multi-vendor setups.
| Dimension | Payment Processor | Payment Gateway |
|---|---|---|
| Primary role | Routes transactions through card networks; manages authorization and settlement | Captures, encrypts, and transmits card data to the processor |
| Who it talks to | Card networks (Visa, Mastercard), issuing banks, acquiring bank | Merchant's checkout or POS; payment processor |
| Data handled | Authorization messages, settlement files | Raw cardholder data (PAN, CVV, expiry) |
| Failure impact | Transactions cannot authorize or settle | Card data cannot reach the processor |
| Pricing | Per-transaction fees, interchange pass-through | Monthly SaaS fee or per-transaction API fee |
| Examples | TSYS, Worldpay, Adyen (processor side), Fiserv | Stripe (gateway layer), Braintree, NMI |
| PCI scope | SAQ D or processor-managed | SAQ A or SAQ A-EP depending on integration |
Many payment service providers (PSPs) bundle gateway and processor functionality into a single API, which simplifies integration but reduces pricing leverage for high-volume merchants.
Types of Payment Processor
Not all processors operate the same model. Understanding the variants helps merchants match the right provider to their transaction mix, volume, and risk profile.
Front-End Processors connect directly to card network switches (Visa Net, Banknet) and handle real-time authorization routing. They are typically used by large acquirers and enterprise merchants. Examples: FIS, TSYS.
Back-End Processors handle clearing and settlement — moving funds between issuing and acquiring banks after authorization. Many acquirers operate their own back-end processor or outsource to a shared utility.
Integrated (Full-Service) Processors perform both front-end and back-end functions. This is the most common model for mid-market merchants. Examples: Worldpay, Adyen, Fiserv.
Payment Facilitators (PayFacs) act as the merchant of record, sub-merchant-boarding under their own acquiring relationship. Stripe and Square are PayFacs — merchants get fast onboarding but less pricing control.
Independent Sales Organization (ISO) Processors resell processing capacity from larger processors or acquirers, often under a white-label arrangement. Common in the SMB market.
Specialized Processors focus on specific verticals — recurring billing processors (e.g., Recurly-integrated processors), high-risk processors for industries like gaming or nutraceuticals, or cross-border processors optimized for multi-currency settlement.
Best Practices
For Merchants
Negotiate interchange-plus pricing over flat-rate once monthly card volume exceeds $20,000. Flat-rate simplifies accounting but systematically overpays on low-interchange cards (debit, corporate cards with rewards stripped).
Enable network tokenization through your processor. Visa and Mastercard network tokens replace the PAN with a processor-specific token that automatically updates on card reissue, reducing declines from expired cards by 10–20%.
Monitor authorization rates by card type, BIN country, and device. Most enterprise processors provide decline reason code reporting. Segment by domestic vs. international and card-present vs. card-not-present to pinpoint systemic issues.
Implement account updater services for subscription businesses. Processors integrated with Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) automatically refresh stored card credentials before a payment attempt.
Understand your contract's early termination clause and PCI liability shift. Some processor contracts include liquidated damages for early exit and shift PCI breach liability to the merchant if tokenization is not used.
For Developers
Use the processor's test environment with full BIN simulation. Most enterprise processors provide test card ranges that simulate specific decline codes (insufficient funds, do-not-honor, velocity limits) — use these to build robust retry logic.
Implement idempotency keys on all capture and refund requests. Network timeouts can cause duplicate submissions; idempotency prevents double charges without requiring synchronous confirmation.
Handle soft declines with intelligent retry scheduling. Decline codes like 05 (Do Not Honor) are often transient. A retry after 24 hours converts 15–30% of initial soft declines on average (Visa data).
Store processor transaction IDs alongside your internal order IDs. Reconciliation and chargeback responses require the processor's retrieval reference number (RRN) or authorization code — not just your internal ID.
Validate webhook signatures before processing settlement events. Processors send settlement and chargeback webhooks that trigger fund movements in your system; an unvalidated endpoint is a financial fraud vector.
Common Mistakes
Conflating authorization with payment. Merchants sometimes fulfill orders on authorization alone without confirming capture and settlement. Network rules require capture within a set window (typically 7 days for ecommerce) — uncaptured authorizations void automatically and revenue is lost.
Ignoring processor-specific MCC assignment. An incorrect Merchant Category Code assigned at onboarding causes systematic authorization declines for certain card types and exposes the merchant to incorrect interchange rates. Verify MCC during boarding and request correction if it does not match the primary business activity.
Using a single processor with no failover. Processor outages, however rare, directly stop revenue. Merchants processing above $500K/month should route through at least two processors or implement an orchestration layer with automatic failover.
Not reviewing decline reason codes regularly. Many merchants only look at overall authorization rates. Drilling into specific decline codes (e.g., a spike in 14 — Invalid Card Number — often indicates a scraping attack or form validation bug) reveals actionable root causes.
Overlooking cross-border routing fees. When a domestic processor routes an international card, cross-border fees (typically 0.4–1.1% on top of interchange) apply. Merchants with high international volume should negotiate cross-border fee caps or use a processor with local acquiring in key markets.
Payment Processor and Tagada
Tagada is a payment orchestration platform, not a processor itself — it sits above your processor layer and connects to multiple processors, gateways, and payment service providers through a single API integration.
Tagada and Processor Orchestration
With Tagada, you can route each transaction to the optimal processor based on card BIN, currency, transaction amount, or real-time authorization rate data — without rewriting your checkout integration. If one processor returns a soft decline or goes offline, Tagada automatically retries through a secondary processor within the same authorization window, recovering revenue that would otherwise be lost. This is especially valuable for merchants operating across multiple markets where local acquiring relationships significantly improve authorization rates.
Tagada also normalizes the data models and webhook formats across processors, so your engineering team handles one integration schema regardless of how many processors sit underneath. Reconciliation reports aggregate settlement data across all connected processors into a single ledger view, eliminating the manual work of cross-referencing multiple processor dashboards.