How Long Does It Take to Integrate a Crypto On-Ramp?

A launch date needs a finish condition, and "live" can mean three different things.

For an on-ramp, "live" might mean a test payment worked, a user received crypto in a wallet, or support can trace and resolve a failed purchase. Each promise sets a different completion point, and a wider one costs more days.

That is why the order matters. Publish a date while the promise is still open, and the schedule then depends on every scope decision you make later.

The pattern is well documented. More than two-thirds of large technology programs surveyed by BCG were expected to run over on schedule or budget, or ship less than planned, and unsettled scope is one reason a date can move before work even starts.

Three decisions set that scope, and each one moves the estimate.

The route is the first scope decision. A redirect sends the user to a page hosted by the provider and carries the lowest documented implementation effort. An iFrame places that page inside your site, which adds domain configuration and camera access to the testing plan.

Mobile introduces device-specific behavior. On Android, the in-app browser used for the standard flow cannot run Google Pay, so that payment method needs a different browser window. A mobile estimate therefore depends on which devices and payment methods ship at launch.

Reusing what your product already has expands the job again. Silent authentication lets the on-ramp recognize a user who is already signed in to your product. And if you already verify users through Sumsub, a share token passes approved identity data to the provider so the user isn't asked to verify twice.

Both run outside the visible flow. Neither happens on the purchase screen the user sees, so neither shows up in a quick demo.

Before naming a date, write one sentence describing the release's completion. A defensible version requires crypto reaching the wallet and a status trail that support can follow from payment through delivery.

Either side can set the launch date, so the calendar has to track the provider's steps separately from your team's.

• The provider controls access approval. Your team controls the route and the connections to existing accounts, plus the proof required before release. Access follows a published onboarding order: sandbox credentials first, then production credentials after business approval. A sandbox is the test environment where the purchase flow runs without moving money.

• This is where the schedule can compress. Sandbox access arrives before approval, so your engineers can start building. At the same time, the provider reviews the company, and the one-week review can overlap with the build instead of delaying it.

• The business file still comes first. The company submits a questionnaire and recent corporate records, while directors and other relevant owners complete identity checks. The documentation doesn't say whether collecting those materials counts within the published week, so put document collection on the plan before the review starts.

Then run the review and the sandbox work in parallel, and let the release wait for whichever side finishes later.

Four phases run from usable sandbox access to a live purchase. Each one holds a defined piece of work, from opening the test environment to confirming a real purchase in production.

Two assumptions frame them. Count from the moment sandbox access is usable, and assume an engineer is on the job and the product already has user accounts and a wallet destination. Building either of those sits outside this plan.

So, the table separates the one published figure from the technical work your team still has to size.

The phases overlap. Mercuryo issues sandbox keys so partners can start testing before KYB finishes, and production keys after it clears. The review and the build can overlap, and the release waits for whichever finishes later.

For the three phases without a published figure, the estimate comes from the engineers who own the implementation, not from a standard timeline.

The route still changes how much work the build takes. Mercuryo does not publish a duration for any route, so the difference is one of complexity, not of days you can copy into a plan.

Mercuryo documents redirect as the simplest method, with the lowest implementation effort. It sends the user to a page the provider hosts, with nothing to embed. An iFrame places that page inside your site, which adds domain configuration and camera access for the KYC liveness check. Mobile introduces per-platform requirements, including a separate browser window for Google Pay on Android.

Use those differences to compare the effort each route demands. Don't assume a fixed number of working days.

A demo that opens the purchase screen proves only that the screen loads and accepts input. Estimates fail between that screen and a finished purchase, because payment and crypto delivery are recorded as two separate operations.

The transaction documentation shows why. A successful card purchase creates a second operation that sends the crypto to the user's wallet, and payment can finish while that delivery stays pending or fails.

The hidden build work sits in linking the two. Your product has to connect both operations to the same internal order, so support can tell a declined payment apart from crypto that never reached the wallet.

Status changes arrive through callbacks, which are messages the provider sends to your server. The delivery policy retries an unconfirmed message for up to three days and treats an HTTP 200 response as confirmation.

That retry behavior creates a second requirement. Because the same message can arrive again, your system should apply each update only once; otherwise, a retry can duplicate an internal action or leave the order in the wrong state.

The documentation describes only the retry, so the safe-to-repeat handling falls to your team.

The finish condition you commit to is testable. In a successful case, the crypto reaches the wallet. In a failed one, the reason shows correctly. And when the same callback arrives twice, the internal order stays put.

All three stay on the release plan even when the widget looks finished on day one, so allow time to prove status handling works, in addition to the time to build it.

Four documented settings can stop the flow. Most clear with a configuration or access change, and the Android one needs a different browser window.

The migration checklist covers five steps before full release. You update the URLs to production, obtain production credentials, swap in production API keys, point the callback at a production address, and run one small live purchase.

That last purchase checks the complete chain after the URLs and credentials change, so reserve time for it and name who can inspect the order when payment succeeds but delivery does not.

The provider's purchase flow returns currency availability by country and the minimum and maximum purchase for each fiat-to-crypto combination. Define the first-release markets and payment methods before testing, so the team checks the combinations users will receive.

Three launch purposes share the same minimum test, and the purpose decides how much product scope surrounds it.

Every release ends with crypto in the wallet and a low-value production purchase. Testing a repeated status message belongs on the plan too, so a retry never changes the order twice.

A demand test only asks whether users complete a purchase. A campaign date needs support instructions ready, because traffic arrives on a fixed day. A core purchase journey requires more, since the app has to carry the transaction after the provider page closes.

The point is to pick one before you estimate. Choose the row before engineering estimates the job, because combining all three makes engineering test for account reuse and deep status screens that the release does not require.

A go-live date is defensible once the plan names the route, the required account connections, and the finish condition for each phase, and records which dates depend on provider approval.

Ask the assigned engineer for a low, expected, and high duration on each team-owned task. The PMI Practice Standard for Scheduling builds its method on that pattern, asking for three durations per activity, from optimistic to pessimistic, developed with the people who will perform the work.

With those estimates in hand, confirm five items in the integration review:

1. The complete company file is ready for business review.
2. Every test system has sandbox access.
3. The route and optional account connections are fixed for the first release.
4. Testing follows payment through to wallet delivery and repeats one status message to confirm a retry changes nothing.

The production plan includes a low-value purchase and a support owner.

Teams still deciding which layers they will own should resolve that first in Build Your Own Crypto On-Ramp, or Use a Provider?, since that choice determines which tasks belong in this timeline.

With scope settled, a team integrating Mercuryo can confirm the provider-side steps for review and production access with the integration team.

Once those answers are recorded, the roadmap date points to a release you can describe in full, with a name against every dependency. If the scope changes later, revise the range at the same time.

Plan around the business review, which runs about a week, with the build happening in parallel. The route you choose and the size of your team set the rest, so the firm date comes from your engineers once the scope is fixed.

Redirect is the simplest route to build, but production still needs KYB approval, which typically runs about a week, plus wallet delivery checks and one live purchase. That puts even the lightest launch beyond a few days.

An incomplete business file, test systems without access, a wrong embedded domain, or a mobile payment method that needs a different browser flow. Account reuse adds more.