Looking for a crypto payment processor alternative
Almost every merchant evaluating crypto acceptance wants the payment and not the asset. The processors differ enormously on that one point — where conversion happens, whether you hold a balance, and whether the result reconciles alongside your card takings or in a separate system with its own dashboard.
Six questions that decide what you're signing up for.
Do you end up holding tokens?
The decisive question. If conversion happens after settlement rather than before it, you have a balance, a treasury policy, and an asset on your books — whether or not you wanted one.
When is the rate fixed?
It should be set and shown before the customer confirms, and printed on the receipt. A rate applied afterwards means the euro figure you receive isn't the one anybody agreed to.
Does it reconcile with your card payments?
A crypto order should sit in the same list, carry the same kind of reference, and land in the same payout. A separate dashboard is a second reconciliation model you'll maintain forever.
Is it on your checkout or a redirect?
A method that redirects to a crypto-branded page converts worse and looks like a different company took the payment. On-page beside cards is a materially different experience.
What does a refund look like?
Ask whether a refund goes back as tokens or as the fiat settlement, and against what reference. This is where separate crypto systems get awkward for finance.
Who is in the flow of funds?
Understand which entity holds value at each step, under what permissions, and what reaches your account. It's the first thing your finance and compliance people will ask.
Two different products sold under one name
One kind of crypto processor is built for businesses that want to hold digital assets: you receive tokens, you manage a balance, you convert when you choose. The other is built for businesses that want the payment and nothing else: conversion happens before settlement and euros reach your account. Both are legitimate; they suit opposite intentions, and the marketing language is nearly identical. Working out which one you're being shown is most of the evaluation.
- [ 01 ]Hold-the-asset: a balance, a treasury policy, a conversion decision
- [ 02 ]Take-the-payment: conversion before settlement, fiat in your account
- [ 03 ]The words on the website often don't distinguish them
The operational cost nobody quotes
The fee is rarely what makes crypto acceptance expensive. The cost is the second system: a separate dashboard, a separate reconciliation, a second currency in the ledger, a wallet or custody arrangement to secure, and a compliance conversation about all of it. A method that lives on your existing checkout, produces an ordinary order, and settles into your ordinary payout avoids nearly all of that — which is why the integration model matters more than the rate.
- [ 01 ]A second dashboard and a second reconciliation model
- [ 02 ]A second currency in the books and the exposure that follows
- [ 03 ]Custody, keys, and the policy that governs them
- [ 04 ]The compliance conversation each of those triggers
Where Protocore Gateway fits
We're firmly the second kind. USDC sits on the same checkout as cards and wallets, priced at a rate shown before the customer confirms, converted as part of settlement, and paid out in euros alongside your card takings against the same order reference. You never hold a token, never run a wallet, and never open a treasury function. Refunds unwind as the euro settlement rather than as a token transfer, so both legs of the accounting stay in one currency. If what you actually want is to hold digital assets, we're the wrong choice and will say so.
- [ 01 ]On the same page and the same order as cards
- [ 02 ]Rate fixed before confirm, printed on the receipt
- [ 03 ]Converted before settlement — you never hold a position
- [ 04 ]One payout, one reference, one currency in the books
Questions worth asking anyone.
Yes — that's the difference between conversion before settlement and after it. When the conversion is part of settlement, what reaches your account is fiat and there is no balance, no wallet, and nothing to sell at month end.
Ask when the rate is fixed. If it's set and shown before the customer confirms and recorded on the receipt, the euro total on the order is the figure you receive, and the volatility question doesn't reach you.
They shouldn't. A customer paying from their own wallet to a payment address generated for that order has nothing to sign up for — and a signup step is where most crypto checkouts lose the payment.
It should look like any other payment: one order, one euro figure, one payout line, with the method and the rate applied recorded on the receipt. If your accountant needs a second process for crypto orders, the integration model is wrong.
Take a stablecoin payment right now.
Run the demo checkout in USDC across three networks and see the euro settlement it produces — then decide whether the rest of your evaluation is worth doing.
Try the checkout