Payment processors move payment transactions through the payment ecosystem; however, they are only one part of the process. A payment gateway securely transmits payment information from the merchant’s checkout to the processing infrastructure. Depending on the integration, it may appear as a provider-hosted payment page or operate behind the merchant’s own interface. An acquirer is a regulated financial institution that connects the merchant side of a card transaction to the card networks, supports clearing and settlement, and underwrites merchant risk either directly or through an approved intermediary. A payment aggregator or payment facilitator (PayFac) lets merchants accept payments under its own master merchant account instead of opening their own.
When something goes wrong, knowing which layer failed matters. The checkout page may load correctly while the issuer declines the card, or the processing system may be fully operational while the acquirer refuses to accept the merchant’s MCC.
What Is a Payment Gateway?
A payment gateway securely handles payment requests between the merchant’s checkout and the processing infrastructure. Depending on the integration, it may collect card details through a hosted form or operate behind the merchant’s own interface. It can also support tokenization, 3D Secure, and secure connections to other payment providers.
A simple payment gateway example is a hosted checkout page: a customer enters card details, clicks “Pay,” and the gateway prepares that information so it can be sent for authorization.
A gateway can also offer payment links, recurring billing, saved cards, fraud filters, and reporting. Those features are useful, but a gateway-only provider does not itself underwrite the merchant or provide the underlying acquiring relationship.
Types of Payment Gateway: Hosted, Embedded, and Direct API
There are three common types of payment gateway setups. The main difference is where the customer enters payment data and how much responsibility stays with the merchant.
| Type of payment gateway | How it feels in practice | Best fit | Main tradeoff |
|---|---|---|---|
| Hosted redirect or hosted payment page | The customer pays on a page controlled by the provider | Merchants seeking a fast launch and potentially reduced PCI DSS scope, depending on the implementation | Less control over checkout design |
| Embedded hosted fields or iFrame | The payment form appears inside the merchant checkout | Merchants that care about smoother UX and fewer redirects | More work for developers and more implementation risk |
| Merchant-hosted card-data flow / direct card-data API | The merchant collects payment data and sends it through API | Larger teams with strong engineering and compliance resources | Highest PCI DSS and security responsibility |
For many merchants, a hosted or embedded checkout is enough. A direct API gives more freedom but more responsibility – the more your own systems touch payment data, the more carefully you need to manage PCI DSS scope and data flow.
What Is a Payment Processor?
A payment processor works behind the checkout. Once the gateway has created a payment request, the processor helps move that request through the payment system.
It can be involved in authorization, capture, clearing, settlement, and reconciliation – in plain terms, it sends transaction messages between the merchant side, the acquiring side, the card network and the issuing bank, then brings the response back.
Many providers blur this line: Stripe, for instance, describes itself as bringing together payment-processing, payment-gateway and merchant-account capabilities, while separately explaining how a payment processor differs from a merchant acquirer.
Payment Gateway vs Payment Processor
The easiest way to separate the two is this: the gateway handles the secure payment request, while the processor helps move the transaction through authorization and subsequent processing steps.
| Question | Payment gateway | Payment processor |
|---|---|---|
| What does it mainly do? | Securely handles or transmits payment requests from checkout | Helps move the transaction through authorization, capture and settlement steps |
| Where does it sit? | Website, app, hosted checkout, payment link or virtual terminal | Behind the checkout, connected to processing and acquiring routes |
| What does the merchant configure? | Payment form, API keys, tokenization, 3D Secure flow, payment methods | Capture logic, response handling, processing reports and routing settings |
| What can fail there? | Token issue, checkout timeout, API error, authentication or redirect failure caused by the gateway, merchant integration, 3DS provider, or issuer authentication service | Authorization-message failure, malformed response, capture or batch-processing error, clearing issue, or reporting mismatch |
| How is it priced? | Percentage fee, fixed transaction fee, interchange-plus or blended rate, feature add-ons | Pricing varies widely and may combine gateway, processing, acquiring, scheme, authentication, cross-border, and dispute-related fees |
| What does it not solve alone? | Underwriting, MCC approval, reserves, payout holds | Checkout UX and payment-form behavior |
A low-risk merchant may never need to separate these roles because one PSP bundles everything. A high-risk merchant usually cannot afford that blur. When approval rates drop, or payouts are delayed, it matters whether the problem sits in the gateway, processor, acquirer, issuer, risk engine, or account policy.
Payment Gateway vs Payment Processor vs Acquirer vs Aggregator
A two-part comparison misses two important pieces: the acquirer and the aggregator or PayFac. The full comparison is payment gateway vs payment processor vs acquirer vs payment aggregator – each role controls a different part of the payment relationship.
| Role | What it really controls | What merchants should ask |
|---|---|---|
| Payment gateway | Whether checkout can create a valid payment request | Is the checkout stable, secure and easy for customers to complete? |
| Payment processor | Whether transaction messages can move through the processing path | Are responses, capture, records and reporting handled clearly? |
| Acquirer / acquiring bank | Whether the merchant can accept card payments under this risk profile | Is this MCC, country, product and chargeback profile acceptable? |
| Aggregator / PayFac | Whether the merchant can process under a sponsored model | What happens if risk signals change after launch? |
A merchant account – the piece often skipped in simple gateway-vs-processor explanations – is the financial relationship that lets a business accept card payments and receive settlement. For high-risk merchants, it is often the hardest part: the gateway may connect easily, and the processor may be capable, but the acquirer can still reject the category, country, or MCC code.
Trying to map your own stack onto these four roles? A payment gateway provider that will actually name the acquirer behind your account makes this far easier.
What Is a Payment Service Provider (PSP)?
A PSP combines several payment functions – gateway technology, processing access, payment methods, fraud tools, reporting, and sometimes acquiring – under one commercial relationship.
This is why merchants use payment terms loosely: someone may call Stripe “our processor” while it also provides gateway functionality, or call PayPal a gateway when it also acts as a wallet and merchant-account-style service. A bundled PSP setup can simplify integrations and contract management, although visibility into acquiring relationships and reserve conditions depends on the provider and agreement. That may be fine for mainstream e-commerce; for high-risk merchants, those hidden details can decide whether revenue keeps moving.
How a Card Transaction Moves From Checkout to Settlement
A card transaction is not one single action. It is a series of handoffs and decisions.
Merchant acceptance is generally assessed during onboarding and underwriting. Acquirers and PSPs may continue reviewing merchant activity, but this is separate from the issuer’s authorization decision for an individual transaction.
| Stage | What is being decided | Main layer involved |
|---|---|---|
| Checkout | Can the customer submit payment details? | Gateway |
| Data handling | Is the request complete, protected and formatted correctly? | Gateway / PSP |
| Routing | Where should this transaction go? | Processor / PSP / acquiring connection |
| Issuer response | Will the customer’s bank approve the transaction? | Issuing bank |
| Capture | Should the approved amount be finalized? | Merchant / processor |
| Records | Can the transaction be matched in reports and settlement data? | Processor / acquirer / PSP |
| Payout | What funds are released, held, offset or reserved? | Acquirer / PSP / aggregator |
In other words, the simple statement that “the payment failed” does not provide sufficient detail. Payments can fail before they reach the issuer, be declined by the issuer, or be approved while the merchant’s payout is delayed pending a KYB review or part of the funds is withheld under a reserve policy. A transaction may also succeed in one country and fail in another because the acquiring route performs differently. A robust payment setup will show whether the problem occurred during processing, authorization, or payout; a poor one may provide only a generic failure message or leave a payout delay unexplained.
Payment Failures, Issuer Declines, and Account Holds: Diagnosing the Layer
Merchants often say, “The gateway declined the payment,” although the gateway may simply be displaying a response from another part of the payment system. The error code is a useful starting point, but it doesn’t always tell the whole story. A failed authentication, an issuer decline, and a payout hold are different problems, and each needs a different approach.
| Message or pattern | Likely source / where to investigate | What it means / what to do |
|---|---|---|
| 1. Technical and authentication failures | ||
| Invalid API key, bad endpoint, token error, checkout timeout | Gateway / merchant integration | Check credentials, endpoint, request format, and connection logs. The request may not have reached processing. |
| 3D Secure failed or abandoned | Merchant checkout / 3DS provider / issuer's Access Control Server (ACS) | Check the authentication status, challenge flow, redirects, and timeout logs. The customer may have abandoned the process, or authentication may have failed for technical or issuer-related reasons. |
| 2. Issuer authorization declines | ||
| “Insufficient funds” (code 51) | Issuer | The available balance or credit is insufficient. The customer may need to add funds or use another payment method. Any retry must follow the applicable network rules. |
| “Restricted card” (code 62) | Issuer | The card is subject to restrictions. Ask the customer to contact their bank or use another payment method. |
| “Do not honor” (code 05) | Issuer | A generic decline without a specific explanation. Check any additional issuer response data and the provider's retry guidance before attempting another authorization. |
| “Lost card” / “Stolen card” (codes 41/43) | Issuer | Hard decline. Do not retry using the same card credentials. |
| 3. Merchant-account, reserve, and payout issues | ||
| Merchant category or MCC unsupported | Acquirer / PSP | The business type, MCC, country, or product falls outside the provider's acceptance policy. Another acquiring relationship or underwriting review may be needed. |
| Payout delayed after approved transactions | PSP / acquirer / PayFac | Check KYB status, reserve requirements, settlement schedules, and payout conditions. An approved transaction does not guarantee immediate payout. |
| Account placed under review or processing suspended after launch | PSP / PayFac / acquirer | The provider may be reviewing changes in transaction volume, chargebacks, refunds, business activity, or compliance status. Confirm the reason and required corrective steps. |
A soft decline describes a potentially recoverable refusal, not a separate processing layer. A sudden drop in approvals in one country is also a broader performance signal rather than a single decline type. To investigate it, compare issuer response codes, BIN-level results, and acquiring-route performance.
For high-risk merchants, the distinction matters. An issuer decline may affect one transaction; a merchant-account restriction can stop processing altogether. A payout hold is different again: payments may have been approved, but the merchant cannot yet access the funds.
The right response depends on what actually happened – fixing an integration, addressing an issuer decline, resolving an account review, or finding an acquiring relationship that supports the business.
Merchant Account, MCC Code, and High-Risk Underwriting
A merchant account represents the financial arrangement that enables a business to accept card payments and receive settlement. Depending on the model, the merchant may have a direct acquiring relationship or operate as a sub-merchant through a PayFac. The PSP or acquiring bank is exposed to the merchant’s chargeback, refund, fraud and compliance risk – if the merchant cannot cover the losses, the acquirer may face additional financial exposure. Therefore, not all businesses are given equal treatment.
The merchant category code (MCC), along with other signals, helps acquirers and PSPs assess the merchant’s risk profile during underwriting. It indicates the type of merchant that generated the transaction. While a clothing retailer and an online casino may both have the same checkout process, they have very different refund patterns, chargeback rates, and regulatory concerns. For low-risk merchants, MCC usually stays in the background; however, for high-risk merchants, it can affect whether onboarding happens at all. For gambling websites, card networks define MCC 7995 (betting, including casino gaming chips); in the US region, government-licensed online casinos use MCC 7801. The acquirer assigns the code during onboarding.
Stripe provides documentation regarding restricted businesses, including those requiring further review or not supported based upon geographic location, product, and/or risk level. PayPal products can combine merchant-account and gateway functions and can place temporary holds on funds when a payment is disputed; therefore, provider rules are especially important.
For businesses in iGaming, forex, crypto, adult, and other high-risk sectors, the fundamental question is not “Which gateway offers the best API?” but “Which acquirer is willing to underwrite this business and keep the account live?”
Do you have any more questions?
Fill out the form, and we will contact you
*By submitting this application, you consent to the processing of your personal data in accordance with the privacy policy.
The Reason Accounts Freeze: Aggregators and PayFacs
Payment aggregators and PayFac-style PSPs enable faster merchant onboarding; rather than each merchant developing a direct relationship with an acquirer, the aggregator lets multiple merchants use its master merchant account to process payments as sub-merchants. Square and Stripe both work this way for most merchants. While it is beneficial, it is also delicate.
This is why aggregated/PayFac-style models are so effective with the general seller base, yet can be fragile for large transaction values, international business, or high chargeback rates. PayFacs and their sponsoring acquirers continuously monitor sub-merchant activity. Material changes in volume, geography, products, disputes, or chargebacks may trigger reserves, additional review, payout delays, or termination under the applicable agreement.
For a CFO, two questions need answering. First, who controls settlement funds? Second, how quickly could payouts be delayed or temporarily suspended?
What You Actually Sign: Contract, Funds, and Liability
A payment setup is not only a technical choice – it is also a contract about money, risk, and responsibility.
A merchant may sign with:
- a gateway provider that supplies checkout connectivity;
- a PSP that bundles gateway, processing, reporting, and settlement support;
- a PayFac or aggregator that sponsors access;
- a direct acquirer that provides the merchant account.
Note on Merchant of Record (MoR): A merchant of record is not another processing layer. It is a commercial model in which a third party becomes the legal seller to the customer and assumes defined responsibilities for payments, taxes, refunds, and disputes.
Before choosing the setup, ask three questions.
- Who is the merchant of record?
This affects legal responsibility, taxes, refund ownership, customer statements, and disputes.
- Who can delay settlement?
The party controlling payout may apply a rolling reserve, pause funds during review, offset refunds, or change settlement conditions under the agreement
- Who carries chargeback exposure?
A provider may manage dispute workflows, but the merchant may still absorb the financial loss, fees, and operational work
A lower processing rate can look attractive on paper. It becomes expensive if payouts are unstable, reserves are heavy, or the merchant was never underwritten correctly.
High-Risk Stack: Several Acquirers Under One Gateway
A simple setup may work with one gateway, one processor, and one acquiring route. High-risk merchants often need more resilience than that.
A stronger setup may include:
- one gateway or routing layer;
- several acquiring relationships;
- separate MIDs and billing descriptors for genuinely separate brands or business lines;
- routing by country, BIN, issuer, card type, currency, amount and risk score;
- retry logic for recoverable soft declines;
- reporting by provider, route, issuer, geography and decline code.
A gateway with routing and orchestration capabilities can help maintain payment continuity by directing eligible transactions through approved routes. For more on how routing and cascading work, see BillBlend’s guide to payment orchestration.
When payment performance drops, switching processors may not be necessary. The merchant may instead need another approved acquiring route, local acquiring in a particular market, or better chargeback management. Each MID has to reflect the real business behind it. For iGaming, forex, and other high-risk verticals, BillBlend offers payment gateway technology and connectivity to supported payment providers and local payment methods, depending on availability and approval.
If your decline data does not show whether the problem sits with the issuer, acquirer, processor, or route, BillBlend can help map the payment chain before you replace the wrong provider. Talk to the BillBlend team for a free review of your setup.
Payment Processor and Gateway Examples: Who Is Actually What
Payment brands are hard to label because many of them cover several jobs at once. The better question is not “What is this company forever?” but “What role does it play in this integration?”
| Brand | How to think about it | What matters |
|---|---|---|
| Stripe | PSP with gateway and processing functionality; acquiring-related capabilities vary by country and product | Strong integrated setup, but restricted-business rules still apply |
| PayPal | Wallet, PSP, gateway and merchant-account-style solution depending on product | Convenient, but PayPal’s account rules and risk policies matter |
| Amazon Pay | Checkout method and payment processor: Amazon processes the payment and can hold funds | Amazon's own reserve and payout rules apply, on top of the merchant's main stack |
| Authorize.net | Payment gateway | Often connects merchants to processors and merchant accounts |
| Adyen | Enterprise PSP/acquirer/processor/gateway-style platform depending on region | Often used by larger merchants needing global acquiring and local methods |
| Mastercard / Visa | Card networks | They connect issuers and acquirers; they are not ordinary merchant gateways |
Other payment providers include Fiserv, Global Payments, and Elavon, whose processing and acquiring-related services vary by product and market.
Modern payment providers often combine several roles, so the distinction depends on the product and region. Stripe can offer gateway, processing, and broader PSP functionality; PayPal combines wallet services with payment-platform features; Amazon Pay provides a checkout option with its own processing, settlement, and reserve rules.
Payment Processor vs Payment Network: Where Visa and Mastercard Sit
Visa and Mastercard are card networks, not payment processors in the merchant-facing sense: they provide the rules and rails connecting issuing and acquiring banks. A processor sends messages through those rails; the issuer approves or declines; the acquirer manages settlement.
Payment Costs: Look Beyond the Transaction Rate
These different roles also affect what merchants pay. Rather than focusing only on the headline transaction rate, compare the full commercial model, including gateway, processing, acquiring, scheme, authentication, cross-border and dispute fees, as well as reserve and settlement terms.
Payment Security: Encryption, Tokenization, PCI DSS, and 3D Secure
Payment security depends on how checkout is set up and where card data goes. Four elements matter here:
- Encryption protects payment data during transmission.
- Tokenization replaces sensitive card details with tokens, reducing the need to store actual card numbers.
- PCI DSS sets security requirements for businesses and providers that handle cardholder data.
- 3D Secure adds cardholder authentication through the issuing bank when required.
A hosted payment page can reduce the merchant’s PCI DSS scope because the provider collects card details. Direct API integrations that handle card data on the merchant’s systems generally bring more security responsibilities. Using a gateway does not remove the merchant’s PCI DSS obligations.
How to Choose the Right Setup
The best setup depends on risk level, geography, payment methods, and how much control the merchant needs: a small low-risk store may be fine with an all-in-one PSP; a subscription business needs to weigh recurring billing and involuntary churn more heavily; a marketplace considering a PayFac model should also clarify who acts as the merchant of record and how dispute responsibilities are allocated.
For high-risk merchants, the setup should start with underwriting and continuity.
Ask:
- Does the provider support your MCC code and vertical?
- Which acquiring banks sit behind the setup?
- Who holds funds before payout?
- What triggers a rolling reserve?
- Can transactions be routed across several acquirers?
- Does the provider support smart routing and cascading?
- What happens if one acquirer stops supporting the vertical?
- Who handles chargebacks and representment?
- Can local payment methods be added without rebuilding checkout?
This is the difference between buying a payment gateway and building payment infrastructure.
Before signing, ask the provider to confirm its acquiring coverage, reserve policies, and payout terms in writing.
What High-Risk Merchants Need From a Payment Provider
High-risk merchants often need capabilities that are not available in every PSP setup, including multiple approved acquiring routes, local payment methods, flexible routing, and detailed risk and settlement reporting.
BillBlend helps merchants manage payment routing and transaction performance through an integrated payment technology approach.
For high-risk merchants weighing payment gateway vs payment processor options, the practical question is not just whether checkout works, but whether the payment setup meets their business needs and supports their target markets.
Speak with BillBlend to review your current payment stack and discuss potential issues affecting transaction approvals or payouts.
Frequently Asked Questions
Do I need both a payment gateway and a payment processor?
Most online card payments need both gateway functionality and processing functionality. A merchant may buy them separately or use one PSP that bundles both into a single platform. Providers often bundle them because merchants prefer one contract, one integration, and one reporting layer instead of managing separate gateway, processor, and acquiring relationships.
What are the common reasons for payment gateway failure?
Common reasons include API errors, invalid credentials, expired tokens, 3D Secure redirect issues, checkout script conflicts, timeout errors, unsupported payment methods, incorrect currency setup, and malformed transaction requests. These are technical failures, not always bank declines.
Why is my payment being declined by the payment gateway?
It may not be the gateway actually declining it. The gateway may simply display a response from the issuer, processor, acquirer, or risk engine. Check the decline code first. A soft decline may be recoverable through authentication or routing. A hard decline usually comes from the issuer. A merchant-category rejection usually points to acquirer or PSP policy.
What is the difference between a merchant account and a payment gateway?
A payment gateway securely transmits payment information from checkout and may also collect card details, depending on the integration. A merchant account is the financial relationship that allows the business to accept card payments and receive settlement. The gateway handles the payment request; the merchant account handles the merchant’s ability to get paid.
What are the downsides of using a payment gateway?
A gateway can add fees, integration work, checkout dependency, and another possible point of failure. It also does not automatically solve underwriting, settlement, chargebacks, or high-risk acceptance. For high-risk merchants, the gateway is only useful if the acquiring and processing relationships behind it can actually support the business.
