How Payment Processing Works
Payment processing is not a single action — it is a coordinated sequence involving the customer, the merchant, and at least four distinct financial entities. Understanding each step helps merchants diagnose failures, reduce costs, and improve conversion rates.
Customer Initiates Payment
The customer enters card details at a checkout page, taps a contactless terminal, or initiates a wallet payment. The payment gateway encrypts the card data and sends it securely to the payment processor.
Authorization Request
The payment processor routes the transaction to the relevant card network (Visa, Mastercard, Amex, etc.), which forwards it to the customer's issuing bank. The issuing bank checks for available funds, fraud signals, and account standing, then returns an approval or decline code — typically within 1–3 seconds.
Authentication (When Required)
For online transactions subject to 3D Secure or strong customer authentication (SCA), an additional step verifies the cardholder's identity via a one-time password, biometric, or risk-based exemption. This reduces fraud liability and chargeback exposure for the merchant.
Capture
Once authorized, the merchant captures the funds — either immediately (common for ecommerce) or later (common for hotels and marketplaces). Authorization holds expire if not captured, typically within 7 days.
Clearing
At end of day, the merchant's acquirer batches captured transactions and submits them through the card network for clearing. The card network calculates net positions between issuing and acquiring banks.
Settlement
The issuing bank transfers funds through the card network to the acquiring bank, which then deposits the net amount — minus interchange and processing fees — into the merchant's account. Settlement typically completes within 1–3 business days.
Why Payment Processing Matters
Payment processing infrastructure directly impacts revenue, customer experience, and operational cost. Inefficiencies at any stage — a misconfigured gateway, a processor with poor issuer relationships, or a rigid retry logic — translate into lost sales and higher costs.
According to Visa, global digital payments exceeded $10 trillion in annual volume in 2024, with card-not-present (CNP) transactions growing faster than any other segment. For ecommerce businesses, the average checkout conversion rate is approximately 68% — but declined transactions account for a significant share of abandoned carts, with industry data suggesting that up to 15% of legitimate transactions are declined due to false positives from issuer fraud models.
Processing fees are also material: interchange fees alone represent the largest cost component for most merchants, often accounting for 70–80% of total processing costs. A 0.1% reduction in effective rate on $10M annual volume is $10,000 in direct margin — making processor selection and fee negotiation a meaningful business lever.
Cost Benchmarks
Average ecommerce processing cost: 1.8%–3.5% per transaction. High-risk merchants or those on flat-rate plans may pay 2.9% + $0.30 or more. Interchange-plus pricing is generally more transparent and cost-effective at scale.
Payment Processing vs. Payment Orchestration
While payment processing handles the execution of individual transactions, payment orchestration manages the strategy layer above it — routing, fallback, and optimization across multiple processors. The two are complementary, not interchangeable.
| Dimension | Payment Processing | Payment Orchestration |
|---|---|---|
| Primary function | Execute a single transaction | Route and optimize across processors |
| Scope | One processor, one acquirer | Multiple processors, gateways, acquirers |
| Authorization rate control | Limited (set by issuer/network) | High — smart routing improves approvals |
| Failover | None built-in | Automatic retry on alternate processor |
| Cost optimization | Fixed by processor pricing | Dynamic — route to cheapest path |
| Integration complexity | Single API | Single API to multiple backends |
| Who manages it | Processor | Merchant or orchestration platform |
Types of Payment Processing
Payment processing varies significantly by channel, transaction type, and the technology stack involved. Merchants typically deal with multiple variants simultaneously.
Card-Present Processing occurs at physical terminals. Transactions use EMV chip or NFC contactless data, which carries lower interchange rates and fraud liability than card-not-present. Terminals communicate with the processor via direct IP or HTTPS.
Card-Not-Present (CNP) Processing covers ecommerce and MOTO (mail order/telephone order) transactions. CNP carries higher interchange rates and greater chargeback risk because the physical card is not verified. Strong authentication mechanisms like 3DS2 help mitigate this.
Recurring and Subscription Processing uses stored merchant account credentials (tokens) to initiate subsequent charges without the cardholder re-entering data. Network tokenization (Visa Token Service, Mastercard MDES) improves authorization rates for recurring billing by keeping tokens updated even when physical cards are replaced.
Real-Time Payments (RTP) bypass card networks entirely, moving funds via bank-to-bank rails (e.g., FedNow, SEPA Instant). These are instant and irrevocable but require the customer to have a connected bank account rather than a card.
Wallet and Alternative Payment Methods (APMs) route through intermediary wallets (Apple Pay, Google Pay, PayPal) or local payment methods (iDEAL, Pix, Alipay). Each has its own processing flow but often settles through the same acquiring infrastructure.
Best Practices
Every stakeholder in the payment flow has different optimization levers. Below are targeted recommendations.
For Merchants
- Negotiate interchange-plus pricing once monthly volume exceeds $50K. Flat-rate pricing is convenient early on but expensive at scale.
- Enable network tokenization for recurring billing. Visa and Mastercard token services automatically update expired or replaced card details, reducing involuntary churn.
- Monitor authorization rates by BIN and country. A sudden drop in approvals from a specific issuing bank signals a routing or fraud-model issue worth escalating to your processor.
- Use 3DS2 with risk-based exemptions rather than blanket SCA challenges. Unnecessary friction at checkout reduces conversion; exemptions for low-risk transactions preserve the customer experience while maintaining compliance.
- Set up retry logic for soft declines. Many legitimate declines (e.g., "insufficient funds" on a prepaid card) succeed on a second attempt hours later.
For Developers
- Always use idempotency keys when submitting authorization or capture requests. Network timeouts can cause duplicate charges if the same request is submitted twice without a deduplication key.
- Handle all decline codes explicitly. Do not treat all failures as generic errors — surface card-specific messages (e.g., "card expired") to users and route non-retryable declines away from retry flows.
- Implement webhook verification. Payment processors send async notifications for authorization updates, disputes, and refunds. Verify webhook signatures and process events idempotently.
- Scope PCI DSS exposure. Use hosted fields or a payment element to keep raw card data off your servers. This reduces PCI scope from SAQ D to SAQ A or SAQ A-EP.
- Test with real BIN ranges in sandbox. Many processors provide test card numbers that simulate specific issuer responses (approve, decline, 3DS required) — use them to validate edge-case handling before go-live.
Common Mistakes
Even experienced payment teams make avoidable errors that directly cost revenue or create compliance risk.
1. Ignoring authorization rate optimization. Many merchants track successful payments but not declined attempts. A 5% authorization rate improvement on high-volume traffic is significant; without measuring declines, merchants have no baseline to optimize against.
2. Over-challenging with 3DS. Applying 3DS to every transaction — rather than using risk-based exemptions — adds friction that reduces conversion, particularly on mobile. Under PSD2, many low-value transactions qualify for TRA (Transaction Risk Analysis) exemptions.
3. Single processor dependency. Relying on a single payment processor creates a single point of failure. Processor outages, regional routing issues, or sudden account terminations can halt revenue with no fallback. Redundant processing architecture mitigates this risk.
4. Mismanaging interchange fees. Merchants on tiered pricing often have no visibility into actual interchange categories being applied. Transactions may be downgraded to higher-cost tiers due to missing data fields (e.g., no AVS data, missing level 2/3 fields for B2B cards).
5. Confusing authorization hold with capture. Authorizing a transaction reserves funds but does not move them. Failing to capture within the authorization window (typically 7 days) results in an expired hold, requiring re-authorization — and potentially annoying the customer with duplicate pending charges.
Payment Processing and Tagada
Payment processing is the foundational layer that Tagada is built to optimize. Tagada acts as a payment orchestration layer above multiple processors and acquirers, giving merchants a single integration point while enabling dynamic routing, automatic failover, and cost optimization across the entire processing stack.
How Tagada Improves Processing Outcomes
Rather than being locked into a single processor's authorization rates and pricing, merchants using Tagada can route each transaction to the processor most likely to approve it — based on BIN, currency, amount, and historical performance. This typically improves authorization rates by 2–8% and reduces effective processing costs through intelligent acquirer selection. Tagada is not a bank or payment processor — it orchestrates the processors you already use or want to add.