The Case for Building
Every platform CTO who considers building payment infrastructure in-house has good reasons.
You want full control over the payment experience. You don't want to depend on a vendor for a mission-critical flow. You've been burned by third-party APIs before: the latency, the breaking changes, the support tickets that go nowhere. Your engineering team is strong. Payments are "just APIs." How hard can it be?
These are reasonable instincts. And for a small number of companies, building is the right call.
But for most platforms, the build decision is based on an incomplete understanding of what "payment infrastructure" actually means. The gap between "integrate a PSP's API" and "run production payment infrastructure" is where the real cost lives, and it's dramatically larger than most CTOs estimate.
What You're Actually Building
The misconception is that payment infrastructure is primarily an API integration exercise. Connect to Stripe's API, handle webhooks, store transaction records. A senior engineer could prototype it in a sprint.
That prototype handles the happy path. Production payment infrastructure handles everything else.
The Integration Layer
A single PSP integration is straightforward. But platforms rarely stay on a single PSP. Enterprise customers mandate their own gateways. Geographic expansion requires region-specific providers. Pricing optimisation demands routing between providers.
Each PSP has its own API design, authentication model, error handling, webhook format, and idiosyncratic behaviour. Worldpay's API looks nothing like Adyen's, which looks nothing like Checkout.com's. Building an abstraction layer that normalises these differences, so your core platform doesn't need to know which PSP is processing a given transaction, is a significant engineering investment.
Tokenisation and Card Storage
If you're storing card data, or even passing it through your systems, you're in PCI scope. Most platforms use tokenisation to avoid this, but token management across multiple PSPs adds complexity. Tokens from Stripe don't work with Adyen. Network tokens behave differently than PSP-specific tokens. Managing token lifecycle, migration, and multi-PSP portability is non-trivial.
PCI Compliance
PCI DSS compliance is not a checkbox exercise. At service provider level, which is where platforms sit, the threshold for Level 1 is 300,000 transactions a year, against six million for merchants. Level 1 requires a Qualified Security Assessor (QSA) audit, penetration testing, vulnerability scanning, and ongoing monitoring.
The cost isn't just the audit. It's the infrastructure changes required to pass it. Network segmentation, encryption at rest, key management, access controls, logging, monitoring, and maintaining all of it continuously, not just at audit time.
PCI DSS 4.0, enforced since March 2025, raised the bar further with requirements for stronger encryption, mandatory multi-factor authentication, and continuous monitoring.
Reconciliation and Settlement
Every PSP settles differently. Different formats, different timelines, different fee structures. Building automated reconciliation that matches transactions to settlements across multiple PSPs, and catches discrepancies, is a substantial data engineering problem. At scale, this becomes a major operational cost.
Chargeback and Dispute Handling
Each PSP has its own dispute process, evidence requirements, response deadlines, and notification mechanisms. Building a unified dispute management layer that works across PSPs, with automated deadline tracking and evidence compilation, is its own product.
Multi-Currency and Regulatory Compliance
International payments introduce currency conversion, cross-border fees, local payment method support, and country-specific regulatory requirements (SCA in Europe, local acquiring in certain markets). Each adds a dimension of complexity.
The Real Cost
Time
A basic single-PSP integration takes months to get production-ready. That includes webhooks, error handling, retry logic, idempotency, reporting, and edge cases.
Building a multi-PSP abstraction layer, the kind that lets you add or remove PSPs as configuration rather than code, takes months with a dedicated team.
Becoming a PayFac (processing payments on behalf of sub-merchants) takes months and requires merchant underwriting, KYC/AML, fraud monitoring, and regulatory reporting.
Money
The initial build cost varies widely, but directionally:
Component | Cost |
|---|---|
Core integration (single PSP) | Months of engineering work |
Multi-PSP abstraction layer | Months of work for a dedicated team |
Reconciliation & reporting | A substantial data engineering project |
Dispute management | Effectively its own product |
These are engineering costs. They don't include the opportunity cost: what those engineers would have built for your core product instead.
The Maintenance Tax
The build cost is front-loaded, but the maintenance cost is permanent. PSPs change their APIs. New PCI requirements come into force. Payment regulations evolve. Security vulnerabilities need patching. Each of these requires your team's attention, indefinitely.
Large payment companies employ teams of hundreds dedicated to maintaining payment infrastructure. They can amortise that cost across thousands of customers. A platform maintaining its own payment infrastructure carries the full burden alone.
When to Build
Building makes sense when payments ARE your core product: when the competitive advantage of your business comes from owning the payment flow end-to-end.
Specifically, build if:
You are a payment company. If your primary revenue model is payment processing, building proprietary infrastructure is defensible. Stripe built their own infrastructure because they ARE a payment company.
You need sub-transaction-level control. If your business model requires manipulating payment flows at a level of granularity that no third party can provide (custom routing algorithms, proprietary risk scoring), building may be necessary.
Payment infrastructure is your moat. If owning the payment flow creates a competitive advantage that justifies the ongoing investment, the build decision is strategic.
For most platforms, none of these apply. Payments are infrastructure that enables the core product. They're important, but they're not the product itself.
When to Buy
Buy when payments are a required capability of your platform but not your competitive differentiator. This applies to the majority of software platforms.
The signals:
Your engineers are building payment features instead of core product. If your roadmap keeps getting hijacked by payment integrations, you're spending engineering capital on the wrong problem.
Enterprise customers are demanding PSPs you don't support. Every custom PSP integration is months of engineering time. A payment layer gives you 40+ PSPs through one integration.
PCI compliance is consuming security resources. If your security team is spending months on PCI audits rather than securing your core application, you're carrying compliance burden that can be reduced.
You're evaluating becoming a PayFac. In most cases, the economics that drove the PayFac model have changed. Managed models now offer comparable economics without the regulatory burden.
The Middle Path: PSP-Neutral Abstraction
The build vs buy framing suggests a binary choice. In practice, there's a middle path that gives platforms the benefits of both: integrate with a PSP-neutral payment layer that provides the abstraction you'd build, without the cost of building it.
This is how Shuttle works. Platforms integrate once. That single integration connects to 40+ PSPs. Adding or removing a PSP is configuration, not a code change, and saved cards stay with the gateway that stored them. Card data never enters the platform's environment, which limits the platform's PCI scope; platforms complete SAQ-D, with less of it applying to their own systems, and everyone taking card payments has to be PCI compliant.
The platform retains control over the payment experience. White-label checkout, merchant onboarding, and transaction management are branded as the platform's own.
Crucially, this approach reduces PSP lock-in rather than creating it. Because the layer is PSP-neutral, the platform can switch the underlying PSP at any time, though saved cards stay with the gateway that stored them. The integration is with the layer, not with any individual PSP. That's more flexibility than building direct integrations, not less.
The Decision Framework
Factor | Build | Buy (Payment Layer) |
|---|---|---|
PCI scope | Full Level 1 | Merchants: SAQ-A. Platforms: SAQ-D (limited) |
Multi-PSP support | Each integration is a project | 40+ PSPs included |
Ongoing maintenance | Permanent engineering cost | Handled by provider |
Control over UX | Full | White-label |
PSP flexibility | Limited by what you've built | Add/remove as config |
Core product impact | Engineers diverted | Engineers stay focused |
The question isn't whether your team CAN build payment infrastructure. Most strong engineering teams can. The question is whether they SHOULD: whether that investment of time and money produces more value than spending those resources on the product your customers actually pay for.
For platforms where payments are infrastructure, not product, the answer is almost always to buy.