The Crypto On-Ramp Integration Checklist for Product Teams

The documentation stops at features. It can't tell you which consequences each feature drags in, or who absorbs them. Each capability arrives with a decision attached, and that decision usually belongs to someone other than the engineer reading the docs.

• The rate endpoint is a feature; who keeps the rate you show in sync with the live one is a decision.

• Business verification is a feature; who starts gathering documents, and when, is a decision.

The docs are enough to build the on-ramp. Shipping it on time takes the decisions the docs leave out.

So this is not a tour of what a vendor can do. It is a list of the choices a build ticket leaves out, in the order they come due, using one provider, Mercuryo, as the concrete case. Each number below is there for one reason: it shows you where a feature hands you a decision without saying so.

Written as "integrate on-ramp," it reads as one engineering task. It is four tasks, and each runs on its own timeline.

• Engineering builds the connection.
• Compliance decides how users get verified and completes your business verification. It depends on other people and on paperwork, so it rarely moves on your schedule
• Support decides how a stuck user gets unstuck.
• Finance owns reporting and reconciliation once money moves.

The provider acts as merchant of record, taking on the chargebacks, fraud, and disputes that come with the transaction. That's why an integration is a build project rather than the far longer road to running the rails yourself.

Building those rails yourself means securing the licenses your own operations require across the jurisdictions where you serve users, a process that runs on regulators' timelines, not yours, before your first transaction clears.

Taking that regulatory weight off your critical path is exactly what makes the rest look small. The visible work is gone, and the remaining coordination gets underestimated. The work moved to other desks; the total amount stayed the same, and coordination has no defined point where it is finished.

The rest of this checklist is coordination, in three passes: the decisions that change what engineering writes, the compliance that has to start before the build, and the ownership that has to exist before the first live transaction.

These come first because each one rewrites the ticket. Settle them after the build starts and you are reworking, not building. Pick your integration route before the build starts, because it sets how much you write.

A provider gives you more than one way in, and the choice sets how much of your product the user stays inside and how much engineering you sign up for.

The trade-off is the same no matter which provider you pick. The more of the screen you control, the more engineering you take on.

A hosted route is the least code, with branding limited to theme and URL parameters. The more of the flow you rebuild in your own interface, the more engineering you take on and the more of the payment and compliance surface you pull toward your own product.

Begin with the hosted route for the lowest implementation effort. Move inward later, once live usage shows which part of the experience drives conversion or retention.

The real question is how much of the experience you want to own forever. That's a product call, and it lands on product before it lands on engineering.

Reach numbers are accurate but tell you nothing on their own about whether your users can pay. Mercuryo covers 135+ countries through 10+ payment methods, and behind a headline like that sits the one question that decides conversion.

That question is simple: are the specific methods your audience uses available in your markets? Confirm it early, and the reach in the headline turns into reach you can count on.

Coverage falls into three families, each solving a different reach problem:

The examples above are a sample. Availability varies by market and method, so confirm the current coverage in the payment-method documentation before launch and you build on solid ground.

One detail is worth knowing early because it sits in the mobile-pay fine print. Apple Pay and Google Pay run on a closed list of 23 fiat currencies.

So confirm your market's currency is on that list, since availability can still depend on the user's device, OS version, and card issuer.

You choose how much pricing and choice lives in your own app before the user reaches the widget.

Mercuryo exposes the data you need to build it: the currency list, live buy and sell rates, available payment methods, and the minimum and maximum transaction limits, so the number you show matches what the user can transact.

Render that yourself to keep the user inside your interface. Because those rates are live, a number shown in your own screens can drift from the current one, so decide how you keep the two aligned.

Let the hosted flow present rates, limits, and currencies, and you build very little of it yourself.

Neither choice is wrong, but it is a choice, and it changes the ticket from "load a widget" to "load a widget and keep live pricing in sync." Make it on purpose, before an engineer makes it for you by accident.

Compliance is the workstream that doesn't run on your schedule, and launches slip when teams treat it like it does. It has two halves, both gating launch and both waiting on other people, so both start the day you commit.

Verifying users is part of the flow, and how much of it you handle is up to you. There are three ways in, and they trade convenience for control:

• Let the widget verify. Mercuryo runs identity and liveness checks through Sumsub, the identity-verification service it uses under the hood, all inside its own flow, so you build nothing. What a user is asked for scales with the purchase, the market, and the payment method, so heavier checks appear only when they are needed.

• Reuse your existing checks. If you already clear users through Sumsub, pass a share token so they aren't asked twice. It requires a Reusable KYC contract with Sumsub and a partner token exchanged and verified with your integration manager, so raise it early. The token works once per person.

• Submit documents via API. Send the user's documents to Mercuryo through the API. The user still completes the liveness check inside the widget.

Whichever route you pick, how deep the check goes follows the amount, the user's country, and the payment method, and the widget handles that step for you:

You won't code the tiers, but knowing the 700-euro line exists lets you write clear in-app copy about when a user gets asked for more, so that step never surprises them mid-purchase.

Business verification is the deadline inside a document requirement

KYB verifies your company, not your users. It belongs to legal and finance, never engineering, and the provider's ask is specific:

• A short business-information form.

• Documents naming your directors, shareholders, and ultimate beneficial owners, meaning whoever ultimately owns or controls the company, even through a holding structure.

• Proof you own your domain.

• Individual verification of every director, shareholder, and UBO through Sumsub, with government ID and proof of address.

Then comes the clause that turns the list into a countdown. Every document must be issued within the last three months.

That check depends on people outside the build team and on current paperwork, so anything gathered too early goes stale and has to be reissued.

Leave it until engineering is done, and it becomes the reason launch waits on a director's proof of address. Start it in parallel on day one, and it clears while the build proceeds.

An on-ramp needs people most from launch onward. The human ownership matters from the first live transaction and keeps mattering after it. Three things need a name attached before any money moves, and "the team" is not a name.

The Merchant Dashboard ships three roles; your job is matching them to humans so each team sees what it needs and the dashboard hides what it should not.

The dashboard gives you a live view of transactions that you can export and filter by location and currency, alongside revenue, new sales, and user metrics over any time period.

The dashboard already shows the data; what's missing is a person assigned to open it. Name the human who opens it each day, because a dashboard no one opens is just an unwatched screen.

This is one of the few items you do not have to build yourself. The provider handles your end users directly, with 24/7 chat support.

That matters most around fraud and chargebacks. Card fraud reached 33.41 billion dollars in 2024, and card-funded crypto purchases carry that risk.

Because the provider acts as merchant of record, the legal seller on the transaction rather than you, it takes on the chargebacks and fraud disputes, which stay off your books.

What stays yours is the doorway. You decide how a stuck user reaches that support from your product.

You also decide who owns the KYC data and transaction detail in your own records, so support and finance read from recorded data instead of guessing.

The API allows 2000 requests per 5 minutes. Treat that as a budget you spend against. Poll rates and limits on every session and you draw it down fast, so design within it and ask to raise it before traffic reaches the ceiling, not in the incident afterward.

The second piece of engineering has a deadline too. Every message between you and the provider is stamped with a signature, a short fingerprint of its contents that breaks the moment anything is altered, so a tampered request gives itself away. The two directions use different methods, SHA-512 for the requests you send, and HMAC SHA-256 for the callbacks you receive, so your build generates one and verifies the other. Both are required work, not an optional extra.

Reporting lives in the same dashboard, open to all three roles. Give it a cadence, decide who pulls what and when, and month-end becomes routine instead of an emergency.

The argument, collapsed into the one table you hand around. Every row is a decision the docs assume you already made. Print it, put a name in the middle column, and work the right one.

Read the table back, and the pattern is hard to miss. Almost none of it is code. Only two rows are engineering, sandbox, and signatures, and both are contained pieces of work with clear specs. The rest of the table is decisions waiting for an owner.

The argument fits in that one table. Loading the widget is the small part, so that's never what sinks a launch.

Launches slip because the decisions around the widget arrive without owners and pile up near the deadline, spread across product, compliance, legal, finance, and support.

Settle them in the order they come due, put a name in the middle column, and the integration finally becomes the easy part it looked like from the outside.

The test of readiness is simple. Every row above has a name next to it, and the code was never the risk.

Once every row has an owner, the open question is time. For how the route you chose maps to a launch date, read How Long Does It Take to Integrate a Crypto On-Ramp? and set the schedule against the decisions, not just the build.

The provider acts as merchant of record and carries much of the regulatory weight, which is why an integration is a build project rather than the far longer road to building the rails yourself.

You are still responsible for holding whatever licenses your own operations require in the jurisdictions where you serve users, so confirm your obligations with your own legal team.

The provider, as merchant of record. Disputed payments, fraud, and chargebacks sit with them, not on your books.

2000 requests per 5 minutes, with the ability to increase it on request. If your traffic will exceed it, ask before launch, not after you hit the ceiling.