Payment Gateway Integration for Fintech Websites: PCI DSS Scope Guide

Your compliance officer signs off the licence. Your marketing team ships the new site. Then the payment provider asks one question nobody on the team can answer: which PCI DSS questionnaire does your deposit page fall under?

That answer decides how much audit work lands on you. Payment gateway integration looks like a developer task, but for a broker or fintech firm it is also a compliance decision and a conversion decision. The method you choose sets what your website must secure. The gateway you choose decides who will accept you as a merchant.

This guide covers how the integration works, where PCI DSS scope starts and stops, white label versus direct PSP, and what to budget. WSA builds the website layer for brokers and fintech firms, so the focus is on what your site touches, not on API code.

How Payment Gateway Integration Works on a Fintech Website

Payment gateway integration connects your website to a gateway that passes the customer's payment details to the acquirer and returns an approval or a decline. The gateway sits between your deposit page and the banks, so you never talk to Visa or Mastercard directly.

Think of it as a relay with strict handoffs. Your site starts the deposit. The gateway handles the sensitive part. Your site only hears the result.

What Happens Between "Deposit" and "Funds Received"

Here is the sequence a card deposit follows on most broker sites:

1. The client enters an amount on your deposit page and clicks pay.

2. Your site sends the client to the gateway's payment form, or loads that form inside your page.

3. The gateway converts the card number into a token and sends the request to the acquirer.

4. The client's bank approves or declines, often after a 3-D Secure check.

5. The gateway returns the result to your site, and your back office credits the trading account.

Where the Website Ends and the Gateway Begins

Here's where most teams lose clarity. They treat "the payment page" as one thing, when it is two: the part you build and the part the gateway builds.

A hosted payment page is built and run by the gateway. Tokenization is the process that replaces the card number with a random token, so your systems store a reference and never the card itself. A payment service provider (PSP) bundles the gateway, the acquiring relationship and often fraud tools into one contract.

Imagine you run a forex brokerage and your developer proposes a custom card form on your own domain "for a better look". The look improves. Your PCI DSS scope grows from a short self-assessment to a full audit programme. That trade-off should be a decision, not a surprise.

PCI DSS Scope: What Your Website Touches and What Stays Out

Your integration method decides your PCI DSS scope: a redirect keeps card data off your site, an iframe leaves your page responsible for script security, and a direct API puts card data on your servers and you in the heaviest questionnaire. The PCI Security Standards Council publishes the current standard, PCI DSS v4.0.1, in its document library.

The questionnaire a given merchant uses is set with its acquirer and its qualified security assessor, so treat the table as a starting map, not a ruling.

Redirect, Iframe, or Direct API: How Each Changes Your Scope

A redirect is the lightest option. The client leaves your domain, pays on the gateway's page and comes back. Your site never handles card data. The cost is brand continuity, because the page looks like someone else's.

An iframe keeps the look but shifts risk. The gateway's fields appear inside your page, so the experience feels like yours. Card data still goes straight to the gateway. But your page now surrounds a payment form, and that matters for the next point.

A direct API gives full control and full responsibility. Card data reaches your servers, so your whole environment is in scope. Few brokers need this.

In practice, most regulated firms choose a hosted page or an iframe and spend their effort on licensing, KYC and deposit conversion instead.

The 2025 Client-Side Script Requirements Nobody Mentions

Unlike a redirect, an iframe leaves your own page responsible for the scripts that run around the payment form. Requirements 6.4.3 and 11.6.1 in PCI DSS v4.0.1 cover this: they ask you to keep an inventory of scripts on payment pages and to detect unauthorised changes.

For SAQ A merchants, Report URI explains that these two requirements were taken out of the questionnaire in January 2025 and replaced by an eligibility condition: you must confirm your site is not susceptible to script-based attacks. The PCI SSC covers how to meet that condition in FAQ 1588.

Here's what that means for your site build:

• Set a Content Security Policy (CSP) that lists which scripts may run on the page.

• Add Subresource Integrity (SRI) hashes so a changed third-party file is blocked.

• Remove analytics, chat widgets and ad pixels from the page that hosts the payment form.

• Keep a written script inventory and a change log.

What this means: a deposit page full of marketing tags is a compliance risk, not just a speed problem. A full redirect avoids the issue because the payment page never sits on your domain.

White Label Payment Gateway or Direct PSP Integration?

The key difference is control versus speed: a white label payment gateway lets you run payments under your own brand, while direct PSP integration connects you to one provider's checkout and compliance stack. Neither one removes your own licensing and AML duties.

Side-by-Side Comparison for a Regulated Firm

Decta, a payment provider, describes the white label model as higher in upfront cost and lower in long-term cost. Treat that as a vendor view and ask for the fee schedule in writing.

Which Option Fits Which Broker

If you are launching in under three months with one payment method, direct PSP integration is usually the right start. You test demand before you invest in your own payment stack.

If you plan several providers, several regions or a branded cashier, a white label payment gateway pays back. You add routes without rebuilding the deposit page each time.

One honest limit: a white label payment gateway still needs a licensed acquirer behind it. The label changes the front end, not who approves your merchant account.

Which Gateways Work for Regulated Brokers

A gateway works for a regulated broker only if its acquirers accept your licence and your merchant category. Forex and CFD sit in a high-risk class for most acquirers, and the answer to "can you take us on?" often arrives before any pricing talk.

Use this checklist when you shortlist a provider:

1. Licence acceptance: does it accept your regulator and jurisdiction? Your forex brokerage licence will be the first document requested.

2. High-risk underwriting: is the provider set up for forex merchant categories, or will the account be frozen after launch?

3. Chargeback handling: brokers face elevated chargeback and refund rates, and payabl notes card schemes monitor merchant ratios, citing 1.5% for Visa.

4. Authentication: native 3-D Secure 2 support, which PSD2 strong customer authentication requires for card payments in Europe.

5. KYC/AML signals: transaction monitoring and a flow that places identity checks before the first deposit.

Your broker website compliance checklist covers the disclosures and risk warnings the same deposit page must show.

What Payment Gateway Integration Costs and How Long It Takes

Payment gateway integration cost has two parts: provider fees and build effort. Provider fees are published. Build effort depends on the method you choose.

Those ranges come from Shuttle Global's pricing guide. Brokers are often quoted above the typical band because of the high-risk category, so ask for your own quote.

Build effort follows the method, and these tiers are indicative:

• Hosted redirect: the lightest build, usually weeks rather than months.

• Iframe or embedded fields: more front-end work plus the CSP and script clean-up above.

• White label or multi-provider: a longer project, with about two months quoted for provider-side setup alone.

Here's where budgets slip: teams price the gateway and forget the website work, the testing and the compliance review. Add all three before you sign.

Designing a Deposit Flow That Converts and Stays Compliant

A client who reaches your deposit page has already decided to fund the account. What happens next is yours to lose. A redirect to an unfamiliar domain, an unexplained decline or a missing receipt all push that client back out.

Build the deposit page with these elements:

• Your logo and brand name on every step, including the hosted page where the gateway allows it.

• A plain explanation of the redirect before it happens ("You will complete payment on our secure payment partner's page").

• Visible payment-method choices with fees and processing times stated.

• Clear decline messages that name the next step, such as trying another card or method.

• Required risk warnings and regulatory disclosures on the page.

• No third-party marketing scripts on the page that hosts the payment form.

A broker whose deposit page redirects without warning to a page with another company's name invites doubt at the exact moment of payment. The fix is a short sentence and a consistent brand frame, not a redesign.

How WSA Handles the Website Side of Payments

WSA is a fintech web design agency that builds broker and fintech sites on Framer and Webflow. For payments, WSA's role is the website layer: the deposit page, the script hygiene around it, the content and the integration points to your chosen gateway. WSA does not provide payment services, PCI certification or legal advice.

That layer is where the practical work sits. WSA is a partner of B2BROKER, built the 70+ page CMS for B2CORE and delivered 50+ product pages for B2TRADER in six weeks, so large, structured fintech sites are routine work. See more broker and fintech websites in the portfolio.

On a typical project, WSA agrees the integration method with your payments and compliance leads first, then designs the deposit flow around it, then builds the page with a clean script setup. Your acquirer and assessor confirm the compliance outcome.

Conclusion

Payment gateway integration is a scope decision first and a technical task second. Pick the method that keeps card data off your servers, choose a gateway whose acquirers accept your licence, and decide early between a white label payment gateway and direct PSP integration.

Then build the deposit page as both a compliance page and a conversion page. Keep scripts clean, explain every redirect and show the disclosures your regulator expects.

WSA builds that website layer for brokers and fintech firms. If you are choosing a gateway or planning a new deposit flow, talk to WSA before the design is fixed.

FAQ

How does payment gateway integration work?

Connecting a payment gateway links your website to a service that securely passes payment details to the acquirer and returns an approval or decline. The client enters an amount and pays on a hosted page, an embedded form or a form you build. The gateway tokenizes the card, the acquirer asks the client's bank for authorisation, and the result returns to your site. Your back office then credits the account. How much of that process your own pages touch decides your PCI DSS scope.

What does a payment gateway integration cost?

The cost is a fee schedule plus build work. Typical UK-based card pricing is 1.5% to 3.5% plus 10p to 30p per transaction, with setup fees from £0 and chargeback fees of £15 to £25. Build effort ranges from weeks for a hosted redirect to a longer project for a white label or multi-provider setup. Brokers are often quoted above the typical band because of the high-risk category, so request a written quote from each provider.

White label gateway or direct integration?

Choose direct PSP integration to launch quickly in one market, and choose a white label gateway when you need brand control and several providers. Direct integration has lower upfront cost and ties you to one provider's checkout. A white label gateway costs more up front and typically takes about two months to set up, but lets you add routes without rebuilding your deposit page. Both still require you to meet your own licensing and AML duties.

Which gateways work for regulated brokers?

The gateways that work for regulated brokers are those whose acquirers accept your regulator, jurisdiction and merchant category. Look for high-risk underwriting, chargeback management, 3-D Secure 2 support and built-in KYC and AML monitoring. Ask each provider whether it already serves forex or CFD merchants in your jurisdiction, and request that confirmation in writing before you start the build.

What compliance applies to payment pages?

Payment pages fall under PCI DSS, currently v4.0.1, plus your financial regulator's rules on disclosures and risk warnings. PCI DSS scope depends on your integration method: a redirect is usually SAQ A, and an iframe is SAQ A with a condition that your page is not open to script attacks. Card payments in Europe also need strong customer authentication under PSD2. Confirm your questionnaire with your acquirer or a qualified security assessor. This article is general information, not legal or compliance advice.