We design and build custom payment gateways for PSPs, EMIs, platforms and high-volume merchants whose payment flows have outgrown a standard integration. We cover authorisation, tokenisation, routing and settlement, with PCI DSS in scope from day one, and you own everything we build.
Let's talkA custom payment gateway is worth building when a standard PSP integration starts costing you margin, control or product flexibility. That usually comes down to four situations: processing fees at your volume outweigh the cost of running your own gateway, you need to route across several acquirers, your flows don't fit a PSP's model, or you're launching as a PSP, EMI or payment facilitator yourself.
If none of those apply, integrating an established provider is faster and safer, and we'll tell you so in the first conversation.
The right route depends on how much control over routing and card data you need, and how much compliance and certification work you're prepared to carry. Each route strikes a different balance between the two, so it pays to decide before any payment gateway development starts.
Payment businesses and platforms choose this when their volume or flows justify owning the stack. You control routing, data and the checkout. In return, you carry the full weight of PCI DSS scope, acquirer certification and ongoing maintenance.
This is the right route for most businesses. Stripe, Adyen or a similar PSP handles processing and much of the compliance burden, so you can take payments quickly. The trade-off is that you work within their rules, pricing and payment methods.
This route is for companies that want to offer payments under their own brand without building the core. You start faster and own the merchant experience, but the processing engine and its roadmap stay with the platform vendor.
If you already work with several PSPs, an orchestration layer routes each transaction to the best provider and gives you failover. You gain control over routing, while processing and the rails underneath stay with your PSPs.
A payment gateway is a set of modules that have to agree with each other on every transaction. The checkout screen is rarely where projects go wrong. The risk sits in settlement reconciliation and the token vault, where a design flaw turns into money you can't account for or audit scope you didn't plan for. These are the modules we build, as part of our FinTech software development work.
The routing engine sends each authorisation request to the right acquirer or PSP based on card type, currency, cost or availability. When an acquirer is slow or down, failover logic reroutes the transaction without losing its state, so a single outage doesn't stop you taking payments.
Let's talkTokenisation replaces card numbers with tokens that are useless outside your system. The vault is the only place real card data lives, which keeps the rest of your platform out of PCI DSS scope and lets you take repeat payments without storing cards anywhere else.
Let's talkReconciliation checks that what was authorised matches what the acquirer actually settled. Design it late and it fails silently: transactions look fine while the books drift apart. We make retries idempotent, so a repeated request never charges a customer or settles a payment twice.
Let's talkFraud screening scores each transaction for risk in real time and decides whether to approve it, decline it or send the cardholder through a 3D Secure challenge. Tuned well, it catches suspicious patterns while keeping false declines low, because every legitimate payment you block is lost revenue.
Let's talkA gateway for European customers needs more than cards. It supports digital wallets, bank transfers such as SEPA, local methods like iDEAL and pricing in multiple currencies, with conversion logic that makes clear which currency a merchant is paid out in.
Let's talkIf merchants process through your gateway, you need to check them before their first transaction. Onboarding flows handle identity verification, risk assessment and the KYC and AML checks, and only activate a merchant once those checks pass.
Let's talkSubscriptions and instalments depend on stored payment credentials and sensible retry logic. Recurring billing schedules the charges, retries failed payments at intervals that give them a real chance to succeed, and keeps the customer's payment details up to date.
Let's talkThe merchant dashboard is where your merchants or finance team see transactions, refunds and settlement status. Clear reporting here cuts support questions and manual spreadsheet work, and gives auditors a trail they can follow.
Let's talkMost of the work in a gateway project sits in its connections rather than its core. Our payment gateway integration services connect your gateway to acquirers, PSPs and the systems you already run, through documented REST APIs and SDKs.
Every acquirer has its own message formats, settlement files, fee handling and chargeback process. For Globus Payments, an EMI-licensed payments company in London, complex API integrations with banks and financial service providers were central to the platform.
An abstraction layer keeps your gateway logic independent of any single PSP. You can add a provider, switch one off or move volume between them without rewriting the core, which also strengthens your position when you renegotiate fees.
Your gateway has to exchange data with the platforms you already run, from ERP and accounting to e-commerce and core banking. API-first design keeps that payment gateway API integration predictable for your own developers.
Compliance decisions shape a payment gateway's architecture, so they belong before the first line of payment code rather than after testing. Retrofitting tokenisation or network segmentation into a finished system costs far more than designing it in. We build to the requirements of PCI DSS, PSD2 and GDPR from the start, which makes your own assessments simpler.
Where card data flows decides your PCI DSS scope. Tokenisation and network segmentation keep the cardholder data environment small, so fewer systems need assessing under PCI DSS v4. PA-DSS was retired in 2022 and replaced by the PCI Secure Software Standard.
Strong Customer Authentication applies to most online card payments in the EU under PSD2 and in the UK under rules overseen by the FCA. 3DS2 meets that requirement with risk-based checks: most transactions pass without a challenge, and only riskier ones ask the cardholder to confirm.
PCI DSS expects you to keep transaction records, while GDPR gives customers the right to erasure. Tokenising card data and pseudonymising references in transaction logs keeps the audit trail intact and limits what an erasure request has to touch.
Published estimates for payment gateway development vary widely because they describe different projects: integrating a PSP, building a gateway or becoming a payment facilitator. The cost and time of your gateway build follow from six factors, and a Discovery call pins them down for your case before anyone puts a number on it.
Each acquirer or PSP brings its own formats, test environment and certification. One connection is a contained piece of work. Three acquirers with failover between them is a different project, because routing, settlement and reconciliation logic have to handle all three.
Cards alone are the simplest start. Every wallet, bank transfer or local method you add brings its own flow, refund rules and reconciliation. Launching with the methods your customers actually use, and adding the rest later, keeps the first release focused.
Service providers that process more than 300,000 card transactions a year fall under PCI DSS Level 1 and need an annual assessment by a Qualified Security Assessor. Your expected volume, and how much of your platform touches card data, decide how much security architecture and evidence the build has to deliver.
Before you go live, acquirers and card schemes test your gateway against their specifications. That certification can't run in parallel with development, because it only starts once the integration works. Plan for it from the start and a technically finished gateway won't sit waiting for approval.
A gateway that only passes authorisation requests to acquirers is a technical service. Once you hold or move customer funds, you enter regulated territory: an EMI or payment institution licence, or a payment facilitator arrangement with a sponsoring acquirer, supervised by the FCA in the UK or a national regulator in the EU. That choice belongs with your legal advisers, and it changes what the gateway has to support.
You can check a few hundred transactions a day by hand, but not thousands an hour. The higher your expected volume, the more the build has to cover: automated matching, asynchronous settlement processing and alerts when the numbers don't add up.
Every step in our payment gateway development process produces something you can check before the next one starts, from a compliance scope at the outset to a monitored gateway after launch.
Which model fits depends on who owns your payment roadmap. None of them ties you to a long-term contract, so you can scale the team up or down as your payment gateway moves from build to operation.
Your CTO leads the roadmap and manages a team that works only on your payment gateway. It suits long-term ownership, where knowledge of your flows and acquirers builds up inside a stable team.
We manage delivery with an on-demand team and payment expertise on call, so you get experienced oversight without managing developers yourself. It's a good fit if you don't have a large engineering organisation of your own.
When the scope is fixed, such as a single acquirer integration or a defined gateway release, we take it from concept to deployment as one project with an agreed scope.
The biggest risk in a payment gateway project is dependence: on a PSP, and on the partner who builds your gateway. As a payment gateway software development company, we remove the second one, so you keep control over the system your revenue runs through.
Getting a regulated payments business live needs a partner who stays. We've been the technology partner of Globus Payments since its inception. For this EMI-licensed payments company in London, which serves logistics, we built the API integrations and compliant onboarding flows.
Handing over a gateway you can't run without us would only swap one dependency for another. You own the code and the intellectual property we build, including the tokenisation and routing layer, under every standard contract.
Remote teams stall when nobody on site owns quality and communication. Western managers at each of our hubs oversee delivery, and our engineers take part in cultural workshops and communication training.
A gateway built out of sight is hard to maintain afterwards. Our engineers sit in your standups and Slack channels and work to your roadmap, so knowledge of how your payment flows work stays inside your team.
A selection of the products our embedded teams have helped build.
Globus Payments is a London-based provider of EMI-licensed payment solutions for the logistics sector. Our team built the API integrations that connect its payment services to its clients' systems.
Read the case study
FiatGate is a white-label platform that lets businesses launch their own branded, non-custodial crypto wallet and exchange. We built the complete platform in JavaScript, with third-party APIs for wallet management and exchange functionality.
Read the case study
Axys provides card solutions for high-net-worth individuals, with crypto top-up of the card balance. We delivered the web development behind the platform.
Read the case studyIn a Discovery call we go through your volumes, acquirers and compliance scope. You'll leave knowing whether building, integrating or orchestrating fits your business, even if the honest answer is to integrate a PSP rather than build a payment gateway.
There's no standard price. The cost of developing a payment gateway depends on six factors: the number of acquirer connections, the payment methods at launch, your PCI DSS level, acquirer and card scheme certification, whether you route payments or hold funds, and the reconciliation needed at your volume. Integrating an existing PSP is a much smaller project than a full build. In a Discovery call we scope those factors for your situation before anyone gives you an estimate.
How long a custom payment gateway takes depends less on writing code than on what surrounds it. Acquirer and card scheme certification, the PCI DSS scope and the number of connections usually set the pace, and certification can only start once the integration works. That's why published estimates vary so widely. We map these dependencies in the first phase, so the plan reflects your acquirers and compliance scope rather than a generic timeline.
Payment gateway development starts with the compliance scope and a map of your acquirers, PSPs and payment methods. The core modules follow: routing, tokenisation, fraud screening, settlement reconciliation and the merchant dashboard, built iteratively and tested against acquirer sandboxes. Certification testing and a controlled go-live come next, followed by monitoring and security updates once the payment gateway handles live traffic.
Most businesses should integrate Stripe, Adyen or a similar PSP, because it's faster and much of the compliance burden stays with the provider. Building your own payment gateway makes sense when processing fees at your volume outweigh the cost of running one, when you need to route across several acquirers, when your flows don't fit a PSP's model, or when you're launching as a PSP, EMI or payment facilitator.
A payment gateway that only passes authorisation requests to acquirers is generally a technical service. Once you hold or move customer funds, you typically need an EMI or payment institution licence, or a payment facilitator arrangement with a sponsoring acquirer. In the UK that means FCA authorisation; in the EU, authorisation by a national regulator. The right route depends on your business model, so take legal advice before you design the gateway around it.
Under the card schemes' rules, a service provider that stores, processes or transmits more than 300,000 card transactions a year is PCI DSS Level 1, which requires an annual assessment by a Qualified Security Assessor. Below that threshold, Level 2 usually allows a self-assessment questionnaire. Whichever level applies to your payment gateway, tokenisation and network segmentation keep the number of systems in scope to a minimum.
Strong Customer Authentication, which 3D Secure delivers for card payments, applies to most online card payments in the EU under PSD2 and in the UK under rules overseen by the FCA. With 3DS2 the check is risk-based: most transactions pass without a challenge, and exemptions such as low-value payments and transaction risk analysis reduce friction further. A custom payment gateway has to support both the frictionless flow and the challenge.
Yes. A custom payment gateway can connect to several acquirers and PSPs through an abstraction layer that handles each one's message formats, settlement files and chargeback process. Routing rules then decide where each transaction goes, based on cost, card type, currency or availability, with failover when an acquirer is down. Working with multiple acquirers also gives you a stronger position in fee negotiations.
You do. When Prostrive builds your payment gateway, you own the code and the intellectual property, including the tokenisation and routing layer. That applies under all our standard contracts, whether you work with a Dedicated Team, Team-as-a-Service or Project-Based Development, so you can run, change or hand over the gateway without depending on us.
Yes. Integrating a payment gateway with your existing systems, from ERP and accounting software to e-commerce platforms and core banking, runs through REST APIs and SDKs. For Globus Payments, an EMI-licensed payments company in London, complex API integrations with banks and financial service providers were central to the platform. We document the interfaces so your own developers can maintain them.
A custom payment gateway can support debit and credit cards, digital wallets, bank transfers such as SEPA, local methods such as iDEAL, and recurring payments for subscriptions or instalments, in multiple currencies. Each method adds its own flow, refund rules and reconciliation, so it's usually best to launch with the methods your customers use most and add others later.
After your payment gateway goes live, we monitor performance and settlement, apply security updates and keep the gateway aligned with PCI DSS as requirements change. As transaction volumes grow, we add acquirers, payment methods and capacity without reworking the core. Because you own the code and we document it, you can also move support in-house later.