If you run a software platform, you almost certainly built your own payment links. You are a tech company with engineering resource, the payment companies hand you hosted elements that do the heavy lifting, and stitching them into a links layer is a few days of work. Payments did not feel hard, so you built the minimum, shipped it, and moved on to the product that actually differentiates you.
That is a completely reasonable instinct, and for a real subset of platforms it remains the right one. But the minimum has a ceiling most teams never price in. Hosted elements solve the one thing that is genuinely easy, capturing a card on the happy path. They do not solve the parts that are actually hard.
This guide is the build-vs-buy decision for platforms that already have a basic links layer. It is written for product leaders, founders, and engineering managers who think of payments as a solved feature, and want to sanity-check whether the minimum they built is quietly capping the platform. If you have not built anything yet, the same framework tells you where the line is.
Why Building the Minimum Feels Right
It is worth stating plainly why the minimum is the default, because the decision later only makes sense if you respect the logic that got you here.
You have the tech resource. Building is what your team does well, so building feels cheaper and safer than buying.
Hosted elements make payments look solved. The PSPs give you drop-in components that handle the card capture, so the visible problem is small. You aggregate a couple of payment APIs, put a links layer on top, and it works.
The happy path is genuinely easy. A single processor, one currency, a hosted page. That part really is a few days.
Payments is not your product. A "good enough" payment experience is a rational trade when your roadmap is full of things that actually differentiate you.
None of that is a mistake. The gap is not in the decision to build the minimum. It is in assuming the minimum is the whole problem.
What the Hosted-Element Happy Path Hides
Hosted elements solve capturing a card. Everything below is what they do not solve, and what the minimum links layer leaves on the table. None of this shows up on day one, which is exactly why it is easy to miss.
One PSP, until you need more. The moment a customer has their own acquirer, a negotiated rate, or a region your processor does not serve, you need a second integration, then a third. Hosted elements do not give you multi-PSP routing. Each one is a fresh build.
No per-customer routing. Each of your customers may want their own processor and their own merchant account. A hardcoded PSP behind a hosted element cannot route per tenant.
Multi-currency and cross-border. The minimum works in one currency and one country. Expansion turns into payments engineering instead of go-to-market.
Compliance you did not plan for. Even with hosted elements, the way most teams build means card data or its handling drifts into your logs, support tooling, or other channels, which pulls your platform toward the expensive end of PCI DSS scope. See the cost of PCI compliance for platforms.
Channels the link cannot reach. Customers increasingly want to pay over the phone, inside an AI voice or chat agent, or through agentic checkout. A link-only layer has no path there.
A payment experience you deprioritised. The minimum ships a mediocre flow. You are fine with that today, but it is a real conversion and trust gap that compounds as you scale.
The point is not that you are in pain. Most platforms at this stage feel fine, because the costs above are invisible or deferred. The point is that the minimum is a local maximum: it solved the easy 20% and stopped, and the other 80% is where both the risk and the upside live.
The Minimum Is Cheap to Build and Expensive to Do Well
Build-vs-buy goes wrong when teams compare the cost of buying against the cost of the minimum they already built, rather than the cost of doing payments properly.
The minimum is cheap precisely because hosted elements did the hard capture work for you. But production-grade payments across processors, currencies, channels, and compliance is real engineering: multi-PSP routing, tokenisation, retries, refunds, reconciliation, per-tenant configuration, and a permanent compliance burden. That work never ends, because processors change APIs and compliance requirements shift.
So the honest choice is not "build a links layer for a few days" versus "buy." It is: either keep pointing your engineering resource at payments depth that is not your differentiator, or stop at the minimum and live with its ceiling. An embedded layer removes that dichotomy. See build vs buy payment infrastructure for the fuller cost model.
Build vs Buy: A Decision Framework
As a tech company your default is to build, and for your core product that default is correct. Payments is the specific exception, because the depth is large and it is not what differentiates you. Use these questions to decide where the line sits for you.
Keep building makes sense when:
You serve one market, one currency, and one processor, and expect that to hold.
You have no near-term need for multi-PSP routing, per-customer routing, or new channels.
You genuinely want to own payments as a product and will staff it as one.
Buy an embedded layer when:
You need more than one PSP, or expect to, including letting customers bring their own gateway.
Your customers each need their own processor and merchant account.
You operate or plan to operate across currencies or regions.
You want card data kept away from your systems so your PCI scope is limited.
You need to take payments across channels: links, phone, AI voice and chat agents, agentic checkout.
You would rather your engineers ship your product than maintain payment depth.
DIY Payment Links vs an Embedded Payment Layer
Dimension | DIY links layer (hosted elements) | Embedded payment layer |
|---|---|---|
Card capture | Solved by hosted elements | Solved, plus everything below |
Processors | One per integration you build | 40+ via one integration, bring your own gateway |
Per-customer routing | Hardcoded, hard to vary | Route each tenant to their own processor |
Multi-currency / region | Build per market | Gateway per customer and payment method |
PCI scope | Drifts into yours | Limited, with card data handled by a PCI Level 1 provider |
Channels | Hosted link only | Links, phone/DTMF, AI voice and chat agents, agentic checkout |
Engineering focus | Your team maintains payments | Your team ships your product |
What an Embedded Payment Layer Gives You
An embedded payment layer sits underneath your platform and owns the depth, so your team keeps building your product. Shuttle is one such payment layer: you keep the customer relationship and the experience, and the layer handles the gateway connections, per-tenant configuration and PCI DSS Level 1 security for the card data it touches.
Your engineers back on your product. The depth that is not your differentiator becomes the layer's job. See get payments off your roadmap.
Multi-PSP from one integration. Connect to 40+ gateways once, add or switch processors without re-integrating (saved cards stay with the gateway that stored them), and let each customer bring their own gateway.
Per-tenant routing. Route each customer's transactions to their own processor and merchant account.
PCI scope limited. Card data flows through the layer's PCI DSS Level 1 environment, not your servers, logs, or support screens, which limits your platform's PCI scope.
One layer across channels. The same integration covers links, phone payments, AI voice and chat agents, and agentic checkout, so new channels are configuration, not a new build.
Buying is not conceding that payments is too hard for your team. It is the opposite: it frees the team that could build it to build your actual product.
Frequently Asked Questions
We are a tech company with engineering resource. Why would we buy instead of build? Because the part you can build cheaply (card capture via hosted elements) is not where the value or the difficulty is. The value is in multi-PSP support, per-customer configuration, compliance, and new channels, all of which are real ongoing engineering that is not your differentiator. Buying redirects your resource to your product.
Should my platform build or buy payment links? Build when you serve one market, one currency, and one processor, and you do not need per-customer routing or new channels. Buy an embedded layer when you want multiple PSPs, per-tenant routing, multi-currency, additional channels, or a limited PCI scope.
Isn't a basic links layer with hosted elements good enough? For a narrow, stable scope, yes. The risk is that "good enough" is a ceiling: it ships a mediocre experience and stops short of multi-PSP, per-tenant routing, compliance at scale, and new channels. Those costs are deferred, not absent.
Can we keep our existing PSP if we adopt an embedded layer? Yes. A gateway-neutral layer lets you keep your current acquirer and pricing, and lets each customer bring their own. You are not forced onto a single provider. See single-PSP risk.
Related Reading
What is embedded payments: the category this decision sits inside.
Build vs buy payment infrastructure: the fuller cost model behind the decision.
When SaaS outgrows Stripe Connect: the same ceiling, told through one common starting point.
The payment layer explained: what an embedded layer is and how it differs from a gateway or PayFac.
Decide With the Full Picture, Not Just the Happy Path
If your links layer stops at the happy path, it is worth pressure-testing build-vs-buy properly before the next processor, currency, or compliance request lands.
Talk to our team about embedded payments