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, and they leave the most valuable part of payments, the economics, entirely on the table.
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.
Payment revenue you are not capturing. Your links move money for your customers and you earn nothing on it. Payments can be a margin line, not just a feature, and the platforms treating it that way are pulling ahead. This is usually the single biggest thing the minimum costs you. See how platforms monetise payments.
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 do not intend to treat payments as a revenue line.
You genuinely want to own payments as a product and will staff it as one.
Buy an embedded layer when:
You want payments to be a margin line, not money you move for free.
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 out of your scope so PCI stops being your concern.
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
Payment revenue | None, you move money for free | Revenue share built in
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 | Routed by currency, region, or customer
PCI scope | Drifts into yours | Held by a PCI Level 1 provider, kept out of yours
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, the layer handles processing, routing, compliance, and the economics.
Payments as revenue, not a free feature. Capture economics on the payments your platform already enables. For most platforms this is the line that changes the build-vs-buy maths on its own.
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, 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 lifted off you. Card data flows through the layer's PCI DSS Level 1 environment, not your servers, logs, or support screens, keeping your platform out of 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, while you finally capture the part of payments that pays.
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 payment revenue, multi-PSP routing, 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 and captures payment economics you currently give away.
Should my platform build or buy payment links? Build when you serve one market, one currency, and one processor, you do not need per-customer routing or new channels, and you do not intend to monetise payments. Buy an embedded layer when you want payment revenue, multiple PSPs, per-tenant routing, multi-currency, additional channels, or card data out of your 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 captures no payment revenue, 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.
How does buying help us monetise payments? A DIY links layer moves money for your customers and earns nothing on it. An embedded layer is built to share payment revenue with the platform, turning payments from a free feature into a margin line.
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.
How platforms monetise payments: turning payments from a feature into a revenue line.
Decide With the Full Picture, Not Just the Happy Path
If your links layer captures no payment revenue and 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