Fintech companies build payment platforms across five layers, and the order rarely changes: the payment gateway, which handles transaction routing, tokenization, and marks the PCI DSS scope boundary; the processing and acquiring layer, where authorization, clearing, and settlement move through card networks and acquiring banks; the fraud and risk engine, scoring transactions in real time and managing chargebacks; the compliance and KYC/AML layer, covering identity verification, sanctions screening, and transaction monitoring; and the reconciliation and data layer, matching settlements and feeding reporting. Sequence matters more than component choice — each layer depends on the one beneath it, and early decisions on PCI scope and licensing structure cost far more to unwind later than to architect correctly the first time.
A payment platform is never built as a single project. It takes shape as a sequence of architecture decisions, each one closing off certain options for the ones that follow — the PCI DSS scope a team accepts at launch, for instance, still governs its compliance costs when volume reaches $100M, and a licensing structure chosen in month one can fix the go-live date no matter how quickly engineering moves after that. Most guides describe what a payment platform needs to do: process transactions, catch fraud, stay compliant. Few explain how fintech companies build payment platforms in practice — what gets built first, what gets bought instead, and where a decision that looks trivial at $1M in annual volume turns expensive at $50M.
This article follows that build sequence in order, walking through each of the core payment platform components: gateway integration, acquiring relationships, fraud infrastructure, compliance architecture, and the data layer most teams underbuild early and rebuild later. For any team approaching fintech software development for the first time, understanding this payment infrastructure fintech stack end to end is what separates a platform designed to scale from one that gets rebuilt under pressure.
Where Every Payment Platform Starts: The Gateway Layer
The first thing any fintech company builds — or, more precisely, integrates — is a payment gateway. Every transaction passes through this layer first, and how a team approaches payment gateway integration shapes decisions with a longer tail than anything built afterward.
What the Payment Gateway Layer Actually Consists Of
Four components sit under “gateway”: an API layer accepting and validating requests, a tokenization service replacing card data with a token before it reaches a backend, a routing engine choosing the processor — increasingly a distinct challenge for platforms handling mobile payment gateway integration across multiple markets — and an authentication module handling 3DS2 for SCA.
Tokenization matters most — it has to happen client-side, in the browser or mobile SDK, before credit card data touches the platform’s servers, while sensitive payment data should be protected with strong encryption protocols like TLS in transit and encryption at rest.
That placement sets the PCI DSS scope for the whole company: tokenize client-side and qualify for SAQ A or SAQ A-EP; accept raw card data server-side and face PCI DSS Level 1 or 2 certification, plus an annual QSA audit — six to nine months of avoidable compliance work, and PCI DSS outlines key requirements for encrypting this payment information.
What Happens in the Two Seconds Before “Payment Successful”
In the payment portal, a customer enters payment details, the SDK tokenizes the customer’s payment information on the spot, and the token travels to the platform’s servers, where routing logic picks the processor and, if SCA applies, authentication runs before routing completes. All of it resolves in two or three seconds — four systems making and confirming a decision before “Payment successful” appears. This transaction process is what allows a business to accept credit card payments securely and deliver a smooth experience across online transactions.
Build, Integrate, or License — What This Layer Actually Requires
Almost no fintech company writes a gateway from scratch, because creating a payment gateway and the wider payment gateway building effort demand deep expertise. Most integrate an existing one (Stripe, Adyen, Checkout.com) while keeping control over tokenization behavior and routing logic — the two decisions that determine PCI scope and flexibility for everything built afterward.
The build vs. buy decision here isn’t binary, and teams weighing whether to build a payment gateway from scratch should also factor in what that build actually costs: a custom payment gateway commonly runs about €1,000,000 to €10,000,000, and even an MVP can take up to six months. Beyond the initial build, teams should also weigh the ongoing costs of maintenance, monitoring, and certification renewals. By contrast, using a third-party provider reduces much of the compliance and maintenance burden.
The PCI Scope Decision — Made Once, Affects Everything
For most teams, client-side tokenization is the right call, full stop — the UX benefits of handling raw card data are largely achievable anyway through hosted fields or embedded elements, and robust security measures plus data security requirements extend beyond PCI DSS Level 1 certification when EU customer data is involved. GDPR mandates strict consent and retention requirements for EU data, so teams should define storage boundaries early, based on their specific business requirements.
Teams that choose server-side handling to “keep flexibility” usually end up either pushing through PCI DSS Level 1 certification or retrofitting client-side tokenization later, a harder migration since the whole payment flow was built around raw card numbers. Getting this right at the outset is cheaper than fixing it after, especially once sensitive data enters scope — which is exactly why a gateway security audit early in the build, paired with a clear view of gateway compliance and security requirements, tends to pay for itself many times over.
Third-Party Gateway vs. Custom Build — and Why Most Teams Stay Bought Longer Than They Expect
The build-vs-buy decision isn’t about quality — Stripe, Adyen, and peers already run production-grade systems at trillions in volume. It’s about economics: past roughly $50M–$100M in annual volume, many teams consider an own payment gateway or a proprietary payment gateway once payment service fees overtake the cost of ownership. Saving $0.05 per transaction on 1 million transactions can recover build costs, and processing 5 million transactions can deliver about $250,000 in annual cost savings.
Most teams stay bought well past that point anyway, since their engineering bandwidth is busy shipping the features driving the volume growth that would justify the build. A custom build, when it happens, includes the core payment gateway services needed to run your stack: a custom API layer, a tokenization vault, a routing engine, and a connection into acquiring relationships — which can’t be built at all, only licensed or sponsored separately.
Processing, Acquiring, and the Economics of Settlement
The processing and acquiring layer is the part of the payment stack fintech companies almost never build. Card networks like Visa and Mastercard, the acquiring banks behind them, and the messaging standards connecting them (cross-border messaging just finished migrating to ISO 20022) represent decades of infrastructure no startup sprint will replicate — which is why most teams researching how to build a payment processing app quickly find the real build sits one layer up, not in the network itself. For a broader view of the landscape these payment networks operate within, see this e-payment systems guide. What fintech companies build instead sits one layer above it.
What the Processing Layer Does and Why Fintech Companies Don’t Build It
When a customer pays, the gateway sends an authorization request to the card network, which routes it to the cardholder’s bank; from there, the payment processor and payment processing services handling the flow move funds through settlement toward the merchant account and eventually the merchant’s bank account, typically T+1 to T+3. Direct acquiring relationships require a banking license or sponsorship through a licensed acquiring bank, with payment service provider models as the usual alternative and licensing alone running six to twelve months plus significant capital reserves. Maintaining that relationship also means running network-level fraud monitoring, chargeback management, and BIN sponsorship compliance as full operational functions — which is why most fintech companies only get the economics right at $100M or more in annual volume within a specific corridor.
What Fintech Companies Do Build Above the Processing Layer
The economics of digital payments and online payments usually live in the layer above acquired processing, in three parts: a routing engine directing transactions to different acquirers based on card type, geography, authorization rate, or transaction volumes (typically delivering 10–30 basis points in effective rate reduction at scale), multi-currency settlement management — the same logic underpinning most money transfer app builds — that supports local payment methods and broader multiple payment methods by converting at strategic moments instead of the processor’s spot rate, and, for marketplace and PayFac platforms, a fee calculation engine handling split payouts, settlement reporting, and recurring payments. This routing engine relates to the gateway’s orchestration layer, but solves a different problem: gateway orchestration routes between gateway connections, while acquiring routing routes between direct acquiring relationships, and high-volume platforms often need both.
Fraud Detection: What Changes as Transaction Volume Grows
Every fintech payment platform architecture needs a fraud layer on day one. What that layer looks like on day one and what it looks like two years later are usually two different systems — fraud detection follows a buy-first, build-later arc, and the transition point is more specific than most teams assume.
Why Third-Party Fraud Tools Are Correct at Launch
Third-party tools like Sift, Forter, SEON, Signifyd, or Kount win at launch not because they’re better in principle, but because they carry data a young platform hasn’t generated yet. A model trained on 50,000 transactions generalizes poorly; a vendor model trained across millions can surface patterns no early-stage platform’s history could reveal alone.
Andrii Semitkin
Delivery Director at SPD Technology
“At low volume, buying cross-network intelligence isn’t a shortcut — it’s close to the only path to competitive fraud detection. A platform’s own transaction history simply hasn’t lived long enough to teach a model anything a vendor’s network hasn’t already seen a thousand times over.”
In practice, a third-party scoring API sits in the flow after the payment request lands and before authorization, returning a fraud score in 200–300ms, after which rules accept, flag, or decline based on that score plus platform-specific velocity rules — a critical check for financial institutions that need to catch fraud before sufficient funds are moved.
When Building In-House Makes Sense — and What It Actually Requires
The trigger is specific: around one million monthly transactions, a platform’s own data gets rich enough for custom models to beat generic ones. Below that, custom models fight a data volume problem they can’t win. Above it, domain-specific signals — customer behavior, merchant-specific fraud vectors, geographic concentration — give in-house models a real edge.
The build requires technical expertise, a feature store, a training and evaluation pipeline, backend services often built with Python, Java, or Go, a microservices architecture for independent scaling, sub-100ms serving infrastructure, and drift detection, since fraud patterns shift enough that a model accurate at launch can degrade meaningfully within 90 days. Cloud infrastructure is commonly used to support high availability and a seamless payment experience, because downtime directly impacts payment transactions and revenue.
Andrii Semitkin
Delivery Director at SPD Technology
“The model itself is usually the smallest part of the engineering work. The feature store and the drift detection loop wrapped around it are where most of the effort — and most of the ongoing maintenance burden — actually goes.”
For teams weighing this transition directly, it’s worth comparing in-house fraud systems against SaaS fraud tools on the specific cost and control tradeoffs, and looking at where AI in fraud detection is heading alongside fraud detection with machine learning techniques more broadly.
For PayFac and Marketplace Platforms — Adding the Merchant Risk Layer
PayFac platforms — standing in as merchant of record for sub-merchants — carry a layer B2C platforms don’t need: merchant risk monitoring, tracking chargeback ratios, refund rates, and volume drift across every sub-merchant. This isn’t optional. Visa’s VAMP and Mastercard’s ECP programs put acquirers on notice once portfolio chargeback ratios cross defined thresholds, and the acquirer or PayFac must show active monitoring and remediation.
A PayFac without it is accumulating regulatory exposure with every merchant onboarded. Building merchant risk monitoring at scale ties closely into broader merchant lifecycle management practices, and it’s a key reason the payments industry treats risk infrastructure as inseparable from onboarding itself.
Compliance, Licensing, and Why These Determine Your Go-Live Date
Of all the architecture decisions in a payment platform build, the compliance and licensing track is the one most likely to decide when the platform actually goes live. That’s not because compliance is technically simple — it’s that the licensing timeline runs on a regulator’s clock, not an engineering one, and most teams don’t learn this until they’re six months into the build.
What the Licensing Track Requires and Why It Runs in Parallel
A platform that holds funds, moves money between parties, or issues payment instruments needs a money transmitter license in the US — 48 states each run their own MTL process — or a Payment Institution/EMI authorization in the EU under PSD2. State regulators review applications on their own schedule, typically six to eighteen months per state, and none of that is the company’s to control.
A platform that waits until engineering is finished to start licensing goes live six to eighteen months later than it could have; one that files on day one and runs licensing alongside engineering never lets the timeline become the constraint. One alternative for early-stage platforms in a hurry: launch through a licensed third party — a bank partner, BaaS provider, or existing money transmitter — while applying for direct licenses in parallel.
KYC and KYB — What Gets Bought and What Gets Built
KYC verifies individual identity — document checks, liveness detection, matching name, DOB, and SSN against credit bureau or government data. KYB verifies business entities through state registration lookups, EIN verification, and, under FinCEN’s Customer Due Diligence rule, identification of every beneficial owner holding 25% or more of the business.
Nearly every platform buys this from providers like Jumio, Onfido, Persona, or Stripe Identity and integrates by API; what gets built is the onboarding workflow around it — orchestrating verification, handling failures (10–30% of applications need manual follow-up), and routing approved applicants to account creation. Custom KYC stays rare, limited to very high-volume platforms or regulated verticals needing deep case-management integration.
AML Monitoring — the Layer That Grows With the Platform
Where KYC verifies identity once at onboarding, AML monitoring runs continuously on every transaction, aggregating patterns to surface money laundering indicators, structuring, or other suspicious activity, and generating SARs when they appear. Most platforms launch on third-party AML platforms like Sardine, Actimize, or NICE Actimize with pre-configured rules and SAR workflows already built in. As volume grows, the case for training AML models on internal data strengthens, since patterns specific to one platform’s user base are better caught by a model trained on that population than a generic one. This sits within the broader frame of payment processing compliance and the secure payment best practices that govern it.
The Data and Reconciliation Layer: The Component That Gets Rebuilt
The data and reconciliation layer is usually the last thing prioritized before launch and the first thing causing problems a year later. Processor-provided reporting holds up at $2M in annual volume — it stops holding up once a platform runs multiple providers, computes its own fees, and has an audit on the calendar.
What Reconciliation Actually Requires at Scale
Reconciliation means three workflows running correctly at once within your payment infrastructure ledger, which records every financial event to ensure accurate reconciliation: settlement reconciliation (confirming every transaction settled correctly within 48 hours), fee reconciliation (computing exact interchange and markup per transaction), and chargeback reconciliation (tracking disputes from notification through resolution, including reversals tied to bank transfers as well as card transactions). A custom pipeline built at design time costs a fraction of one built retroactively, because even successful payments still need ledgering and reconciliation to be auditable — the data model chosen at the processing layer determines how painful that retrofit becomes.
Why the Analytics Layer Is Where the Platform’s Strategic Value Lives
Payment data is among the richest a business generates, signaling customer behavior, fraud patterns, and market dynamics at once. Platforms treating it as a compliance artifact leave value on the table; those treating it as a strategic asset build fraud models and reporting competitors can’t easily copy — precisely the argument behind treating data analytics in finance as a competitive lever rather than a reporting obligation, and why financial business intelligence tooling matters as much as the transaction engine itself. Most start with processor exports in a BI tool, then rebuild once cross-provider reporting outgrows it — building the data infrastructure and warehouse right the first time is cheaper than the rebuild.
Build vs Buy: How the Decision Changes at Each Stage
The right answer on build vs. buy differs by component and shifts as the platform scales — what’s correct at $5M in annual volume is often wrong at $100M. The table below maps that decision as a stage-aware framework rather than a binary choice, since understanding each component’s transition point is part of what separates teams that design for scale from teams that rebuild under pressure.
Component | Bought at Launch | Build Trigger | What Gets Built |
|---|---|---|---|
Payment Gateway | Stripe, Adyen, Checkout.com, or another third party provider; PCI compliance managed by vendor | > $50M–$100M annual processing volume; product requires customization | Custom payment gateway with custom API layer, client-side tokenization vault, routing engine, direct acquirer connections, and baseline support for credit and debit cards and debit card payments |
Processing & Acquiring | PSP or PayFac model via a payment service provider; direct acquiring not feasible without license | > $100M in a specific corridor; banking license or BIN sponsor secured | Routing layer, multi-currency settlement management, fee calculation engine |
Fraud & Risk | Sift, Forter, SEON; cross-network intelligence unavailable internally at early stage | > 1M monthly transactions; domain-specific fraud patterns underserved by vendor models | Feature store, ML scoring pipeline, behavioral baselines, drift detection, merchant risk layer (PayFac platforms) |
Compliance & KYC/AML | Jumio, Onfido, Persona for KYC; Sardine, Actimize for AML | High onboarding volume makes per-verification fees significant; regulatory control requires proprietary audit trail | KYC orchestration workflow, AML model on platform transaction data, SAR workflow automation |
Data & Reconciliation | Processor-provided reports and exports; basic BI tool | Cross-provider reporting needed; fee attribution requires transaction-level calculation; regulatory audit on calendar | Custom data warehouse, ETL from all providers, reconciliation automation, analytics-ready data model |
Component
Payment Gateway
Processing & Acquiring
Fraud & Risk
Compliance & KYC/AML
Data & Reconciliation
Bought at Launch
Stripe, Adyen, Checkout.com, or another third party provider; PCI compliance managed by vendor
PSP or PayFac model via a payment service provider; direct acquiring not feasible without license
Sift, Forter, SEON; cross-network intelligence unavailable internally at early stage
Jumio, Onfido, Persona for KYC; Sardine, Actimize for AML
Processor-provided reports and exports; basic BI tool
Build Trigger
> $50M–$100M annual processing volume; product requires customization
> $100M in a specific corridor; banking license or BIN sponsor secured
> 1M monthly transactions; domain-specific fraud patterns underserved by vendor models
High onboarding volume makes per-verification fees significant; regulatory control requires proprietary audit trail
Cross-provider reporting needed; fee attribution requires transaction-level calculation; regulatory audit on calendar
What Gets Built
Custom payment gateway with custom API layer, client-side tokenization vault, routing engine, direct acquirer connections, and baseline support for credit and debit cards and debit card payments
Routing layer, multi-currency settlement management, fee calculation engine
Feature store, ML scoring pipeline, behavioral baselines, drift detection, merchant risk layer (PayFac platforms)
KYC orchestration workflow, AML model on platform transaction data, SAR workflow automation
Custom data warehouse, ETL from all providers, reconciliation automation, analytics-ready data model
The components built earliest — gateway and compliance — are also the hardest to unwind later, which is exactly why the architecture decisions made at those two layers carry the most long-term weight of anything in the stack.
SPD Technology: Fintech Payment Platform Engineering in Practice
Building a payment platform means solving problems most software teams never encounter — PCI scope decisions, PayFac transaction economics, fraud systems that outgrow vendor tooling, compliance workflows running in parallel with a licensing clock. SPD Technology works specifically in this space: gateway architecture, PayFac infrastructure, fraud and risk engineering, compliance workflows, and settlement platforms, across engagements spanning years rather than single projects.
Payment Processing and PayFac Infrastructure — Poynt
Poynt needed a full payment processing system, not a gateway integration, and needed it fast — SPD Technology delivered an all-in-one omnicommerce payment system with full-cycle processing, settlement, and a third-party integration API in five months, on a partnership that has now run more than five years.
The PayFac model built into that system illustrates the transaction cost economics this article’s processing section describes directly. The same partnership later underwrote more than 5 million applications in a single year and cut 30 hours of manual work daily thanks to automating merchant onboarding.
Fraud Detection and Risk Engineering at Scale
Underwriting more than 5 million applications in a single year is exactly the volume at which generic, rules-based fraud approaches stop working and custom risk scoring becomes necessary — the same threshold this article’s fraud section identifies around one million monthly transactions.
SPD Technology’s fraud detection and risk management work on that system doubled the merchant termination rate through true-positive alerting. A related engagement, the aggregated merchant portal built for BHN, onboarded more than 8,000 US businesses in two years while cutting onboarding time from seven days to under 24 hours, automating OFAC, EIN, and SSN checks along the way.
Fintech Platforms at Scale — Settlement, Data, and Long-Term Partnership
The merchant settlement platform SPD Technology built for BHN now serves more than 37,000 users, automating report generation and commission calculation on a partnership running more than seven years — precisely the settlement automation problem the data and reconciliation section describes.
SPD Technology also built an SMB funding platform from scratch in 18 months, facilitating more than $350M in financing for 4,000-plus businesses while staying PCI DSS, GDPR, and KYC/KYB compliant throughout — a build that ran compliance and engineering in parallel from day one, the same sequencing this article argues for.
A third engagement, the real-time card-linked rewards platform, runs an event-driven architecture with Plaid connectivity, sub-second reward attribution, and 48–72 hour payout readiness.
Across gateway architecture, PCI scoping, fraud systems, compliance workflows, and settlement infrastructure, this is the layer of the stack SPD Technology has actually built — which is the conversation worth having before deciding what to build next.
Key Takeaways
- Payment platform architecture is built in sequence, not in parallel — the gateway layer sets the PCI scope that defines compliance costs for every layer built afterward, and decisions made at that first layer are the most expensive to change later.
- Client-side tokenization keeps raw card data out of platform servers, qualifying most fintech platforms for SAQ A or SAQ A-EP; accepting raw card data instead requires PCI DSS Level 1 or Level 2 certification, adding 6–9 months of compliance work.
- With digital payments reaching $121.53 billion in 2025 and projected to grow at a 19.43% CAGR, buying the gateway and fraud layers is correct at launch because vendor networks supply cross-platform intelligence no early-stage transaction history can match, but building in-house becomes cost-positive at different volume thresholds — roughly $50M–$100M for the gateway, $100M–$200M for fraud.
- Regulatory licensing runs as a parallel build track, not a post-engineering step — a US money transmitter license takes 6–18 months per state across 48 states, and platforms that start licensing after engineering finishes add that full timeline directly to their go-live date.
- The data and reconciliation layer is the component most often underinvested at launch, and processor-provided reporting that’s adequate at low volume becomes inadequate the moment a platform adds a second payment provider, its own fee calculations, or a regulatory audit.
- Most fintech platforms reach payment orchestration without realizing it, adding a second gateway and managing routing logic directly in application code — the better time to build or buy a dedicated orchestration layer is when that second gateway is added, before routing logic accumulates across services.
In short: payment platform architecture is a sequence of compounding decisions — get the gateway’s PCI scope, the licensing timeline, and the reconciliation model right early, and every layer built afterward inherits that advantage instead of its cost.
FAQ
How long does it take to build a fintech payment platform from scratch?
A minimum viable platform built from scratch to create a payment experience takes 3–6 months; a production-grade one with custom fraud models and orchestration takes 12–24 months. A payment application may cost roughly $150,000 to $2,000,000+, while a comprehensive web payment app often lands around $1,500,000 to $2,000,000+. The scope difference is real engineering time, but the risk most teams miss is regulatory licensing — it often sets the go-live date more than engineering speed does. At SPD Technology, we start licensing on day one, running it parallel to the build rather than after, so the platform can support local payment methods and roll out new payment methods without a compliance bottleneck later.
What is the PayFac model and when should a fintech build on it?
A payment facilitator, or PayFac, steps in as merchant of record for its sub-merchants — a role that cuts onboarding from weeks down to minutes and lets the platform earn directly on processing margin instead of just passing transactions through. None of that speed comes free, though: the PayFac takes on KYB obligations for every sub-merchant, has to run risk monitoring continuously rather than at a single point in time, and needs capital reserves sized to whatever the sponsoring bank requires. SPD Technology’s own PayFac builds bear this out in practice — the economics only work when monitoring is designed in from day one, not added after a portfolio’s already accumulating risk.
What does PCI DSS compliance mean for a fintech building a payment platform?
PCI DSS governs how cardholder data is stored, processed, and transmitted, with compliance level set by annual volume — Level 1 (6M+ transactions/year) requires a QSA audit, Level 2 a self-assessment questionnaire. Client-side tokenization is the most effective scope reduction, keeping raw card numbers off the backend entirely. Get this wrong at launch, and a platform ends up needing an audit one early architectural choice could have avoided.
What payment standards does a fintech payment platform need to implement?
Core standards include PCI DSS for cardholder data, ISO 8583 for authorization messaging, EMV for chip transactions, 3DS2 for PSD2 authentication, and increasingly ISO 20022 for cross-border payments. Skip 3DS2, for example, and EU transactions start failing Strong Customer Authentication at checkout. Jurisdiction-specific AML requirements — SAR filing, beneficial ownership verification under FinCEN’s CDD rule — apply on top of all of these.
What is payment orchestration and does every fintech payment platform need it?
Orchestration is a routing layer sitting above multiple gateways, directing transactions to the best provider by cost, authorization rate, or failover logic. Most platforms don’t need it below roughly $20M in annual volume. The problem shows up when a second provider gets added without it — routing logic scatters across application code, and reporting becomes manual. At that point, teams choose custom or a platform like Spreedly or Primer.