An exchange or a P2P platform has a peculiar problem. The crypto side works fine. The fiat side is where everything stops. Card acceptance gets declined. The bank account gets closed. The reason given is a category name, not anything you did.
This is a solvable problem, but not by finding a provider who asks fewer questions. A merchant account for a crypto exchange goes to the operator whose questions have answers. That starts with understanding why the category is treated the way it is.
Contents
- What the words mean here
- Why the category is priced the way it is
- What an application needs
- What it costs
- Reducing the disputes that come with the model
- Where the fiat lands
- What to prepare before the first conversation
- In short
What the words mean here
On-ramp is the moment a customer turns money into crypto — a card payment or a transfer arriving at your platform. Off-ramp is the reverse: crypto turning back into money that leaves to a bank account. Card acceptance sits almost entirely on the on-ramp side.
P2P means the platform does not sell the asset itself. Two users trade with each other, and the platform holds, escrows or matches. That distinction changes everything in the application. It changes who the merchant of record is, and who answers when a trade goes wrong.
Travel rule is an obligation to pass identifying information with transfers above a threshold. It covers both the sender and the recipient. It is why «we do not collect that data» is not an available answer.
Why the category is priced the way it is
- The purchase is irreversible, the payment is not. Crypto delivered cannot be recalled; a card payment can be disputed for months. That asymmetry is the single biggest reason for the rate and the reserve.
- Card testing looks like your normal traffic. Small, fast, repeated on-ramp payments look exactly like a fraudster’s test pattern. So the filters bite harder here than elsewhere.
- P2P adds a second unknown party. The counterparty in the trade is a customer, not a vetted merchant, and the platform is answerable for both sides.
- The rules keep moving. Licensing and reporting duties for this activity are revised more often than in most verticals, and providers price for that.
Which band a business lands in, and why, is set out in our piece on what high-risk, middle-risk and low-risk payments are.
What an application needs
The company set is standard — registration, articles, beneficiaries — and then the part specific to this activity carries the weight.
- Licences and registrations for the activity, wherever they are required. We work with licensed operators, and the licence is the first thing looked at rather than the last.
- A written AML policy and the person responsible for it. Not a downloaded template: procedures that match what your platform actually does.
- Your verification flow, described end to end. At what point a user is identified, what is collected, what is checked, what blocks a trade. Verification is mandatory — a platform without it is not an application anyone can process.
- Transaction monitoring and limits. Per user, per day, per new account. Show the thresholds you already enforce.
- The dispute path. Who decides a contested P2P trade, on what evidence, in what time.
The rest of the company file is the same as anywhere; the full list is in our merchant approval checklist.
What it costs
MDR runs 3%–5% depending on the type of business, plus 0,50 EUR per transaction; settlement in EUR over SEPA is 0,20%, the settlement term is T+7, and the rolling reserve is 10% for 180 days. A refund costs 50,00 EUR and a chargeback 100,00 EUR. The exact figure is set per merchant and we consider individual solutions for your business.
The reserve deserves attention in this vertical specifically: it is held out of settlement, so on a fast-turning book it is the line that shapes working capital more than the rate does. All published lines sit on the pricing page.
Reducing the disputes that come with the model
Because the asset cannot be recalled, evidence has to be built at the moment of the trade rather than afterwards: identity verified, the exact rate and amount shown and accepted, a timestamped confirmation of delivery to the address, and a statement descriptor the customer recognises. That last one sounds minor and is the most common cause of an otherwise clean dispute.
How the acceptance side is routed and retried is described under payment processing.
The crypto settlement side has its own write-up in our piece on crypto payments for high-risk businesses.
Where the fiat lands
Card acceptance and the account the money settles into are two separate products, reviewed alongside each other rather than one instead of the other. The account side is described under business IBAN — and for this vertical it is worth arranging both before launch, not after the first volume arrives.
What to prepare before the first conversation
Five documents shorten the review more than any wording in the application does, and all five exist before you apply.
- The licence or registration, with its scope. Not just the certificate — what exactly it permits.
- The AML policy and the named officer. Dated, signed, and matching your actual flow.
- A screenshot walk-through of verification. What a real user sees, step by step, from sign-up to first trade.
- Your limit table. Per user, per day, per new account, and what raises them.
- A worked example of a disputed trade. One real case, start to resolution, with the evidence you used.
In short
An exchange or P2P platform is not refused for being crypto. It is refused for an application that cannot show licensing, verification, monitoring and a dispute path. Bring those four, describe the model precisely — who sells, who is counterparty, who answers — and price in a reserve that reflects an irreversible product. Then the account is an ordinary conversation about terms.