Businesses comparing payment providers often encounter the terms “payment gateway” and “payment processor.” The terms describe different functions in the payment chain, but providers do not always use them the same way. Many platforms bundle gateway, processing, and other services, so a merchant may work with one provider while several distinct functions operate behind the scenes.
In general, a payment gateway handles the secure collection and transmission of payment information from the customer-facing experience. Payment-processing infrastructure helps route authorization messages among the merchant’s acquiring environment, card networks, and issuing banks, and supports clearing and settlement. The issuing bank makes the approval or decline decision; settlement involves the relevant payment participants under the merchant’s arrangement.
Online card acceptance generally requires both payment acceptance or gateway functionality and processing or acquiring functionality. A single provider may deliver several of these services under one agreement. Understanding the roles can help a business assess its checkout, costs, reporting, and operational needs without assuming that each function comes from a separate company.
What Is a Payment Gateway?
A payment gateway generally provides a connection between a customer-facing payment experience and the systems that process a transaction. It may be part of a hosted payment page, an embedded checkout, a mobile application, a virtual terminal, or a payment link. The exact flow depends on the provider and implementation.
Gateway or payment-platform capabilities may include the following:
- Capturing payment details. Customers may enter card, wallet, or other payment information through a hosted page, embedded form, mobile software development kit (SDK), virtual terminal, or payment link. Which methods are available depends on the platform and merchant setup.
- Protecting payment data. Depending on the implementation, provider-hosted fields, tokenization, and encryption can help reduce a merchant’s direct handling of raw card data. Certain implementations may reduce PCI DSS scope when applicable eligibility requirements are met. Merchants should confirm the relevant requirements with their provider and qualified compliance adviser.
- Transmitting payment information and returning a response. Gateway functionality typically sends payment data or a tokenized request into the processing environment and makes the resulting status available to the customer-facing experience. The gateway primarily facilitates payment-data capture and transmission rather than acting as the financial institution responsible for settling funds.
Common gateway touchpoints include hosted payment pages, embedded checkout components, mobile payment flows, virtual terminals, payment links, and stored-credential experiences for recurring transactions. Support for wallets, bank payments, multiple currencies, or local payment methods varies by provider, region, and implementation.
Security and risk capabilities also vary. A gateway or payment platform may support tokenization, 3D Secure, address verification (AVS), card security code checks, device signals, or velocity rules. These capabilities may be provided by the gateway, a processor or acquirer, a network service, a third party, or a combination. PCI DSS responsibilities depend on each organization’s role and how payment data moves through the environment.
Provider names do not always map to a single role. Companies such as Stripe, Adyen, PayPal, Braintree, Authorize.Net, and NMI offer different combinations of payment services, which may vary by product, market, and merchant configuration.
What Is a Payment Processor?
A payment processor facilitates transaction messaging and processing between the merchant’s acquiring environment, card networks, and issuing banks. The processor is one part of a broader arrangement that may include a gateway, payment service provider (PSP), acquirer, card network, issuer, and other service providers.
Its role may include helping with these stages:
- Receiving and preparing a transaction message. In an online flow, the processor may receive a request from gateway or platform functionality. In a card-present flow, the request may come through a terminal or point-of-sale system. The details depend on the setup.
- Routing for an authorization decision. The processor helps transmit the request through the relevant network and acquiring environment to the customer’s issuing bank. The issuer evaluates the transaction and returns an approval or decline response; the processor does not make that decision on its own.
- Supporting clearing and settlement. After authorization, the processor, card network, acquirer, and other applicable participants support clearing and settlement according to the payment arrangement. Funding schedules vary by provider, acquirer, payment type, transaction, and business day. The time before funds are available should be confirmed with the provider.
- Related services may also be included, such as reporting, reconciliation files, dispute workflows, risk tools, or payout information. These services are not exclusive to processors and may be provided by a PSP, acquirer, gateway, network, or separate vendor.
- Processing infrastructure supports card-present and card-not-present payments. A retail terminal, online checkout, invoice link, call-center tool, or mobile application can each connect to the payment environment through a different technical path.
- For an in-person transaction, a terminal or point-of-sale system can capture payment details and connect to processing services without a separate online checkout gateway. Many providers combine terminal, gateway, processing, and acquiring-related services, so the merchant-facing product may not reveal every underlying role.
- PCI DSS obligations and other legal or regulatory responsibilities depend on the organization’s role, services, jurisdiction, and payment arrangement. Merchant underwriting, know-your-customer (KYC), and anti-money-laundering (AML) duties likewise vary; they should not be attributed to every processor in the same way.
Payment Gateway vs Payment Processor: How They Compare
The comparison below describes common functions, not fixed boundaries. A provider may combine roles or assign particular features to another part of the payment environment. Review the actual product, contract, and data flow when evaluating a solution.
Summary Comparison Table
| Factor | Payment Gateway | Payment Processor |
| General role | Supports secure capture and transmission of payment information | Supports transaction messaging and processing within the acquiring and payment environment |
| Customer visibility | May be part of a hosted page, embedded checkout, terminal, or payment link | Often operates behind the payment experience; visibility depends on provider and setup |
| Where used | Common in online and other remote payment flows; exact architecture varies | Supports card transaction processing across online and in-person channels |
| Who provides it | A gateway provider, PSP, acquirer, processor, or combined platform may supply this function | A processor, acquirer, PSP, or combined provider may supply this function |
| Possible costs | Platform, gateway, transaction, or other contract-specific charges | Processor/acquirer markup and other contract-specific charges; network and interchange costs may also apply |
Gateway configuration can influence checkout experience, payment-method availability, fraud controls, and transaction-data quality. Processor and acquiring configuration can influence pricing, routing, authorization performance, settlement, and reporting. Actual outcomes depend on the broader payment environment.
Factor 1: What Happens in a Payment Transaction?
A transaction involves several organizations and systems. Knowing which party handles each step can help teams investigate a decline, an incomplete payment, or a settlement question. The outline below shows a common online card flow; individual implementations may differ.
A typical online card payment may move through these steps:
- The customer enters card or wallet details through a checkout experience. Gateway or platform functionality captures or securely references the payment information.
- Depending on the implementation, data may be encrypted or tokenized, and risk checks may be applied by the gateway, PSP, processor, acquirer, network, or a third-party provider.
- The payment request is sent into the processing and acquiring environment.
- The processor helps route the authorization message through the relevant card network and acquiring path to the customer’s issuing bank.
- The issuing bank evaluates the transaction and returns an approval or decline. The response travels back through the payment environment.
- The result is returned to the checkout experience so the customer and merchant can see the transaction status.
- For an approved transaction, the processor, network, acquirer, and other applicable participants support clearing and settlement. Fees and the timing of funds availability depend on the payment arrangement and applicable terms.
| Step | What happens | Participants that may be involved |
| 1 | Customer enters card or wallet information through a checkout or terminal. | Checkout, gateway, or point-of-sale functionality |
| 2 | Payment data is protected or referenced according to the implementation; risk checks may run. | Gateway, PSP, processor, acquirer, network, or third party |
| 3 | The payment request enters the processing and acquiring environment. | PSP, gateway, processor, or acquirer |
| 4 | The authorization message is routed toward the customer’s issuing bank. | Processor, card network, and acquiring environment |
| 5 | The issuing bank approves or declines and returns a response. | Issuing bank and payment network |
| 6 | The transaction status returns to the customer-facing experience and merchant systems. | Payment participants and checkout or platform |
| 7 | Approved transactions proceed through clearing and settlement under the applicable arrangement. | Processor, card network, acquirer, and other relevant participants |
Transaction Flow Responsibilities Table
For online card payments, gateway and processing functions are both generally present, even when a single provider supplies them. The useful question is how the overall setup supports the business’s payment experience, risk controls, reporting, and operating requirements.
Factor 2: Online vs In-Person Payments
The payment channel affects what a business and its customers interact with, but the underlying responsibilities can overlap. The provider’s architecture and product design determine where particular functions sit.
Online and remote payments. E-commerce stores, subscription businesses, software platforms, and marketplaces use a checkout or payment interface connected to processing and acquiring services. The customer-facing experience can affect usability, payment-method availability, authentication, and the information passed into the payment flow. Processing and acquiring arrangements also affect routing, fees, reporting, and settlement. No single feature guarantees higher conversion or fewer abandoned carts.
In-person payments. Retailers, restaurants, and field-service businesses commonly use a terminal or point-of-sale system to capture card or wallet details and send the request into the payment environment. Encryption and other safeguards depend on the terminal and implementation. Merchants may be able to discuss provider-controlled markups, service fees, or terminal costs with a provider or acquirer. Card-network interchange programs are established by the networks and are not individually negotiated by merchants.
Other payment channels include:
- Virtual terminals and keyed-entry tools can support payments initiated by phone, subject to the provider’s security requirements and merchant procedures.
- QR-code payments and tap-to-pay on a phone may use different architectures. Ask the provider how the payment is captured, routed, secured, and reported.
How to think about the two functions:
- For online payments, review the checkout flow, supported methods, customer authentication, and data handling alongside the related processing arrangement.
- For in-person or omnichannel payments, review terminal coverage, reporting, routing, support, settlement arrangements, and how online and in-store transactions fit into existing operations.
Factor 3: Pricing and Fee Structures
Gateway and processing costs vary significantly by provider and commercial arrangement. A business may see monthly gateway or platform fees, per-transaction charges, processor or acquirer markup, network assessments, interchange, cross-border or foreign-exchange fees, dispute fees, and other provider-specific charges. When gateway and processing functions are bundled, these costs may appear within one pricing structure rather than as separate line items.
The same type of fee may be included, itemized, or charged by different parties depending on the contract. A standalone gateway may have its own platform charges, while a PSP or acquiring arrangement may combine several services in a single statement. Review the full pricing schedule and ask how fees apply to the business’s payment methods, transaction types, regions, refunds, and disputes.
A cost comparison should account for the whole arrangement, not just a quoted rate. Network interchange programs are set by the card networks. Depending on the setup, businesses may be able to evaluate qualification, routing, processor or acquirer markup, and other provider-controlled costs.
Possible Cost Structures Table
| Possible cost item | Gateway, platform, or bundled arrangement | Processing, acquiring, network, or other charges |
| Platform or gateway charges | May be monthly, annual, per-transaction, bundled, or absent as a separate line item | May be included in a bundled rate or billed separately under the contract |
| Processing or acquiring markup | May be included in a combined pricing structure | May be quoted as a markup or within a blended price |
| Interchange and network assessments | May appear in an itemized statement or bundled pricing | Depend on network programs, transaction details, and payment method |
| Cross-border or currency costs | May apply based on transaction location, currency, provider, and arrangement | May apply based on transaction location, currency, provider, and arrangement |
| Disputes, refunds, or other services | Fees and responsibility vary by provider and contract | Fees and responsibility vary by provider and contract |
| Billing relationship | One provider may invoice for several services | Multiple vendors may bill separately |
Use the table as a checklist of possible charges, not as a rule about which provider always bills them. The contract and statement determine where each item appears.
Bundled pricing can make it easier to work with one provider and review a consolidated statement, although businesses should still understand what each charge covers and how it may change.
A separate gateway and processing arrangement may provide more provider choice or cost visibility for some businesses. It can also add contracts, integration work, reconciliation steps, and support coordination. The expected benefit should be weighed against those operational costs.
Factor 4: Integration, Control, and Customization
Technology requirements matter when payments are part of a software product, marketplace, or complex operating workflow. Features may be supplied by a gateway, PSP, processor or acquirer, orchestration platform, network service, or a combination of providers.
When reviewing an integration, consider:
Checkout tools and developer support. Compare hosted pages, embedded components, mobile libraries, APIs, documentation, and the level of control the business needs over the customer experience.
Payment and account workflows. Ask whether the solution supports the required custom fields, recurring billing, stored credentials, refunds, payment links, and relevant customer authentication. Availability and implementation details differ across providers.
Events and system connections. Webhooks or other notifications may help connect payment status with order management, invoicing, customer support, or accounting systems. Confirm what events are available and how they are delivered.
Operational and processing needs:
- Reporting and reconciliation. Review the available transaction, settlement, payout, and decline information, and check how it can be exported or connected to existing systems.
- Regional and currency support. Confirm acquiring availability, supported payment methods, settlement currencies, and any limits that apply in each market.
- Routing, retries, tokens, and fraud tools. These capabilities may come from the PSP, processor, acquirer, network, gateway, or orchestration layer. Ask who controls them, what data they use, and what configuration is available.
One Razorpay-affiliated production study reported a 4%–6% improvement in payment success rate from its smart-routing system across the payment methods studied. That result reflects a specific implementation and should not be treated as an expected authorization-rate improvement for other businesses.
The teams involved may experience different parts of the setup. Product and engineering teams often focus on checkout and integration work; finance and operations teams may focus on settlement information, fee visibility, reconciliation, and support. Those concerns can span multiple providers.
Factor 5: Security, Compliance, and Fraud Management
Security and compliance responsibilities depend on provider role, payment architecture, data flows, contracts, and applicable rules. Gateway and processing services may each have obligations, but neither label alone tells a merchant exactly who is responsible for a particular control.
Questions for the gateway or payment platform:
Find out whether card data is entered into provider-hosted fields, transmitted through merchant-controlled systems, or handled through another method. Ask how tokenization and encryption work in the actual implementation and what PCI DSS validation applies to the merchant.
Ask which services are available for customer authentication, such as 3D Secure where relevant, and for risk screening, such as address or card-security checks. Confirm which party provides each feature and who configures it.
Questions for the processing and acquiring arrangement:
Ask how authorization messages are routed, what transaction and decline information is available, and which parties provide any network or risk services.
Clarify who manages disputes, retrieval requests, merchant underwriting, KYC or AML procedures, and required reporting under the specific agreement and jurisdiction.
Responsibility should be documented across the complete payment environment. A bundled provider may simplify communication, but it does not automatically remove the merchant’s own PCI DSS or security responsibilities. Merchants should confirm their validation requirements, secure accounts and integrations, configure available controls, and understand the roles of any vendors that handle payment data.
Payment Gateway vs Payment Processor: Which Matters More for Different Business Models?
The right questions depend on the business’s channels, transaction mix, markets, existing systems, risk profile, and internal resources. The table offers prompts for discussion rather than assigning every business to a fixed gateway or processor model.
Business Model Comparison Table
| Business context | Questions to ask about payment experience | Questions to ask about processing and operations |
| Online store | Which checkout formats, payment methods, mobile experiences, and authentication options are supported? | What transaction detail, fee information, routing options, and settlement reporting are available? |
| Subscription software | How are recurring credentials, customer authentication, failed payments, and account updates supported? | Which regions, currencies, decline details, and reporting workflows fit the service? |
| Omnichannel retailer | Can customer-facing online and in-person experiences support the business’s desired workflows? | How do terminal and online transactions appear in reporting and reconciliation? |
| B2B invoicing platform | Are payment links, embedded options, bank payments, or invoice workflows supported? | How are transaction costs, settlement terms, and reconciliation handled? |
| Marketplace or platform | What seller onboarding and payment flows are available? | How are fund flows, disputes, reporting, and provider responsibilities structured? |
Use these examples to identify which requirements to test during provider selection:
Online businesses can examine checkout usability, mobile performance, supported payment methods, authentication, decline reporting, and the relationship between checkout design and the payment flow. Test the actual experience rather than assuming a particular gateway design will reduce abandonment.
B2B payment programs should review invoice workflows, payment methods, transaction-level costs, approval and decline reporting, reconciliation, and settlement terms. For larger payments, understand how percentage-based charges, fixed charges, and any applicable limits affect the total cost.
Marketplaces and platforms should clarify seller onboarding, fund flows, dispute responsibilities, reporting, and any legal or compliance obligations that apply to their role. These requirements depend on the business model, provider arrangement, and jurisdiction.
Should You Bundle Your Payment Gateway and Processor or Keep Them Separate?
Some businesses use a PSP that combines checkout, gateway, processing, and related services under one relationship. Others choose a gateway or platform and connect it with separate processors or acquirers. The terminology and division of services vary, so compare the actual functions and contract terms.
Bundled payment service providers may offer several functions through a single platform or agreement. The specific services, acquiring model, and supported payment flows vary by provider and market.
A separate arrangement can connect a gateway or orchestration platform with one or more processors or acquirers, where the technology and contracts support that design.
Potential benefits of a bundled arrangement:
- Fewer integrations or commercial relationships may simplify implementation, support, billing, or reporting, depending on the provider.
- A ready-made checkout or platform integration may help a business launch without building every payment component itself.
- Working through a single support channel may simplify issue escalation, though the merchant should understand which teams handle particular problems.
Potential reasons to consider separate providers:
- Provider choice may support regional acquiring or routing options when those are available and justified by the business’s needs.
- Separate contracts may make it easier to review provider-controlled fees or select services for different markets, but network interchange itself is not negotiated by merchants.
- A multi-provider design may offer alternatives during a service disruption if failover is supported and tested. Results depend on the implementation and can introduce added technical and operational work.
Bundled vs Separate Setup Comparison Table
| Setup type | May suit a business that needs | Potential advantages | Trade-offs to assess |
| Bundled platform | A consolidated provider relationship or a ready-made payment flow | May reduce the number of integrations, contracts, or support channels | Review bundled fees, functionality, data access, and limits on provider choice |
| Gateway with one processor or acquirer | A specific checkout experience with a separate processing relationship | May offer choice in providers or clearer separation of functions | Requires coordination across contracts, support, integration, and reconciliation |
| Gateway or orchestration with multiple processors/acquirers | Routing choice, regional options, or contingency planning supported by the business case | May offer flexibility where integrations and contracts support it | Adds technical oversight, operational monitoring, reporting, and contract complexity |
There is no universal revenue threshold for separating gateway and processing relationships or adopting orchestration. Businesses should consider a more complex arrangement when the expected benefits from routing flexibility, regional acquiring, redundancy, cost visibility, or provider choice justify the added technical and operational effort. The decision should account for payment volume, geography, payment methods, existing systems, authorization performance, reporting needs, contract structure, and internal resources.
The comparison table summarizes trade-offs to investigate. A setup that works for one organization may not fit another with different payment channels, systems, staffing, or provider terms.
Payment Gateway vs Payment Processor: Which Should You Focus on First?
Most businesses need both payment acceptance and processing functions for online card payments, but they may not need to manage them as separate products. Start by identifying the problem the business is trying to solve, then determine which part of the overall payment environment can address it.
Review gateway or checkout functionality first if the business needs to improve how customers pay, add a specific payment method, support a new channel, or connect checkout with its website or application. Test usability and accessibility with the actual customer journey.
Review processing and acquiring arrangements if the business needs clearer fee information, different regional coverage, more useful authorization data, a change in settlement terms, or a better fit with its reconciliation process. Ask which elements are provider-controlled and which depend on the network, issuer, or other participant.
For either path, check integration effort, fraud and authentication tools, data access, reliability commitments, support, contractual terms, and the responsibilities that remain with the merchant. The best fit is the arrangement that meets the business’s needs without adding complexity that it cannot support.
How PayTech Trust Helps Businesses Evaluate Payment Infrastructure
PayTech Trust helps businesses evaluate payment gateways, processing environments, hosted payments, ERP and business-system integrations, reporting, payment-cost visibility, and other payment workflows. The right combination of gateway, processor or acquirer, and supporting technology depends on existing systems, transaction mix, payment channels, operational requirements, and selected providers. Available capabilities vary by processor, gateway, integration, and implementation scope. Explore Enterprise Payment Environments & Integrations and Payment Cost Optimization & Interchange Review to learn more.
Frequently Asked Questions About Payment Gateways and Payment Processors
These answers explain common payment terms, but a provider’s product descriptions and contract should guide decisions about a specific setup.
Can I Accept Online Payments With Only a Payment Processor and No Payment Gateway?
Online card acceptance generally needs both payment acceptance or gateway functionality and processing or acquiring functionality. A provider may bundle those functions into a hosted checkout, API, or broader PSP service, so the merchant may work with one company. A card-present setup may use a terminal or point-of-sale system to capture payment information without a separate online checkout gateway.
Can I Use One Payment Gateway With Multiple Processors?
Some gateways and orchestration platforms can connect with multiple processors or acquirers. Depending on the architecture, this may support provider choice, routing alternatives, or continuity planning. Any effects on cost or payment success are implementation-specific; the Razorpay study discussed above describes one particular production system, not a general expected result. Multi-provider setups also require careful integration, monitoring, reconciliation, and contract management.
How Does a Merchant Account Fit Into the Payment Arrangement?
A merchant account is part of the acquiring arrangement that enables a business to accept card payments and receive settlement under the applicable terms. The account structure and fund flow can differ across providers; some PSP arrangements aggregate merchants or use other models. Ask the provider how funds are held, reported, and paid out in the specific setup.
How Do Security Responsibilities Differ Across Providers?
Responsibilities depend on the providers’ roles, the payment architecture, data flows, and applicable requirements. Gateway, PSP, processor, acquirer, network, and third-party services may each provide or support different controls. Merchants should confirm their PCI DSS validation requirements, identify who handles each service, protect access to their systems, and document the controls they are expected to manage.
What Should I Ask Vendors When Comparing Payment Solutions?
Questions to consider during evaluation include:
- Which countries, currencies, and payment methods are supported for the intended business model?
- How are transactions routed, and what approval, decline, retry, and fallback information can the business review?
- What charges may apply, including platform fees, transaction fees, processor or acquirer markup, network assessments, interchange, cross-border or foreign-exchange charges, refunds, and disputes?
- What APIs, SDKs, integrations, documentation, and technical support are available?
- Which fraud, authentication, tokenization, and PCI DSS scope-reduction capabilities are supported, and which party provides each one?
- What service commitments cover uptime, incident response, support, reporting, and the timing of settlement or payouts?
