August 6, 2026
Choosing a Crypto Payment Processor: 10 Services Compared by Total Cost
Read article
Some of your cross-border charges never arrive. The issuer declines them, nobody explains why, and a couple of corridors your bank will not touch at all. That is usually how a finance lead ends up reading about crypto payment processing — or crypto acquiring, the same job under the name a lot of vendors use: accepting customer payments in cryptocurrency through a provider that watches the blockchain for you. The buyer sends coins from their wallet, the provider confirms the transfer landed and credits it to a balance you hold with them, normally converted on arrival into a stablecoin: a token pegged to the dollar.
It is called acquiring because it does the job card acquiring does. The machine underneath is a different machine, and so is the bill. And the bill is never one number: the rate on the landing page is one parameter out of ten, and on a modest average order the other nine decide what you actually pay. So this page hands you the grid rather than a price. What each parameter is, what it does to your total, and what to ask about it in whatever price list lands in your inbox — put your own conditions in and it works on any contract you are shown.
It is a regional term. You meet it mostly on the sites of processors in Eastern Europe and the CIS, where "acquiring" is the everyday word for card acceptance. English-language payments say it differently, and the mapping is one to one:
From here this page says gateway and processor — the wording in the contracts.
Card acquiring has four parties: you, your customer, the card network, and the acquiring bank that holds your merchant account. The bank sits in the middle and does four jobs at once. It moves the money. It fronts you funds before they clear. It carries the risk of a payment being pulled back weeks later. And it puts fiat in your bank account. Your rate pays for all four.
Crypto acceptance deletes the middle. Four parties become three: you, your customer, and a processor reading the blockchain. The processor keeps books and converts currency. It never owned that money and never advanced it to you.
Three consequences follow.
Your money sits with a service, not a bank. Between the moment a customer pays and the moment you take the balance out, you own a claim on a company. No deposit insurance stands behind it. That is why what to look at when comparing processors deserves a week of somebody's attention.
There is no reversal to make. No buyer, bank or processor can pull a confirmed transfer back — the mechanism is simply not part of the chain.
And no arbitrator to ask. When a card customer disputes a charge, an institution with a rulebook decides who was right. Here a dispute is two people and an email thread.
Four card words stop applying, so park them now: authorisation hold, capture, clearing, chargeback. One card word survives, in a single sense throughout this page: settlement means the moment money reaches your own bank account.
What you gain is simple: money that arrives is money you keep. No pull-back weeks later, no fee for losing an argument you never got to hear.
What you take on is that a refund is your own act. Nothing automatic gives a customer their money back — you send a transfer because you decided to. The processor's fee for it is the small part — a refund is a priced operation with its own line in the price list, so find that line before you sign. What sits around the fee is bigger. You already paid to accept the payment and do not get that back, the money leaves a stablecoin balance so the exchange rate in between is yours, and somebody does the transfer by hand with nobody to appeal to when the customer says it never came. That is what a high refund rate costs you here. The fee itself is the cheap part.
A rate is not a price. The number on the landing page is one line of ten, and the other nine are what you sign. Below is each of them: what it is, what it does to your total, and the question that gets a straight answer out of a sales conversation.
One bearing to hold while you read: published acceptance rates for crypto sit roughly between 0.5% and 2% per payment. Everything else on this list moves your real number away from whichever end you were quoted.
The acceptance rate. A percentage of every payment that goes through. Everyone has one, everyone advertises it, and it is the only line most people compare. Ask whether it is charged on the invoice amount or on what actually arrives on your balance. The processing service CryptumPay charges 1% of each successful payment, from 0.5% at high volume, and the fee can be passed to the customer.
A fixed part per payment. Some price lists add a flat sum to every transaction; plenty do not. Never assume either way, because this one moves in inverse proportion to your basket. Say the fixed part is €0.25: on a €20 order that is another 1.25% on top of the rate, on a €500 order it is 0.05%. Same tariff, two completely different prices. If you sell small tickets, read this line before you read the percentage.
Volume tiers. Rates that step down as monthly turnover rises. Some providers publish the thresholds; with plenty of others you will not see them at all — so never plan on a step you have not been shown in writing. Ask where the steps sit, over what period volume is counted, and what happens in a month you fall short.
Conversion. Incoming coins have to become something stable, and eventually perhaps fiat. This is the parameter people miss, because it lives in one of two places: inside the acceptance rate, or on its own line. A 1% rate plus a 1% conversion is 2% — double the figure from the landing page, and nothing dishonest happened. Ask the one question that settles it: is conversion included in the rate, and which exchange rate is applied. At CryptumPay incoming funds convert to USDT on arrival.
The withdrawal, by channel. Taking your balance out is priced per route, and each route carries its own price: to your own crypto wallet, to a bank inside your own payment zone, or by international transfer. Which of the three is cheap and which is dear is whatever the price list in front of you says — so read it rather than assume it. Ask for all three, not only the one you plan to use in month one.
And inside that same line, the minimum fee. It turns the arithmetic upside down while hiding behind a small percentage. Say the price is half a percent with a minimum of €50. On a €1,000 payout, half a percent would be €5 — but the minimum applies, so you pay €50, which is 5% of the money. It stops biting at €10,000, where half a percent finally equals €50. Below that you are not paying a percentage at all; you are paying a flat fee dressed as one. Which makes your withdrawal schedule a pricing decision: batch, and this line shrinks toward nothing; take small amounts out weekly, and it eats the model.
All of that assumes the money is going to one place: you. Pay a few hundred partners instead and batching is off the table — every recipient is a separate transfer that meets the fee on its own, and the line you just shrank to nothing becomes the largest one on the bill. Cards, wallets and chains priced side by side on exactly that run are in what two hundred small payouts really cost.
The minimum withdrawal amount. Until the balance clears it, the money stays with the service. Harmless at scale, irritating while you are testing the channel on a handful of orders. Ask what it is on each route. CryptumPay withdrawals go to your own wallet at any time with no minimum amount, manual or automatic.
Settlement cadence. How often money actually moves, not how fast it could. It costs nothing on the fee schedule and a great deal in working capital, which is why it gets a section of its own further down.
The network fee. The cost of getting a transaction into a block. Your customer pays it, so it never reaches your invoice — but on an expensive network a small order can carry a fee the buyer refuses, and an abandoned checkout costs you the whole order rather than a percentage of it. Treat it as a revenue parameter and ask which networks are supported.
The price of a refund. Sending money back is its own priced operation, separate from acceptance. Ask what it costs, and confirm what you already suspect: the fee you paid to accept the payment does not come back with it.
Entry costs — the ones that are usually missing. A card merchant account tends to arrive with things you pay before selling anything: a security deposit, a monthly minimum, a turnover you commit to. Crypto acceptance generally has none of them, which is exactly why they are worth asking about explicitly — any monthly fee, any committed volume, anything payable if you sign and never switch on.
Take your real average order and the route the money genuinely has to travel, then write down only the lines that apply to you: acceptance, the fixed part if there is one, conversion if it is charged separately, the withdrawal channel you will actually use, and the minimum fee where it bites. Add them, divide by the order value, and you have one honest percentage.
That number — not the one from the landing page — is what goes into the comparison below.
Your card rate is whatever you negotiated, and negotiated rates are not published, so there is no honest average to compare against. You do not need one — your number is on your own statement.
Add up the card side properly first. Three things go into that sum and only three: the rate, the fixed fee per transaction, and any monthly minimum you pay whether you reach it or not, spread across the orders it covers. That total, on your own average order, is your all-in card number. Read it against the percentage you just built out of the grid.
Leave the chargeback fee out of it. That one lands per disputed transaction, so it follows your dispute rate — add it in that proportion or leave it out.
And the rolling reserve is not a fee. A percentage of each day's takings is held back and released on a schedule at the end of the reserve period, minus whatever disputes and refunds actually consumed. That is your money, late. Counting it as a cost inflates your card side by more than the three real fees put together, and every comparison below then tilts toward crypto on bad arithmetic.
It is a cash-flow problem, and often a painful one: on a reserve you are financing your processor with working capital frozen for months. There is no rolling reserve on the crypto side — no percentage of each day's takings withheld as a matter of contract — and that difference belongs in the decision as cash flow, measured in months of frozen capital.
Three questions then decide which side wins, and the headline rate is none of them.
Run the grid honestly and it rarely produces a saving worth rebuilding a payment stack for. Price is not the reason to do this.
The reason is the other column. A percentage only describes a payment that went through, and your problem is the ones that did not: the charge declined by an issuer three time zones away, the country your bank will not settle into, the buyer whose card will not work on your checkout. A crypto payment either lands on-chain or it does not, visibly, and nobody can take it back afterwards. That is what you are buying, and the withdrawal leg is the price.
By default it lands as a stablecoin balance held by your processor. Two routes out of there:
One parameter almost nobody weighs decides your working capital: settlement cadence runs from daily to weekly depending on the provider. Weekly settlement in a business with weekly supplier payments is a different business from daily settlement. Cut-off times and banking-day counts are rarely published anywhere, so get the day of the week and the hour in writing.
The same questions get sharper the day you decide to leave a provider. Money already taken but not yet settled has to finish moving while you migrate, and a cadence you never pinned down becomes the length of the wait. That end of it is worked through separately, in Coinbase Commerce alternatives and what happens to the money you left behind.
Commercially it is lighter than a card merchant account: sign up, pass business verification, agree the rate. No terminal to buy, no deposit to post, no turnover you promise to hit.
The technical side is a few lines of code, by one of four routes — a hosted payment page, an embedded widget, a plugin for your e-commerce platform, or a direct API integration. The full walkthrough of those four routes is a page of its own.
The real work lands in week two: accounting has to book a stablecoin balance, support needs an answer for "I sent it and the order still says unpaid", and the refund policy needs rewriting because the mechanism changed. What actually changes inside a working store covers that ground properly.
Incoming funds also get screened. Providers run AML checks on the wallets paying you, and a flagged payment can be held — which keeps your balance clean, but makes "money arrived" and "money is spendable" two different events. How AML screening works on incoming payments is worth reading before your first held transaction.
In both jurisdictions that matter here, the question lands on your provider's status.
European Union. MiCA, the Markets in Crypto-Assets Regulation, has been fully applicable since December 2024, and the transitional window for providers already operating under national rules closed on 1 July 2026. A provider serving EU clients now has to be an authorised crypto-asset service provider. Checking that authorisation before you sign is the whole of your homework; the register sits on ESMA's MiCA pages.
United States. The GENIUS Act, the federal framework for payment stablecoins, was signed on 18 July 2025 and takes effect on the earlier of 18 January 2027 or 120 days after regulators issue final rules. The date is not fixed, so a US provider's obligations are still being written — the record is on the GENIUS Act page at congress.gov.
That describes the EU and US frameworks as of August 2026 and is not legal advice; what you owe depends on where you are incorporated and where your customers are.
Most companies never choose between cards and crypto. They add crypto for the corridors where cards keep failing, keep cards for everything else, and judge the addition on recovered orders. That makes the decision much smaller than it looks.
It suits you if your problem is corridors, large B2B invoices with technical buyers, or digital goods with few disputes. The bigger your average order, the more the fixed costs shrink into noise.
It does not suit you if:
No. There is no reversal mechanism in this chain and no bank to run one. The complaint still comes to you, with no arbitrator to rule on it, and a legitimate one you settle by sending money back yourself, at your own cost. The mechanism is missing; the obligation is not.
Two clocks. The on-chain part takes minutes. The bank part is your provider's settlement cadence, daily to weekly, and the cut-off times behind it are rarely published — ask for the day and the hour before you sign.
Four parameters decide it, and the advertised rate is only one. Where the money has to end up — crypto, a bank in your own payment zone, or an international transfer — because each step adds a layer. Whether conversion sits inside the rate or on its own line. Your average order, which decides whether fixed parts and minimum fees are noise or the whole bill. And your all-in card number from your own statement: rate plus fixed fee plus any monthly minimum, with the rolling reserve left out, because that is delayed cash and not a fee. Large tickets and batched withdrawals make the crypto side work. Small, frequent ones do not.
The grid is a template; the values come from whoever you sign with. CryptumPay's, for the lines above: 1% of each successful payment, from 0.5% at high volume, and the fee can be passed to the customer. Incoming payments convert to USDT on arrival. Withdrawals go to your own wallet at any time, manually or automatically, with no minimum amount. Before the first payment you need a merchant account, a Project ID and your domain added to the project — the widget will not run on a domain that is not in it.
Create an account and connect the checkout yourself, or talk to sales and we will plan the integration with you.
