Comparing payment providers?
See how leading PSPs differ in coverage, pricing, integrations, and day-to-day payment operations.
This website uses cookies to help improve your user experience
Choosing payment gateway solutions is largely a question of control that starts with a bigger decision: how much of the payment stack does your business actually need to own?
For most companies, integrating an established provider (PSP) is the fastest and most economical route. For others, transaction volume, geographic expansion, routing requirements, or provider limitations eventually justify orchestration or custom infrastructure.
This guide breaks down those choices through the decisions that matter in production: integration model, architecture, cost, PCI scope, reliability, multi-provider routing, and migration.
The goal is to help you decide where an existing PSP is enough, where an additional payment layer earns its keep, and where custom payment gateway development becomes a defensible investment.
Get engineering support for new PSP connections, multi-provider setups, migrations, and payment architecture.
A payment gateway is the layer that securely moves payment instructions between the checkout and the infrastructure that processes the transaction. It captures or receives payment details, passes the request into the processing chain, and returns the resulting status to the merchant’s system.
The processor handles the transaction further downstream, communicating with acquirers, card networks, and issuing banks to obtain authorization. A payment service provider, or PSP, usually gives the business access to both the gateway and the processing services through a single platform.
From the customer’s point of view, an online payment gateway might look like a checkout form or a wallet button. For the merchant, it sits on a critical transaction path where security, latency, provider availability, and integration design can directly affect completed payments.
But there’s a lot happening behind the interface to get that transaction to work.
An approval from the issuing bank only confirms that the transaction can proceed. Depending on the payment flow, funds may still need to be captured, cleared through the payment network, and settled into the merchant account.
That distinction matters operationally. Your application needs to know the actual state of each transaction, including pending payments, delayed captures, refunds, reversals, and failures that occur after authorization. Finance systems then have to reconcile the processor’s records against the funds received. A successful authorization is therefore one event in a longer payment lifecycle, not the finish line.
See how leading PSPs differ in coverage, pricing, integrations, and day-to-day payment operations.
For most companies, integrating an established provider is the economically sensible starting point. With a third-party provider, you get payment rails, security infrastructure, and much of the compliance framework needed to accept transactions.
A relatively standard payment gateway integration may cost around $5,000 to $20,000.
Custom payment gateway development changes the economics considerably and requires a much larger investment. Many custom gateways can get into the $50,000 to $300,000+ range, with proprietary platforms built much closer to the rails reaching $500,000 or more.
The initial build is only part of the payment gateway development cost. Certification, PCI DSS obligations, scheme changes, monitoring, incident response, and ongoing integrations become your responsibility too.
Integration is typically a better fit if your business can work within an existing provider’s payment flow, supported markets, transaction flows, and required level of checkout control.
It gets the product to market faster and leaves much of the regulated payment infrastructure with a company whose business is operating it.
The important question is much provider-specific logic you are putting into your own product. A tightly coupled integration can become expensive to change later, particularly when a second PSP, new market, or migration enters the roadmap.
When the limits of third-party providers start to create a problem for your business, like payment economics or product decisions, it’s a good time to consider a custom gateway.
High transaction volumes can make processing fees material, but cost is rarely the only trigger. You may need direct control over routing between acquirers, transaction data, retry logic, regional integrations, or payment behavior that an off-the-shelf provider cannot support cleanly.
At that point, a build-versus-integrate calculation is much more useful than comparing implementation budgets alone: development cost vs. the recurring cost of provider fees, failed payments, engineering workarounds, and limited routing flexibility.
Get a better sense of the investment required for different gateway approaches.
Deciding to take the existing provider integration route still means there are many things you have to do to get payments live. That can include planning for refunds, delayed events, reporting, security, and provider outages.
The main trade-off is control versus implementation and compliance overhead. A hosted checkout sends the customer to a payment page controlled by the provider. It’s usually the quickest option to implement, and your own systems may never touch the card data.
Embedded fields and iframes work differently. Even though the customer stays on your site, all the sensitive payment details go straight to the provider.
SDKs are more common for web and mobile teams that want ready-made payment components. They’re fast to set up, though you also lean more heavily on the provider’s tooling.
With a direct API, you get much more control over the payment flow. Of course, that also means more backend responsibility, especially if raw card data passes through your systems and increases PCI DSS scope.
Weigh hosted, embedded, and direct payment integrations before architecture work begins.
A payment integration starts with the transaction lifecycle, not the API. Authorization, capture, refunds, recurring payments, disputes, and regional methods need to be mapped against what the PSP supports natively. Anything the provider does not cover becomes part of your own payment logic.
The next decisions are architectural. Define where card data enters the system and how quickly it is tokenized, then design the backend around asynchronous payment states.
Webhooks can arrive late or more than once, requests can time out after the provider has processed them, and retries can create duplicate transactions if idempotency is missing. These cases need to be part of the design before production traffic arrives.
Testing should cover those failure paths, and monitoring should follow the transaction rather than stop at API availability.
Approval rates, payment errors, latency, and reconciliation can expose problems that infrastructure health checks miss.
In one Primer integration, Oxagile used an event-driven setup that cut new PSP rollout time from three months to about 2.5 weeks and reached a 93% acceptance rate.
Mobile apps introduce failure cases that web teams don’t often encounter. A customer might lose their connection during checkout or send the app into the background halfway through authentication.
Native SDKs also have to keep the checkout working if someone locks their phone or uses Face ID or fingerprint verification before returning to the payment.
Apple Pay and Google Pay can speed up the checkout process, but they still rely on an underlying payment processor or gateway. They also have their own rules about certain in-app purchases that can affect the payment flow.
See what it takes to build a reliable payment flow for iOS and Android.
Businesses rarely add a second gateway simply for redundancy. Different PSPs perform differently by market, card type, currency, and payment method. Running several can improve geographic coverage, approval rates, processing economics, and resilience when one provider has an incident.
The complexity moves into your own architecture. PSPs expose different APIs, transaction states, error codes, webhook behavior, and retry rules. Connecting each one directly to the product spreads provider-specific logic through the codebase and makes every new integration harder.
A shared payment layer gives the application one internal payment model, with provider adapters handling those differences underneath.
Failover also needs more than a rule that sends a declined transaction somewhere else. The system has to distinguish a genuine decline from a timeout or provider failure, know if the first PSP already processed the request, and prevent a retry through another route from creating a duplicate charge.
Oxagile used that approach for a subscription platform expanding into MENA, LATAM, and Southeast Asia. The new setup cut processor integration from months to weeks and introduced automatic fallback when a provider became unavailable.
See how to manage multiple gateways without making the payment flow harder to maintain.
Building a gateway means taking ownership of the transaction lifecycle between your product and the processors or acquirers underneath it. That gives you control over routing, payment states, integrations, and transaction data, but it also turns payments into infrastructure your team has to operate continuously.
Tokenization keeps raw card details from moving through more of the system than necessary. It replaces that information with a secure token that other services can use instead.
A gateway needs a consistent internal model for a transaction as it moves through authorization, capture, reversal, refund, and settlement. If there are several processors involved, that matters even more, as each provider represents payment states, errors, and asynchronous events differently.
Around it sit the security and operational components. Tokenization and the card vault control where sensitive credentials live and which systems can access them.
The routing layer selects the processor or acquirer based on rules such as geography, cost, availability, or performance.
Fraud controls evaluate transactions before money moves, while reconciliation later checks the gateway’s view of a payment against processor and settlement records.
The difficult part is how these components behave when the happy path breaks. A processor timeout, for example, does not necessarily mean the payment failed.
The gateway may need to establish the actual transaction state before retrying or routing elsewhere, or it risks charging the customer twice.
How do tokenization, routing, fraud checks, and reconciliation work as part of one system?
Before deciding how to build payment gateway solutions most optimally, establish what owning one would solve. Lower processing costs at sufficient volume can be one reason. Control over routing, specialized transaction flows, direct processor relationships, or limitations in existing PSPs can be others. Those benefits need to justify both the initial build and the permanent operational burden.
Architecture comes next: define the transaction lifecycle, security boundary, processor interfaces, failure behavior, and reconciliation model before implementation.
Processor connections and certification then have to be completed without treating launch as the finish line.
A production gateway needs ongoing ownership of PCI DSS obligations, scheme and processor changes, monitoring, incident response, security, and releases on a system where defects can affect real money.
The team should have experience building payments architecture, along with backend engineering, security, QA, and operations. Someone also needs to own scheme changes and compliance work after launch since the gateway will be an active financial system for as long as the business uses it.
See what goes into the path to production.
Compliance requirements are typical architecture constraints prior to certification. PCI DSS affects network segmentation, access controls, logging, key management, vulnerability management, and how changes to the cardholder data environment are tested and released.
PSD2 requires businesses in Europe to verify a customer’s identity more carefully for many online payments.
One common way to do that is EMV 3-D Secure, which lets the customer confirm the purchase via their bank before the payment goes through.
These are ongoing engineering responsibilities. PCI assessments recur, standards change, processor and card-scheme requirements move, and security controls have to survive normal product development.
For a custom gateway, compliance thus affects the initial architecture, the budget, and how the platform is operated and changed after launch.
The surrounding software may also need support for things like billing, payment processing, fraud checks, reporting, and integrations.
New markets, channels, and providers put different demands on payment infrastructure. Two capabilities become particularly important as that complexity increases: orchestration and payment-level observability.
Orchestration adds a control layer over multiple PSPs and gateways.
It can route transactions based on cost, geography, availability, or performance and apply fallback when a provider fails.
That overhead is difficult to justify for a simple single-PSP setup. It starts earning its place when routing decisions materially affect approval rates, resilience, or expansion into new markets.
Learn when to consider managing several payment providers through one system and how it’s done right.
Infrastructure can look healthy while payments are failing. A regional drop in approvals, rising authentication failures, or delayed provider responses may never trigger a conventional uptime alert.
Payment observability therefore needs to follow transaction outcomes as well as system health.
The useful question is not simply “Is the gateway up?” but “Where are we losing successful payments, and why?”
Build monitoring around transaction behavior and a clear incident response process.
Agentic payments change a basic assumption in payment infrastructure: the person authorizing the purchase may not be present when the transaction happens. The payment layer has to establish who the agent represents, what it has permission to buy, how much it can spend, and when human approval is required.
New protocols are beginning to formalize that trust model through agent identity, signed mandates, tokenized credentials, and programmable spending controls. Fraud models will also need to distinguish legitimate automated purchasing from malicious bot activity.
See what changes when software is able to choose and complete transactions.
Accepting payments on web, mobile, and POS does not make a payment setup omnichannel. The real test is whether every channel can recognize and continue working with the same payment.
A purchase made in an app should still be identifiable when it is refunded in-store, without rebuilding the transaction from disconnected records.
That requires a persistent payment identity and shared transaction state beyond authorization. For instance, refunds and settlement can happen somewhere else again. The payment record has to preserve that chain regardless of which channel generates the next event.
Customer identity and token portability add another layer. The same customer may have different IDs in the app, CRM, and POS, while payment tokens can be tied to a particular PSP or channel.
See what has to happen behind the scenes for channels to behave like one payment system.
Businesses usually switch providers when the current setup becomes too expensive or no longer supports the markets they need. Falling approval rates and recurring outages can push them to make the move sooner.
If the old provider still holds payment credentials or active transactions, the team may need to keep it running until recurring payments, refunds, and disputes are fully moved over.
With a phased migration, you can keep both providers running while you gradually move payments over. If something starts going wrong, you can shift traffic back instead of committing to the new setup all at once.
Oxagile used this approach to move card payments for more than 1.5 million users from Checkout.com to Braintree on a live system with zero downtime.
Plan the migration around live traffic, token portability, rollback, and reconciliation.
A PSP should fit more than today’s checkout. Look at market and payment-method coverage, approval performance, API and webhook behavior, settlement and reconciliation, token portability, support during incidents, and the real cost once cross-border, currency conversion, and other fees are included.
Just as important is how difficult the provider will be to work around later. A good integration should leave room to add another PSP, change routing logic, move stored credentials, or migrate without rewriting the payment layer around a new provider.
The same principle applies when choosing a development partner. Payment engineering goes beyond connecting an API.
The team needs to understand transaction states, failure behavior, PCI boundaries, reconciliation, migrations, and the operational consequences of architecture decisions made before the first transaction goes live.
There is no advantage in owning more payment infrastructure simply for the sake of control. The right setup is the one that gives the business enough ownership where it affects economics, reliability, and product flexibility, without taking on operational responsibility that a provider can handle better.
Oxagile works on both sides of that boundary, from PSP integrations and live migrations to multi-provider architectures and custom payment systems. We can help determine where that boundary should sit for your payment stack.
Bring us the current setup, constraints, and roadmap. Oxagile’s team can help assess where integration is enough and where more control is worth the engineering investment.
