What I Would Tell a Payments Team Starting from Scratch

A blank page shouldn’t be intimidating. Instead, look at it like a clean slate. Teams that get payments architecture right from day one have that same energy. The ones that don't? I've watched them spend years trying to navigate out of decisions they made in week one.

I've been in the payments industry long enough to know where the landmines are. There's one mis-scoped decision I see over and over again, a decision that looks small at the start but quietly determines what difficulty level your engineering team plays on for the next three years or more.

Start with who actually owns your payment data

Every time a customer checks out, they're trusting you with something valuable. That data has to live somewhere, and the default move for most teams is to let it sit in their payment gateway's vault. On paper, you own it. In practice, you're a tenant. And tenants don't set the terms.

The moment you try to move that data to a new gateway, better rates, or a new market, you find out how much control you actually don't have. You're wading through access requests, a lengthy migration process, and PCI scope creep you didn't budget for. In the worst case, you're asking customers to re-enter their card details, which is not just friction. It's churn, and it's revenue walking out the door.

The move that changes everything is vaulting your payment data independently of any gateway. With Spreedly's Advanced Vault, your tokenized payment data isn't tied to a single provider. It's portable, PCI Level 1 compliant, and ready to transact across virtually any gateway in an ecosystem of 100+ integrations. You vault once. You go anywhere.

I'll be straight with you: the longer you wait on this decision, the harder it gets. This is the kind of architectural call that pays you back compounding, but only if you make it early.

This matters more than which gateway you choose

I've talked to a lot of payments teams. Most of them spent weeks, sometimes months, in meetings and demos and budget negotiations with gateway providers. Meanwhile, the question of where payment data lives never came up. Gateway comes with a vault, vault is fine, moving on.

That assumption doesn't bite you on day one. It bites you when you're scaling into a new market and need a second gateway for redundancy, or a provider with better authorization rates in a specific region. That's when the lock-in surfaces, and by then you're not having a calm architectural conversation. You're in crisis mode, trying to retool your checkout while it's actively processing revenue.

The companies I've watched go through full payment infrastructure replatforms weren't failing businesses making desperate moves. They were growing fast, and the lock-in caught up with them at the worst possible moment.

Design for the second gateway before you need it

You probably don't need a second gateway today, but just go ahead and build like you do anyway. That mindset is one of the most valuable things I can pass on.

The pattern I've watched play out more times than I can count: first gateway, then a second, then a third. Each addition creates more complexity. Before long, your payments team isn't building, they're maintaining. New features stall because they touch in-scope systems. Every sprint is dominated by infrastructure work instead of product work. The payments team becomes the payments maintenance team.

The root cause is almost always the same: a checkout built directly on a single gateway's API, with no abstraction layer underneath.

Spreedly flips that model. Connect once to the platform, and you can route transactions to any gateway in the ecosystem, based on performance, cost, geography, or whatever logic your strategy calls for. Adding a new gateway isn't an engineering project. It's a configuration. The difference between six months of work and clicking a toggle is not an exaggeration.

Your gateway isn't a partner for life. It's a dependency you can dial up, dial down, or swap out entirely. That's not disloyal. It's strategic. And it's exactly the kind of optionality Spreedly is built to give you.

Provider optionality is also a negotiating weapon

I'm a salesperson, so I'll just say it plainly. Gateway providers know exactly which customers are locked in and which ones can move volume with relative ease.

Guess which group gets better rates, better settlement terms, and faster SLA responses?

When you're vaulted independently and routing through an orchestration layer, you're not a captive. You have leverage. Your CFO will notice. Spreedly customers are in a fundamentally different negotiating position than those who've handed over the keys to a single provider.

PCI scope is an architecture decision, not a compliance task

PCI scope creep kills velocity. I've seen it happen to teams who were growing fast, building confidently, and didn't notice the walls closing in until compliance work was eating half their sprints.

Every system that touches, stores, transmits, or processes raw card data is in scope. Every in-scope system needs to be audited. Every audit costs time, money, and engineering focus. As your stack grows, the scope snowballs.

The fix is making sure raw card data never touches your internal systems in the first place. Spreedly handles this with hosted payment fields that capture card data directly, tokenization at point of capture, and a provider-agnostic vault that keeps your environment clean. Your engineers stay out of PCI scope. Your audits stay manageable. Your product roadmap stays on track.

As of early 2025, only about 32% of organizations felt fully prepared for the PCI DSS 4.0 transition, but 74% already rely on tokenization as their primary compliance strategy. The foundations are there, but most teams don't take the next step of genuinely separating their payment data layer. The ones that do ship faster, iterate more freely, and scale without compliance crises.

Set your metrics before you talk to a single vendor

Before you open your first vendor deck, define what success looks like in numbers. Not vibes. Numbers. That means authorization rates, false decline rates, cost per successful transaction, and SLA expectations for adding a new payment method. Write them down, socialize them, and make them real.

Without this baseline, you won't notice a performance problem until it's become a revenue problem. By the time high-quality transactions are declining at unacceptable rates, you're deeply embedded with the provider causing the damage, and switching feels impossible.

With clear metrics in place, Spreedly's transaction reporting and analytics give you continuous visibility into how each gateway is performing. You can see where your authorization rates stand, compare across providers, and make routing decisions based on data. You know when a provider crosses your red line. You have the numbers to back up a renegotiation or a switch.

Call it your North Star, your KPIs, your mission parameters. Whatever you call them, set them before you start shopping.

Build for the market you're heading toward, not just the one you're in

The advice I see out there swings between "just ship something" and "build for global on day one." Both are wrong at the extremes.

A pre-revenue startup over-engineering for 40 markets is burning resources on ghost users. But a team that hard-codes assumptions about currencies, payment methods, and networks into their checkout is going to pay twice when they expand: once in engineering hours, once in time-to-market.

Build a payment stack that nails your initial market and makes the next two or three genuinely easy. Spreedly's platform supports gateways and payment methods across 100+ countries. The architecture doesn't need to be rebuilt when you go international. You're already on the infrastructure that scales there.

My gold standard is a checkout with no hard-coded assumptions about currency, network, or payment method. That level of flexibility is the difference between a payment stack that enables growth and one that quietly throttles it.

All of this comes back to the same thing: build strategically and embed flexibility early. An off-the-shelf gateway integration is fast to ship and slow to escape. The cost of getting it wrong isn't paid in the first quarter. It's paid in years of remediation, missed opportunities, and engineering capacity diverted away from the work that actually moves the business.

The guide that should have been in front of you on day one

I’m going to leave you with something that every payment leader will agree they needed at the start of their first build: The Complete Guide to Payments Orchestration. 

The guide explains the basics of orchestration, the finer points of its implementation, and the ways businesses like yours benefit across every aspect of generating revenue. It condenses years of operational experience into a digestible playbook that will save early-stage teams from complicated and expensive mistakes.