01
Simple
For straightforward payment needs.
- One processor
- One merchant account
- One gateway
Payment Architecture
The pieces matter. How they fit matters more.
We review how your payment providers, systems, and tools work together—and where the connections create friction.
We look at the payment environment as a system.
Follow the transaction
The problem shows up here.The cause may be somewhere else.
A checkout issue can begin several systems away. Trace the connections to understand where friction starts.
Customer experience
01Customer
- 02
Website / App / POS
- SYMPTOM SEEN HERE03
Checkout
Payment infrastructure
04Gateway / Payment Layer
- 05
Routing / Orchestration
- 06
Merchant Account / MID
Banking & network
POSSIBLE SOURCE · EXAMPLE07Processor / Acquirer
- 08
Card Network
- 09
Issuer
Follow the transaction. Find the friction.
Where it appears
A problem at checkout.
The customer sees the interruption at the point of payment.
Where we investigate
Across the connected environment.
Review the response and connected systems before choosing what to change.
See the supporting layersFraud · Authentication · Tokenization · Recurring billing · Account updater · Chargebacks · Reporting · Data
- Fraud
- Risk controls can affect customer friction and whether a transaction proceeds.
- 3DS / Authentication
- Authentication adds a cardholder-verification step to the payment experience.
- Tokenization
- Stored payment credentials can tie billing and portability to a gateway or processor.
- Recurring Billing
- Billing logic and stored credentials influence how repeat payments move through the stack.
- Account Updater
- Updater support can help maintain stored payment credentials for recurring billing.
- Chargebacks
- Disputes connect payment records with customer history, fulfillment and descriptor clarity.
- Reporting
- Exports and provider reports help compare fees, declines and routing behavior.
- Data
- Transaction records help trace connections and identify where friction may begin.
Illustrative transaction path—not a diagnosis. Actual configurations vary.
Built around your business
The right architecturefits your business.
Different needs call for different levels of complexity.
02
Growing
For expanding channels and billing needs.
- Multiple channels
- Recurring billing
- Connected tools
03
Complex
For specialized routing, risk, and resilience.
- Multiple processors & MIDs
- Routing & orchestration
- Specialized requirements
Compare the details
Simple Environment
Single processor. Single merchant account. Single gateway. Appropriate when the business has straightforward payment needs.
- Single processor
- Single merchant account
- Single gateway
Growing Environment
Multiple channels, recurring billing, fraud tools and additional merchant accounts. Complexity increases as channels, billing models and reporting needs expand.
- Multiple channels
- Recurring billing
- Fraud tools
- Additional merchant accounts
- More reporting requirements
Complex Environment
Multiple processors, multiple MIDs, routing, orchestration, international markets, specialized risk requirements and redundancy. Justified when scale, risk or operational requirements demand it.
- Multiple processors
- Multiple MIDs
- Routing
- Orchestration
- International markets
- Specialized risk requirements
- Redundancy
- More complex reporting
- Justified when scale, risk or operational requirements demand it.
More infrastructure is only useful when it solves a real business problem.
Illustrative setups. The right configuration depends on your business.
Designed to solve something
Architecture should have a reason.
Start with the business problem. Then review the payment setup behind it.
01Outages
01 / Outages
When one connection stops everything.
What’s happening
One ecommerce store relies on a single gateway and merchant account. A processor or gateway outage can stop checkout.
What we’d review
Whether a compatible backup payment path or secondary provider makes sense for critical traffic. Availability depends on approved relationships and technical compatibility; failover is not guaranteed.
02Approval differences
02 / Approval differences
The same customers. Different approval patterns.
What’s happening
A subscription merchant sees stronger rebill approval performance on one processor than another, even with the same customer base.
What we’d review
Merchant-account setup, processor differences, routing logic, and transaction type by channel. Review the differences before considering a change; approval improvement is not guaranteed.
03Recurring billing
03 / Recurring billing
Changing providers without losing the billing picture.
What’s happening
A business wants to move providers, but recurring subscribers depend on stored credentials, token portability, and account updater support.
What we’d review
Tokens, updater services, billing logic, and merchant-account structure before making changes. Stored credentials may not be portable; provider cooperation, contracts, and technical compatibility matter.
04Specialized businesses
04 / Specialized businesses
A business model with different requirements.
What’s happening
A high-risk or specialized merchant may need a setup that matches underwriting expectations, fraud controls, and processor capabilities from the start.
What we’d review
How the architecture aligns with processor capabilities, underwriting, and operational requirements. Any proposed setup remains subject to provider approval.
05Multiple brands
05 / Multiple brands
Different brands need a clear payment structure.
What’s happening
A merchant operates multiple brands or websites, but merchant accounts and checkout flows are not clearly aligned with those business entities.
What we’d review
How merchant accounts, routing, and payment flows match the correct brands, websites, and entities, within processor and underwriting requirements.
06Reporting
06 / Reporting
Deposits alone do not show the whole system.
What’s happening
The merchant sees deposits, but lacks detail across gateway fees, decline patterns, routing behavior, or processor reporting.
What we’d review
Exports, reporting, and unified analytics that could make the payment environment easier to understand as a system, based on available source data.
The right structure for the business
One merchant account is not always the right answer.
Some businesses benefit from separate accounts. Others benefit from keeping things simple.
Straightforward needs
The market stand
One merchant account
A simple setup can suit a single-location business with straightforward payment needs.
More demanding operations
The online operation
Multiple accounts, when justified
Separate accounts may help with operational separation, processor diversity, or resilience.
Backup paths depend on compatibility and provider approval.
When separate accounts may helpBrands · Websites · Entities · Transaction types · More
For some businesses, separate merchant accounts may support operational separation, additional capacity, processor diversity, or clearer performance analysis. For others, they add unnecessary complexity. Online selling or volume alone does not require extra accounts.
- Brand
- Website
- Business entity
- Transaction type
- Geography
- Processor
- Risk profile
- Volume and redundancy needs
Account structure must follow processor, acquirer, card-network, and underwriting requirements.
Redundancy should solve a meaningful risk—not create complexity for its own sake.
Illustrative business examples.
Routing with a purpose
Every payment path should have a purpose.
Orchestration applies business rules to eligible payment paths. The right setup depends on your operations and provider relationships.
Illustrative example
Transaction
Subscription payment
- Type
- Recurring
- Currency
- USD
- Channel
- Online
Routing rule
Apply business rules
Recurring payment
Use the configured eligible MID
Check eligibility and availability
Processor destinations
Processor A
Configured recurring MID
Processor B
Other eligible path
Processor C
Other eligible path
This example sends a recurring payment to its configured eligible account.
Route: Subscription payment → Recurring payment → Processor A · Configured recurring MID.
What can influence routingPerformance · Availability · Geography · Transaction type · Business rules
Payment orchestration can give larger or more complex merchants greater control over where eligible transactions are sent. That control may support resilience, processor flexibility, performance analysis or operational requirements.
- Approval performance
- Processor availability / failover
- Geography or currency
- Transaction type (subscription/high-ticket)
- MID allocation / business rules
- Performance measurement
Routing should be driven by legitimate business and payment-performance objectives. Alternative paths depend on eligibility, compatibility and provider approval; routing does not guarantee approvals or uninterrupted service.
Routing should serve a clear business objective.
Explore Payment OrchestrationIllustrative routing only. Eligibility, compatibility, and provider approvals determine available paths.
Stored payments. Future flexibility.
Your payment data shapes your freedom to move.
Stored credentials keep subscription businesses running. How they are held can affect your options when changing providers.
Illustrative business
A coffee subscription brand
Recurring orders. Stored payment credentials. A possible provider change.
Provider dependency
Tied to one provider
Changing providers may be harder when credentials and billing depend on one provider’s systems.
Transfer planning
Transfer options planned
Review export options, provider cooperation, and compatibility before committing to a switch.
What to check before switchingTokens · Export options · Billing logic · Account updaterTokens · Export options · Billing logic · Account updater
- Gateway tokens and stored credentials
- Recurring and ecommerce merchants often depend on stored credentials. Gateway tokens reference those credentials within the systems that hold them.
- Vault and provider dependencies
- Credentials held in a provider’s vault, and billing tied to its systems, can make a provider change more difficult.
- Token export and migration
- Check whether export or migration is available, what the contracts permit, and what approvals and secure transfer processes are required.
- Network tokens
- Network tokens are not inherently portable. Confirm whether the participating providers support the intended use or transfer.
- Recurring billing logic
- Review billing schedules, subscription records and retry logic alongside credentials. Credential transfer alone does not move the billing setup or guarantee uninterrupted billing.
- Account updater
- Confirm how account updater services are supported by the new setup and whether enrollment or updated configuration is needed.
- Provider cooperation and compatibility
- Review cooperation between the current and potential providers, technical compatibility and compliance requirements before planning a switch.
Token exports and migrations are not always available. Feasibility depends on providers, contracts, technical compatibility, and compliance requirements.
Architecture decisions made today can affect flexibility later.
Plan for the interruption
What happens when one part of the stack stops working?
A resilient setup considers where a single failure could interrupt payments—and whether another eligible path can be prepared.
One available path
A single interruption can stop the payment path.
An alternative prepared
Another eligible path may provide an option.
Conceptual illustration
Scroll each illustration to see the complete path.
- Integrations
- Can the systems support another path?
- Underwriting
- Are the required accounts approved?
- Contracts
- What do provider agreements allow?
- Monitoring
- How will an interruption be detected?
Processor or gateway outages, network problems, configuration errors, and account restrictions can create operational risk.
Redundancy does not eliminate risk. It can give the business another path when something fails.
Options depend on integrations, underwriting, contracts, and technology. No architecture guarantees uninterrupted processing or automatic failover.
SEE THE WHOLE TRANSACTION
One payment.Several connected outcomes.
Routing, fraud controls, authentication, and billing can affect more than the approval decision.
ILLUSTRATIVE ORDER
An online purchase
Returning customer · Stored card · Online
- Returning customer
- Stored card
- Online
Approval performance
May decrease
With stricter fraud rules
Some legitimate payments may be declined.
Fraud & authentication
Exposure may decrease
Customer friction may increase
Stronger screening can add checks or customer steps.
Chargeback risk
Still needs review
Product, customer history, fulfillment, and dispute reasons still matter.
WHAT CHANGES WHEN…
Possible effects depend on the customer, rule configuration, and transaction.
A change designed to solve one problem can create another somewhere else.
Illustrative trade-offs. Review actual results across the payment environment.
The payment stack affects more than whether a transaction reaches the processor. Routing, fraud controls, authentication, billing logic, and merchant-account structure can influence approvals, customer friction, and disputes; review these connected considerations together.
TEST BEFORE YOU COMMIT
A new architectureshould prove itself.
When technically and contractually possible, start with a controlled pilot and compare the results before expanding.
Eligible transactions are allocated to one of two parallel paths: main traffic stays in the current environment, while a limited eligible pilot group uses the test environment. A transaction is not sent to both. Evidence from each environment is compared separately before deciding whether to expand, adjust, or revert.
Eligible traffic
Transactions that meet your pilot criteria.
MAIN TRAFFIC
Current environment
Existing setup continues.
LIMITED PILOT
Test environment
New architecture under review.
COMPARE THE EVIDENCE
Review side by side.
The em dashes are placeholders for measured results, not actual values. No results or advantage are implied for either environment.
| Metric | Current | Pilot |
|---|---|---|
| Approval rate | — | — |
| Cost | — | — |
| Reliability | — | — |
| Chargebacks | — | — |
DECIDE FROM THE RESULTS
- Expand
- Adjust
- Revert
Choose the next step based on the evidence.
ILLUSTRATIVE CONTROLLED PILOT
Keep the baseline
Maintain a clear view of the current setup.
Limit the test
Choose an appropriate eligible pilot group.
Review the trade-offs
Assess cost, reliability, approvals, and disputes.
Change should be based on evidence.
Controlled testing depends on technology, processor cooperation, integrations, contracts, and underwriting. It is not always possible.
Merchant Hub — Being Built
Architecture is easier to evaluate when performance is visible.
Merchant Hub is being built to compare performance across processors, merchant accounts, routing paths, costs and other parts of the payment environment.
Explore Merchant Hub →
How Merchant Counselor helps.
Assess
Map the current payment stack, providers, merchant accounts, integrations, transaction flow and pain points.
Advise
Identify architectural weaknesses, unnecessary complexity and areas where different structures may make sense.
Implement
Help coordinate processors, gateways, platforms and technical partners when approved changes are made.
Optimize
Measure performance and continue evaluating the architecture as the business grows.
Does your payment stack feel more complicated than it should?
Tell us how payments move through your business today.
We'll help map the environment, identify where the complexity is coming from and determine whether anything should change.
Review My Payment Architecture
Understand the system before changing the pieces.