Behind every “Pay now” button sits a chain of decisions that shapes a fintech’s cost base, its compliance exposure and, ultimately, how many customers actually complete a purchase. Choosing payment software and a payment gateway is one of the most consequential technology decisions a fintech, marketplace or digital business makes—yet it is often reduced to a comparison of transaction fees. Fees matter, but they are rarely where the real risk or the real value lives.
This guide looks at payment gateways and payment software from a compliance and decision-maker perspective: what these systems actually do, where the regulatory obligations sit, and how to evaluate providers without inventing certainty that does not exist. It is general information for business and compliance leaders, not legal or regulatory advice; specific obligations depend on your jurisdiction, licenses and business model, and should be confirmed with qualified counsel.
Payment gateway, processor, acquirer: untangling the terms
The payments stack is full of overlapping terms, and clarity here prevents expensive misunderstandings during vendor selection. A payment gateway is the software layer that securely captures payment details and passes them into the payment network—think of it as the secure front door. A payment processor routes the transaction between the customer’s bank and the merchant’s bank and handles the mechanics of moving money. An acquiring bank (acquirer) is the licensed institution that holds the merchant account and settles funds. A payment service provider (PSP) often bundles several of these roles into a single commercial relationship.
Some providers offer the entire chain as one integrated product; others specialize in a single layer. Neither model is inherently better, but you cannot evaluate cost, control or compliance responsibility until you know which parts of the chain a given vendor actually owns—and which parts remain yours.
PCI DSS: the baseline that is not optional
Any business that stores, processes or transmits cardholder data falls within the scope of the Payment Card Industry Data Security Standard (PCI DSS). As of 2026, PCI DSS v4.0.1 is the active version of the standard; the earlier v4.0 was retired at the end of 2024, and requirements that had been designated “future-dated best practices” became mandatory on 31 March 2025. In practical terms, there is no earlier version to fall back on—assessments now reference v4.0.1.
For decision-makers, the strategic question is less about memorizing controls and more about scope. The more cardholder data your systems touch, the heavier your compliance burden. This is why many businesses deliberately choose architectures—such as hosted payment pages or tokenization—that reduce how much sensitive data ever reaches their own environment. A provider that minimizes your PCI scope can save far more in audit effort and risk than a slightly lower per-transaction fee. When comparing vendors, ask precisely how their integration affects your PCI scope, and treat that answer as a first-class selection criterion.
Tokenization, encryption and 3-D Secure
Three capabilities do most of the heavy lifting in modern payment security, and each has a compliance dimension worth understanding.
- Tokenization replaces card numbers with non-sensitive substitute values, so the real data never sits in your systems. This both reduces PCI scope and limits the damage of a breach.
- Encryption (in transit and at rest) protects data as it moves and where it is stored. It is a baseline expectation, not a differentiator—but its absence is a red flag.
- 3-D Secure adds an authentication step that can shift certain fraud liability and supports Strong Customer Authentication (SCA) requirements that apply in markets such as the European Economic Area under PSD2.
These controls also intersect with fraud strategy. Authentication reduces some fraud but can add checkout friction, and the balance between the two is a business decision as much as a technical one. That trade-off connects directly to the wider discipline of fraud and chargeback management, where authentication, monitoring and dispute handling all pull on the same lever.
Compliance obligations beyond card security
Payment software rarely lives in isolation from the rest of a fintech’s compliance stack. Depending on your model and jurisdiction, moving money can trigger obligations well beyond PCI DSS.
| Obligation area | Why it applies to payments | Typical touchpoint |
|---|---|---|
| KYC / customer due diligence | Onboarding merchants or account holders who move funds | Identity verification at signup |
| AML transaction monitoring | Detecting suspicious payment patterns | Ongoing screening of flows |
| Sanctions screening | Preventing prohibited parties from transacting | Real-time checks at payment |
| Data protection | Personal and payment data handling | Storage, access and residency controls |
| Safeguarding (where licensed) | Protecting customer funds held by the business | Segregated accounts and reconciliation |
The point is not that every business carries every obligation, but that a payment integration frequently becomes the trigger point for several of them at once. Onboarding a paying merchant, for example, is exactly where KYC verification and payment enablement meet—and where gaps between the two systems create both fraud risk and regulatory exposure.
Evaluating a payment provider: a decision-maker’s checklist
Once the vocabulary and obligations are clear, provider evaluation becomes a structured exercise rather than a fee comparison. Useful questions include:
- Scope impact: How does this integration change our PCI DSS scope and our data-handling responsibilities?
- Coverage: Which payment methods, currencies and regions are supported today—and which are on the roadmap versus already live?
- Reliability: What are the provider’s uptime commitments and how is degraded service communicated and compensated?
- Cost transparency: Beyond the headline rate, what are the fees for refunds, chargebacks, currency conversion and failed transactions?
- Reconciliation and reporting: How easily can finance teams reconcile settlements and export auditable records?
- Exit and portability: If we leave, how do we retrieve tokens, data and configurations without re-onboarding every customer?
The last point deserves emphasis. Switching payment providers is disruptive precisely because tokens and stored credentials are often tied to a single vendor. Asking about portability before you sign is far cheaper than discovering the lock-in after you have outgrown the provider. This kind of structured, evidence-based approach mirrors the discipline used across other digital wallet and e-money compliance decisions, where operational lock-in and regulatory scope must be weighed together.
Build, buy, or orchestrate?
A recurring strategic question is whether to integrate a single provider, build in-house, or adopt a payment orchestration layer that routes transactions across multiple providers. Building a payment core in-house is rarely justified for most businesses; the compliance burden and maintenance cost are substantial, and the capability is seldom a competitive differentiator. Integrating an established provider is the default for good reason.
Orchestration—sitting a routing layer above several providers—can improve resilience, acceptance rates and negotiating leverage, but it adds its own complexity and cost. It tends to make sense at scale, where the volume justifies the overhead, rather than at launch. As with most infrastructure choices, the honest answer depends on transaction volume, geographic spread and internal capacity, not on which option sounds most sophisticated.
Frequently asked questions
Does using a payment gateway make us automatically PCI compliant?
No. A well-chosen gateway can dramatically reduce your PCI scope, but compliance remains your responsibility for the parts of the flow your systems still touch. Always confirm exactly which obligations the provider covers and which remain with you.
Is the cheapest provider usually the right one?
Not reliably. Headline transaction rates can hide costs in refunds, chargebacks, currency conversion and integration effort—and a provider that expands your compliance scope can cost far more than it saves. Total cost and risk matter more than the per-transaction rate.
What is the difference between a gateway and a PSP?
A gateway is specifically the software that captures and transmits payment data, while a payment service provider typically bundles the gateway, processing and sometimes the merchant account into one relationship. Many businesses use a PSP without ever contracting a standalone gateway.
How does payment choice affect fraud exposure?
Significantly. Features such as tokenization, 3-D Secure and built-in monitoring shape both how much fraud you absorb and how disputes are handled, which is why payment selection and fraud strategy should be evaluated together rather than in isolation.
Conclusion
Choosing payment software and a gateway is a compliance decision dressed as a procurement one. The providers that serve a fintech best are those that reduce PCI scope, make regulatory responsibilities explicit, support the markets and methods the business actually needs, and do not trap customer tokens behind a costly exit. By evaluating coverage, cost transparency, security architecture and portability alongside the headline fee—and by treating fraud, KYC and monitoring as connected rather than separate—decision-makers can select a payment stack that supports growth instead of quietly constraining it.
This article is provided for general information only and does not constitute legal, regulatory or compliance advice. For a discussion of how payment, screening and monitoring capabilities fit together for your specific model, the team at DanuSoft is glad to help.