Setting up an online payment gateway means connecting your checkout to the systems that authorise and move customer money. There are two routes. You integrate an existing provider, or you commission custom payment gateway development when no provider fits your product.
For almost every business the first route is the right one, and it takes seven steps. The second route is a product decision rather than a payments decision. It is covered at the end, along with what it commits you to.
Setting Up a Payment Gateway With a Provider, Step by Step
The seven steps below run in order. Each one closes a decision that the next step depends on, so skipping ahead usually means redoing work. The first three are commercial, the middle three are technical, and the last one never really finishes.
Step 1: Get Your Business Details and Bank Account in Place
Every provider runs underwriting before they let you accept a single payment. Have your company registration, ownership details, business bank account and expected turnover ready.
Your website matters here too. Providers check for visible terms, a refund policy, a privacy notice and clear pricing before approving an account. This is the only step you can complete before choosing anyone, so start it early.
Step 2: Choose a Provider That Covers Your Markets and Payment Methods
Start with the countries you sell in and work backwards. A provider that handles UK cards well may have thin support for iDEAL, Bancontact or SEPA Direct Debit. That gap shows up as lost sales.
Check four things beyond the headline rate:
- how Strong Customer Authentication is handled under PSD2
- which currencies you can settle in, and how quickly
- how chargebacks and foreign exchange are charged
- whether the provider is FCA authorised or registered
Then read the documentation and open a sandbox account. Documentation quality predicts how long the integration takes better than any feature list.
Step 3: Open or Activate Your Merchant Account
A merchant account holds approved card payments before they settle into your business bank account. Some providers include it, so you sign up once. Others require a separate account with an acquiring bank, which means separate underwriting.
Confirm which model applies before you sign, because it drives your settlement times, your reserve requirements and who you call when funds are delayed. It also helps to be clear on the difference between a payment gateway and a payment processor. The two sit either side of this account.
Step 4: Choose an Integration Model and Set Your PCI Scope
This is the decision that shapes your compliance work for years, and most guides reduce it to a list of three options. The model you pick determines how much card data touches your systems.
A hosted page redirects the customer to the provider and keeps card data entirely off your servers. That puts you in the shortest self-assessment questionnaire, SAQ A. A drop-in or embedded field keeps the customer on your site, while the card data still goes straight to the provider. That lands you in SAQ A-EP territory.
A full API integration gives you complete control of the checkout. It also pulls card data into your own scope, with the audit burden that follows.
Pick the lightest model that supports the checkout you actually need. Teams routinely choose full API control for a checkout that a drop-in component would have handled.
Step 5: Connect the Gateway to Your Checkout
You generate test and live API keys in the provider dashboard, then wire them into your checkout using their SDK. Keep keys in a secrets manager rather than your repository, and keep the live key access list short.
Four things separate a working integration from a reliable one. Use tokenisation so you store a token instead of a card number. Treat webhooks as your source of truth for payment status, because a customer who closes the browser never triggers your redirect.
Send an idempotency key with every payment request so a retry cannot charge twice. Build reconciliation against the provider settlement report from day one, not after the first month-end.
Partial captures, refunds and reversals need handling in the same pass. They are easy to add now and painful to retrofit once orders exist.
Step 6: Test Every Path in Sandbox, Including the Failures
Providers supply test cards that trigger specific outcomes. Approvals are the easy part, so spend your time on everything else.
Run declines by reason code, expired cards, insufficient funds, a 3-D Secure challenge, a failed 3-D Secure challenge, a timeout mid-authorisation and a duplicate submission. Process a refund and a partial refund. Deliberately fail a webhook and confirm the retry updates your order correctly.
Then look at each failure the way a customer does. A decline that shows a blank screen costs you the sale twice, because they will not try again.
Step 7: Go Live and Watch Your Authorisation Rates
Going live means swapping sandbox keys for live keys and processing real money. The first weeks are when problems are cheapest to fix, so watch them closely.
Track your authorisation rate broken down by market, card issuer and payment method, since a single weak combination can hide inside a healthy average. Alongside that, monitor failed payment reasons, settlement timing against what the provider promised, your chargeback ratio and any webhook failure queue. A gateway is never finished, because payment methods and authentication rules keep moving.
Compliance You Cannot Hand Over to Your Provider
Using a provider reduces your compliance work. It does not remove it. PCI DSS still applies to you, at the scope your integration model set in step 4, and the annual validation is yours to complete.
Strong Customer Authentication under PSD2 sits in the same category. Your provider supplies the mechanism, but exemption decisions such as transaction risk analysis affect your conversion and your liability. Transaction data also falls under GDPR, which means retention periods and access controls are part of the build.
The picture changes once you hold customer funds or initiate payments on behalf of others. At that point you move into FCA territory as a payment or e-money institution, with capital and safeguarding obligations attached. In our experience building EMI-licensed payment platforms such as Globus Payments, compliance is far cheaper to design in early than to retrofit later.
Should You Build Your Own Payment Gateway Instead?
Building your own gateway is a serious commitment, and for most businesses integrating a provider is the faster and safer route. There are cases where it is the correct call.
When a Custom Build Is the Right Call
Four situations justify it. You process very high volumes, where small gains in routing or authorisation rate outweigh the build. You are selling a payment product, so the gateway is the thing customers pay for.
You run flows no provider supports, such as multi-party marketplace settlement or specialised B2B billing. Or you need raw authorisation and fraud data to run your own risk models. We took the first and second route together with FiatGate, a white-label non-custodial exchange where the payment infrastructure was the product.
What a Custom Build Commits You To
Ownership of a gateway means owning everything underneath it. You negotiate acquirer relationships and card scheme agreements, then maintain an integration for each one, including scheme-specific error handling.
You certify for 3-D Secure 2, run a tokenisation vault, and carry PCI DSS at full scope with audits, scanning and penetration testing. You staff fraud monitoring and chargeback handling. Depending on your model, you may need FCA authorisation before you take a single payment.
None of that is a reason to avoid building. It is a reason to be certain the product needs it, and to plan for a permanent team rather than a project. Specialist payment software development turns that commitment into a system you can maintain.
Choosing the Route That Fits Your Business
The real decision in setting up payments is not how hard the integration is. It is how much compliance scope and operational ownership you want to carry, and step 4 is where you choose it.
Get that right and the remaining six steps are mostly execution. Get it wrong and you discover it during your first PCI validation, or during your first chargeback dispute.
At Prostrive, we build and integrate payment platforms for European startups and scale-ups, including EMI-licensed and non-custodial systems. If you want a team that plugs into yours and gets the compliance scope right first time, book a Discovery call. We will map out your setup together.
