Looking for a hosted checkout alternative
Most people shopping for a new checkout provider are not shopping on features — they're leaving because a method they need isn't there, because reconciliation is painful, or because nobody answers when a settlement looks wrong. This page is the checklist worth applying to whatever you look at next, including us.
Six questions that separate one from another.
Which methods, on one page?
Not the count in the brochure — the ones your customers actually reach for, presented on the same page. A method behind a redirect or a second integration is a method you'll under-use.
What currency do you end up with?
If the answer varies by method, you've bought a reconciliation problem. Ask specifically what a crypto or cross-border payment produces in your account, and in what currency.
How much PCI scope lands on you?
A genuinely hosted page keeps card data off your servers even when it's embedded in your own layout. Ask what your systems store, and what your assessment looks like as a result.
Is there one reference end to end?
Checkout, receipt, webhook, payout, and refund should all carry the reference you supplied. Two identifiers to map between systems is where month-end goes wrong.
What does migration actually involve?
Stored cards should move as tokens so your subscribers never re-enter details, and both providers should be able to run in parallel while the old one finishes settling.
Who answers when it breaks?
A support queue and the team that wrote the settlement code are different products. At the point where a payout looks wrong, the difference is the only thing that matters.
Why people leave a checkout provider
Rarely for a cheaper rate. In practice it's one of four things: a method your customers ask for that the provider won't add, a reconciliation model that makes finance dread month-end, a support relationship that fails at exactly the wrong moment, or a roadmap that stopped moving while the payments world didn't. Working out which of those is your reason is the whole evaluation — a provider that is excellent at the other three is still the wrong switch.
- [ 01 ]A method your customers want that isn't coming
- [ 02 ]Reconciliation that costs someone several days a month
- [ 03 ]Nobody accountable when a settlement looks wrong
- [ 04 ]A product that stopped keeping up with the methods
What a switch actually costs
Less than teams expect on the integration and more than they expect on the edges. The order call and the webhook handler are usually a week; what takes planning is the tail — stored cards and subscriptions that must not break, refunds that still need to travel back over the old provider's rails, and a period where both systems are live. Any provider worth switching to should be able to describe that tail before you sign, not after.
- [ 01 ]Integration: an order endpoint, a redirect, one signed webhook
- [ 02 ]The tail: stored cards, subscriptions, in-flight refunds, parallel running
- [ 03 ]Refunds always unwind over the rail that took the payment
Where Protocore Gateway fits
We answer the six questions above like this: cards, wallets, bank transfer, local methods, BNPL, and USDC on one page; everything settles to euros; the card-handling surface stays ours even when the fields are embedded in your layout; one reference runs from checkout to bank line; stored cards migrate as tokens with both providers running in parallel; and the people who answer are the ones who wrote it. Whether that's worth a switch depends on which of the four reasons above is yours — if it's a cheaper rate, we're probably not it.
- [ 01 ]Every method on one page, settled to one euro figure
- [ 02 ]One order reference from checkout to payout to refund
- [ 03 ]Migration planned with parallel running, tokens included
- [ 04 ]A product studio behind it, not a support tier
Questions worth asking anyone.
Yes, and during a migration you should. New orders point at the new provider while the old one finishes settling and refunding its own payments — refunds always travel back over the rail that took the payment, so the old integration stays live until its last refund window closes.
They shouldn't. Stored cards move between providers as tokens, which is the single most important question to ask if you run subscriptions — a migration that resets every stored card is a churn event, not a migration.
The integration is usually a week. The plan around it — parallel running, token migration, the last refund window on the old provider — is what sets the calendar, and it's normally measured in weeks rather than months.
Then ask your current provider for a date before you evaluate anything. Switching provider to gain one method is a lot of work for a narrow gain, unless the same conversation reveals the other three problems above.
Run the checklist against us.
Take a real payment on our demo checkout, then tell us which of the six questions your current provider fails. We'll tell you honestly whether switching is worth your quarter.
Try the checkout