A merchant account is a specialized bank account that holds funds from card transactions before they settle into a business’s regular bank account. A payment gateway is the technology layer that securely captures and transmits transaction data from checkout to the processor for authorization. They serve different functions (one handles money, the other handles data) and most businesses need both.
A payment processor is the third related term: the entity that actually moves transaction data between the gateway, the card networks, and the merchant account. Most small and mid-sized businesses use a PSP (payment service provider) that bundles all three.
Ask several payment vendors to define a merchant account and payment gateway, and the answers rarely line up. Most of the confusion comes from bundling because a single PSP sells both functions as one product, so the vendor’s own marketing uses the two terms interchangeably even though one holds money and the other moves data.
Payment processor comes up next, and it confuses things further because that role gets absorbed silently into whichever term the vendor already leads with. Some providers call their processing layer a gateway, others call the whole stack a merchant account, and the label ends up describing whoever is selling it more than what the piece actually does.
However, the global payments industry generates $2.5 trillion in revenue on 3.6 trillion transactions a year, according to McKinsey, and at that scale, which piece of the stack actually holds funds versus which one just moves data determines who’s liable when something breaks. This is why it’s crucial to understand the nuances of each of these terms. This guide separates them on their own merits.
What Is a Merchant Account?
A merchant or processing account is a specialized bank account that holds funds from card transactions before they settle into your regular business account. It isn’t the same as a standard checking account or a standard business bank account, and a business can’t deposit into or withdraw from it directly the way it would a normal account.
When a customer pays by card, the acquiring bank captures the authorized funds and deposits them into this account, where they sit until a scheduled settlement moves them into the business’s actual bank account.
Any business accepting card payments needs one because it enables the business to accept credit and debit cards, accept electronic payments, and handle online transactions, whether that processing account is dedicated to the business alone or shared as part of an aggregated, sub-merchant setup under a larger provider. The setup that fits depends almost entirely on transaction volume and how much underwriting control the business wants to hold onto.
What Is a Payment Gateway?
A payment gateway is the technology layer that captures and encrypts a customer’s payment details at checkout, then passes them securely to the payment processor and card networks for authorization. It sits between the customer-facing checkout and the back-end systems that actually move money.
A gateway is a messenger and a security checkpoint. That’s the core distinction from a merchant account, which is the actual account that receives settled funds after the transaction clears. A gateway without a processing account has nowhere to deposit the money it just authorized. At the same time, a processing account without a gateway has no way to process an online transaction in the first place. They’re typically bundled by PSPs like Stripe or Square, but can also be sourced separately.
How a Payment Gateway Works
At the moment a customer submits payment details, the gateway collects them and encrypts the data immediately, before it ever reaches the merchant’s own servers in raw form. This helps protect sensitive payment information before it reaches the processor. It transmits an authorization request to the processor and waits for a response. That response, an approval or a decline, gets returned to checkout within a second or two.
Most businesses need payment gateway development or integration to connect through one of three integration approaches: a hosted redirect, embedded hosted fields, or a direct API, each trading off control for implementation speed differently, and each carrying its own share of PCI scope.
Merchant Account vs. Payment Gateway: Key Differences
Laid out side by side, the merchant account vs payment gateway vs payment processor distinction becomes obvious: each term touches a different part of the same transaction, and none of them does the other’s job.
The table below breaks down what each piece actually handles, money, data, or the instructions that move between them.
Merchant Account | Payment Gateway | Payment Processor |
|---|---|---|
Holds and settles funds from card transactions | Captures and transmits transaction data securely | Moves transaction data between gateway, card networks, and merchant account |
A specialized bank account | A software/technology layer | A service, often bundled with the gateway or account |
Deals with money | Deals with data | Deals with data + settlement instructions |
Merchant Account
Holds and settles funds from card transactions
A specialized bank account
Deals with money
Payment Gateway
Captures and transmits transaction data securely
A software/technology layer
Deals with data
Payment Processor
Moves transaction data between gateway, card networks, and merchant account
A service, often bundled with the gateway or account
Deals with data + settlement instructions
Role in the Transaction Process
Each term maps to a different point of contact in the same payment transactions. The gateway acts first, capturing card data the instant a customer checks out. The gateway sends that data onward for authorization, and the processor routes the request toward the customer’s card issuer, carrying back the approval or decline. The merchant account handles what happens next: it receives the captured funds and holds them until they settle into the business’s main bank account. The full sequence, from checkout to settled funds, is worth walking through step by step.
Fees and Cost Structure
U.S. merchants paid a record $198.25 billion in credit and debit card processing fees in 2025, which is more than triple the $62.1 billion paid in 2009, according to Nilson Report data cited by the Merchant Payments Coalition. That growth reflects fees stacking from both sides of a transaction, since a business typically pays a merchant account’s processing rate and a gateway’s separate fees on top of it, and the total any one business owes depends on which pricing model it lands on.
Here’s how those two costs actually break down:
- Processing account fees are usually structured as interchange-plus pricing or a flat processing rate, sometimes with separate monthly fees layered on top.
- Gateway fees typically run a per-transaction charge, a monthly platform fee, or both, kept apart from whatever the account itself charges for processing.
Oleksandr Boiko
Delivery Director at SPD Technology
“A bundled PSP, one of the more common merchant services, folds both into one simpler, often flat rate, which is exactly why it’s the default choice for a fast launch. At high transaction volumes, a dedicated merchant account paired with a separately integrated gateway usually costs less and settles sooner, which helps cash flow, but it means tracking two fee schedules and two vendor relationships instead of one.”
Integration and Technical Setup
A payment gateway integration is a technical project with an API integration, a hosted checkout redirect, or embedded hosted fields. It is built and tested against a sandbox environment before anything goes live.
Setting up a merchant account is a different kind of process entirely. It’s an underwriting and application cycle with an acquiring bank, other financial institutions, or a payment service provider that reviews the business’s risk profile, processing history, and industry category before approval. Neither timeline moves faster because a launch date says it should. This mismatch, one technical and one administrative, is exactly why a bundled PSP gets chosen so often for a first launch. It collapses both processes into a single signup flow, trading control for speed.
For businesses that don’t want that trade-off, the more useful move is building the gateway side while underwriting runs on its own track, so the account isn’t the only thing standing between a finished integration and a live launch. Merchant payment gateway development can specifically solve this problem, getting the technical half done and tested so it’s ready the moment underwriting clears.
How Merchant Accounts and Payment Gateways Work Together
A single card transaction touches every layer described above within a couple of seconds, in a fixed order.
Nothing in this sequence overlaps, and no step can be skipped, whether the business runs a bundled PSP or works with multiple service providers across a fully separate stack. Every transaction needs both a processing account and a gateway moving through this exact sequence, since the payment system has no shortcut around any one of the six steps.
Step | What Happens |
|---|---|
1. Initiate | Customer submits payment information at checkout |
2. Secure & transmit | Payment gateway encrypts the data and sends it for authorization |
3. Route | Payment processor routes the authorization request to the card networks |
4. Authorize | The customer’s card issuer approves or declines the transaction |
5. Capture & hold | The business’s merchant account receives and holds the captured funds |
6. Settle | Processor settles funds from the merchant account to the business’s bank account |
Step
1. Initiate
2. Secure & transmit
3. Route
4. Authorize
5. Capture & hold
6. Settle
What Happens
Customer submits payment information at checkout
Payment gateway encrypts the data and sends it for authorization
Payment processor routes the authorization request to the card networks
The customer’s card issuer approves or declines the transaction
The business’s merchant account receives and holds the captured funds
Processor settles funds from the merchant account to the business’s bank account
Do You Need Both a Merchant Account and a Payment Gateway?
Functionally, every business that wants to accept payments online needs both a processing account and a gateway working together, whether they’re bundled into one provider or set up as a separate account and a standalone gateway. The real question is whether you want them bundled or split.
A bundled PSP is usually the right call at lower volume or during a first launch, since it turns two setup tracks, technical integration and underwriting, into a single signup flow. Once volume grows, or interchange-plus savings and fraud detection with machine learning start to matter more than convenience, a dedicated merchant account paired with its own gateway provider usually pays for itself. Either way, money still has to move from the customer’s bank into the business’s account, and payment data still has to move securely to authorize it, regardless of how many providers are technically involved.
Marketplaces and embedded-payment platforms face a related but different question: whether the platform needs its own processing account at all, or whether it can run as a sub-merchant under a payment facilitator‘s account instead.
Oleksandr Boiko
Delivery Director at SPD Technology
“The PayFac question is about who owns the underwriting relationship. A platform that stays a sub-merchant moves faster at first, but every risk decision still routes through someone else’s compliance team. The moment that starts slowing down onboarding for your own merchants is the moment building the underwriting layer yourself starts paying for itself.”
That question is only getting bigger, transaction value flowing through embedded payments and finance in the US is on track to exceed $7 trillion in 2026, more than double 2021 levels, with the revenue opportunity for platforms and the infrastructure providers that power them projected to more than double to $51 billion over the same period. At that scale, the underwriting choice stops being a footnote and becomes a real merchant payment platform development decision, since whoever owns it also ends up owning the merchant management lifecycle, onboarding, risk review, payouts, that comes with it.
Choosing the Right Merchant Account and Payment Gateway Provider
Picking the right merchant account and payment gateway provider is about matching the setup to how the business actually processes transactions.
Merchant account providers that look cheapest on a rate sheet can still cost more once monthly minimums and chargeback fees are counted, and a payment gateway provider with a polished dashboard is useless if it doesn’t fit the existing checkout stack. A provider that handles credit card payments smoothly won’t automatically handle debit card payments, contactless taps, or digital wallets with the same reliability, which is worth testing before signing anything. Traditional processing accounts and modern bundled PSPs solve for different priorities entirely.
-
PCI DSS compliance and tokenization should come standard with any processing account provider or gateway provider, since their absence should disqualify a provider outright rather than just cost it points.
-
The full fee schedule needs review beyond the headline rate, because monthly minimums, PCI fees, chargeback fees, and termination fees materially change the real cost of accepting payments.
-
Integration quality has to match the business’s actual platform and checkout flow, since a strong API is irrelevant if it doesn’t fit the existing stack without a costly rebuild.
-
Pricing and underwriting terms should fit the business’s transaction volume and industry category, because flat-rate PSP pricing and dedicated interchange-plus accounts favor different volume profiles.
-
Settlement speed is worth confirming upfront, since how quickly captured funds move from a processing account into the business’s bank account affects cash flow more than the headline rate does.
-
Contract terms deserve as much scrutiny as pricing, since early-termination fees and long lock-in periods can outweigh whatever savings a lower rate first appeared to offer.
Why SPD Technology: Our Expertise in Merchant Payment Gateway Development
SPD Technology builds the integration layer between processing accounts, gateways, and processors for real businesses, implementing whichever setup actually fits their volume and risk profile. Whether that means building a payment processing system from the ground up or automating how a business accepts credit and debit card payments at scale, the work centers on getting the mechanics right for that specific setup.
Long-Term Payment Processing Integration
Our engineering team delivered an all-in-one omnicommerce payment processing system for Poynt, covering a full cycle of payment processing, settlement, and third-party integration. The system reflects the same underwriting logic that now shapes merchant payment platform development: full-cycle processing, settlement, and third-party integrations, all built on PayFac-model economics.
As the partnership grew, the work shifted toward moving Poynt onto a full PayFac model, redesigning settlement to handle sub-merchant hierarchies and speeding up onboarding with stronger risk monitoring. The team also built an embeddable payment gateway interface for merchant checkout pages, backed by tokenization and fraud detection.
That engagement has now run over five years, expanding to include a new Adyen integration, Apple Pay and Google Pay support, and a settlement system scaled for higher transaction traffic. Poynt was later acquired, and SPD Technology stayed on as the team maintaining and extending the same system under the business’s new owner.
Merchant Onboarding at Scale
The Aggregated Merchant Portal we built for Blackhawk Network onboarded more than 8,000 US businesses in two years, cutting onboarding time from 7 days to under 24 hours. Blackhawk’s Original Content Program let one gift card work across thousands of locations, but thanks to the merchant onboarding solution we delivered, adding new merchants meant sales reps manually collecting information and creating leads in Salesforce by hand.
Our team built the portal from scratch, automating OFAC, EIN, and SSN checks into a self-registration flow that auto-approved qualifying merchants. The same platform handled POS terminal registration, subscription management, and Salesforce lead creation, then migrated existing merchant data from Spafinder, Wayspa, and EntreeCard onto the new system.
Multi-Provider Gateway Integration
NimbleCommerce‘s white-label eCommerce platform runs on 27 third-party payment systems, integrated by our engineers. The client needed a single provider capable of delivering its B2C and B2B platform end to end, including an AI/ML-powered reporting module, after outgrowing the agency it had originally hired.
Built to let merchants and resellers accept payments online through whichever provider fits their market, the platform launched across the US, Canada, Mexico, Greece, the UK, and other European countries. The partnership ran six years before the client was acquired, closing a multi-year, multi-country engagement.
Key Takeaways
- Bundling merchant accounts and payment gateways into a single PSP simplifies initial setup for low-volume businesses, but increases processing costs and limits underwriting control as transaction volume grows.
- Dedicated processing accounts paired with standalone gateways reduce processing fees through interchange-plus pricing, but require tracking two separate fee schedules and technical integration tracks.
- Building the gateway integration while underwriting runs in parallel eliminates launch delays caused by bank approval timelines.
- U.S. merchants paying $198.25 billion in processing fees in 2025 highlights the necessity of reviewing complete fee schedules to avoid hidden chargeback, monthly minimum, and early-termination costs.
- Platform transition from sub-merchant setups to custom PayFac infrastructure accelerates merchant onboarding, but increases operational responsibility for compliance, risk monitoring, and payouts.
- Automated merchant onboarding with instant background checks cuts registration time from 7 days to under 24 hours while eliminating manual lead creation errors.
In short: A payment gateway moves data and a merchant account holds money, so while bundled PSPs offer fast launches, split setups give high-volume businesses lower fees and greater operational control.
FAQ
Can I use a payment gateway without a merchant account?
Every transaction needs a merchant account or an equivalent sub-merchant arrangement somewhere in the chain, even when a gateway is the only thing you set up directly.
Most payment gateway providers bundle a processing account in behind the scenes, routing captured data to a shared account they manage. What you’re actually getting is a gateway layer that takes the checkout data and transmits payment information to an account you don’t see or control directly. If you want a separate processing account instead, that has to be set up and underwritten independently.
What is the difference between a payment gateway and a payment processor?
A payment gateway captures and encrypts payment data at checkout. A payment processor is what actually moves that data onward, between the gateway, the card networks, and the customer’s issuing bank, then carries the approval or decline back.
The gateway sits at the front end of a transaction, facing the checkout page. The processor operates behind it, handling the routing that authorizes credit card payments and debit card transactions alike.
How much do merchant accounts and payment gateways typically cost?
A merchant account usually runs interchange-plus or flat-rate processing fees, sometimes with a monthly account fee added on top. A payment gateway usually charges separately, a per-transaction fee, a monthly platform fee, or both. Bundled PSPs fold both into one number, simpler to budget for online payments but usually costlier per transaction than a separate setup once volume climbs.
Do I need a dedicated merchant account or is a bundled PSP enough?
For most businesses starting out, a bundled PSP is enough, and often the faster way to accept payments without a separate underwriting process. Once volume grows, or once a business wants direct control over its financial account, clearer visibility into customer’s account activity, and how disputes get handled, a dedicated processing account usually becomes worth it.
The tipping point depends on transaction volume, industry risk category, and whether interchange-plus savings outweigh the cost of managing a separate merchant account and gateway relationship instead of one bundled provider.
What does a payment gateway integration actually involve?
Payment gateway integration means connecting checkout to the gateway through an API, a hosted redirect, or embedded hosted fields, then testing the flow in a sandbox before anything processes real card data. The gateway needs to handle encrypted data at every step, from the moment it captures a customer’s card data through the moment it returns an approval or decline.
Does a marketplace or platform need its own merchant account?
A marketplace can operate as a sub-merchant under a payment facilitator’s account, meaning the PayFac holds the underwriting relationship and individual sellers never need their own processing account provider. That model moves faster at first, since onboarding a new seller doesn’t require a full underwriting cycle each time. It becomes worth reconsidering once the platform’s own risk decisions, or how quickly a customer payment settles into a seller’s payout, start depending on someone else’s compliance team.
How long does it take to set up a merchant account and payment gateway?
A bundled PSP integration can be technically live within days, since the merchant account underwriting is already pre-approved in the background by the provider. A dedicated processing account application, set up separately from the gateway, is the slower half and the one most likely to cause launch delays if a team treats it as a formality rather than tracking it against documentation and risk-review timelines.