/// Compare / Checkout

Hosted checkout vs building your own

Every merchant taking money online answers this once: does the page that collects card details belong to you, or to your provider? The answer decides your PCI scope, how fast you can add a payment method, and who gets paged when a scheme mandate lands. It is less a technology choice than a decision about what your team should be spending its year on.

/// Option vs option

Seven questions that decide it

Dimension
Hosted checkout
Your own checkout
PCI scope
Minimal. The page collecting card data belongs to the provider, so your servers see a token and never a card number — usually the lightest self-assessment available.
Yours. Handling card data directly puts your systems in scope, with the design, assessment, and annual re-certification that follows.
Time to first payment
Days. Create an order, redirect, handle one webhook — most of the work is deciding what happens after the payment succeeds.
Months, and the long tail is the hard part: 3-D Secure, wallet sheets, error states, retries, and every method's edge cases.
Adding a payment method
Configuration. New methods arrive with the platform and are switched on; the page adapts without a release on your side.
A project each time — integration, certification, UI work, and a permanent maintenance commitment per method.
Control over the experience
High but bounded: branding, layout options, your own domain, and embedded fields when you need the payment inside your page — within what the provider exposes.
Total. If your checkout needs to do something genuinely unusual, nobody else's constraints apply.
Conversion work
Inherited. Method ordering, localization, wallet support, and retry behaviour improve as the platform improves, without you running the experiments.
Yours to earn. You can out-optimise a generic page for your specific funnel — if you have the traffic and the people to run it properly.
Keeping current
The provider's problem. Scheme mandates, SCA changes, browser and wallet updates land as platform updates.
A standing line on your roadmap, indefinitely — the work never finishes and rarely gets prioritised until something breaks.
Real cost
Per-transaction economics, visible and proportional to volume.
Engineering salaries plus certification, spent before the first payment and every year after — usually underestimated by an order of magnitude.
/// 01

When a hosted checkout wins

For most businesses, most of the time. If payments are how you get paid rather than what you sell, the checkout page is not where your advantage lives — and the cost of owning it is paid in the least visible way possible: a permanent share of your engineering capacity going to scheme mandates and method integrations instead of your product. A hosted page also collapses the PCI question, which is the single largest hidden cost of doing it yourself.

  • [ 01 ]Payments are a means to revenue, not the product itself
  • [ 02 ]You want card data out of scope rather than carefully handled
  • [ 03 ]New methods should arrive without a release on your side
  • [ 04 ]Your engineers are worth more on the thing customers buy
/// 02

When building your own wins

When the checkout genuinely is the product. Platforms that process for other people, businesses with a flow no hosted page can express, and teams at a volume where a fraction of a percent of conversion outweighs a payments team's salary — those cases are real, and they justify the build. So does a regulatory position that requires the card-handling surface inside your own perimeter. Below that scale, building usually means rediscovering, expensively, why hosted checkouts exist.

  • [ 01 ]Payments are the product — you process on behalf of others
  • [ 02 ]Volume is high enough that marginal conversion beats a team's cost
  • [ 03 ]A regulator or risk committee requires the surface in your perimeter
  • [ 04 ]Your flow is genuinely unusual and no hosted page can express it
/// 03

Where Protocore fits

Protocore Gateway is the hosted answer, with the usual escape hatches built in rather than sold separately: run the page on our domain or yours, embed the payment fields inside your own layout when the flow demands it, or present the same checkout natively in your app. Cards, wallets, bank transfer, and USDC sit on one page and settle to one euro figure against one order reference. And if the honest answer for you is the third option — you want to be the provider rather than the merchant — the same platform is available whitelabel, which is usually a better deal than building a gateway from scratch.

  • [ 01 ]Hosted page, your own domain, embedded fields, or in-app — same integration
  • [ 02 ]Cards, wallets, transfer, and USDC on one page, settled in EUR
  • [ 03 ]One order reference from checkout to receipt to bank line
  • [ 04 ]Available whitelabel when you want to be the provider, not the merchant

Not sure which side you're on?

Tell us your volume, your methods, and what your engineers are working on. We'll say plainly which one your situation calls for — including when that's building it yourself.

Talk to us