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.
Seven questions that decide it
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
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
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