Migrate Crypto Payment Provider Without Losing Deposits

To migrate crypto payment provider safely, run both providers in parallel, route a small deposit share to the new rail, migrate deposit addresses by natural expiry rather than by force, and keep the outgoing provider live until every in-flight transaction has cleared and reconciled. Cutover is a routing exercise, not a switch.

Why does a crypto provider migration usually go wrong?

Almost never because the new API is hard. Crypto deposit APIs converge on the same primitives: generate address or invoice, watch for confirmation, webhook the credit, expose a settlement report.

Migrations go wrong for three mundane reasons.

• First, the operator schedules a hard cutover date, and on that date a non-trivial number of players are holding deposit addresses issued by the outgoing provider that have not yet been funded.

• Second, finance discovers in week five that the two providers report fees, FX spread and network costs in incompatible shapes, and month-end close slips.

• Third, nobody defined the rollback rule in advance, so when the new rail throws a 4% error spike on a Saturday night, the decision is made by whoever happens to be awake.

All three are avoidable with sequencing. The plan below assumes four to six calendar weeks, one platform engineer at roughly half capacity, and a payments lead who owns the go/no-go gates.

What should you measure before you touch anything?

Freeze a 30-day baseline first. If you skip this, you will spend the next quarter arguing about whether deposits improved.

Capture, per asset and per geography:

• Deposit conversion rate — deposit intents initiated divided by deposits credited. This is the number that funds the business case, and the target of any serious deposit conversion rate optimization work.

• Median and p95 time-to-credit — from first on-chain broadcast to balance visible in the player wallet.

• Failed and abandoned deposit rate — split into underpayment, expiry, wrong-asset, wrong-network and provider error.

• Effective cost per deposit in basis points — processing fee plus network fee plus FX spread plus any pre-funding cost of capital. Gross fee percentage alone is misleading.

• Support contacts per 1,000 deposits attributable to payments.

• Settlement lag — hours from credit to funds usable by treasury.

• Reconciliation break rate — unmatched ledger lines per 10,000 transactions.

Break each metric out by hour-of-day and day-of-week. A provider that looks fine on a Tuesday average may be your constraint at Saturday 21:00 CET.

How do you choose the second provider — and why "second" rather than "replacement"?

Reframe the brief. Most operators who set out to switch crypto payment gateway casino infrastructure end up better served by adding a rail than by swapping one.

Two integrated providers give you commercial leverage at renewal, geographic and asset arbitrage, and — the reason most teams start looking in the first place — payment provider failover iGaming coverage when one rail degrades.

Selection criteria that actually predict operational quality:

1. Asset and network coverage against your real deposit mix, not the marketing list. Check the top five assets by volume and the two you expect to grow.

2. Webhook semantics. Are credits idempotent? Is there a replay endpoint? Can you reconcile from an authoritative report, not just event history?

3. Treasury model. Custodial float means pre-funding, balance risk and an unwind at exit. Non-custodial settlement means neither.

4. Incident behaviour. Ask for 12 months of status history and the mean time to first human response on a P1 raised at 03:00.

5. Reporting granularity. Can you get txid-level records with fees decomposed? This determines whether reconciliation takes a day or a quarter.

Structure this as a scored matrix with weights agreed before demos. If you want a checklist to work from, our guidance on evaluating a replacement crypto payment gateway covers the technical and commercial questions worth asking in diligence.

What does a safe parallel run actually look like?

Parallel means both providers live in production, both able to issue deposit instructions, with a routing layer deciding which one handles a given request.

Build the routing layer before you integrate the second provider — it is the single most valuable artefact of the project and it is what makes every subsequent change reversible.

Minimum viable routing layer: a provider abstraction with one interface for address/invoice issuance and one normalised credit event; a weighted routing policy configurable at runtime without deploy; per-provider health checks; and a kill switch that forces 100% of traffic to a named provider in under 60 seconds.

The 5% canary is the important gate. Select the slice by hashing player ID so allocation is sticky — a player must not see one provider on Monday and another on Tuesday, because that creates duplicate address confusion and inflates your support queue.

Exclude VIP segments from the canary entirely. Hold the slice through at least one full weekend peak and one deposit-heavy promotional window before you touch the weights.

How do you migrate deposit addresses without breaking in-flight deposits?

This is where hard cutovers cause outages, and it is entirely preventable.

Assume that at any moment a meaningful share of your player base is holding an unfunded deposit address or invoice issued by the outgoing provider. Some were generated minutes ago; some are sitting in a screenshot from last week.

If you revoke those addresses on a cutover date, the funds still arrive on-chain and you now own a manual credit problem at exactly the moment your team is least able to absorb it.

The rule is: migrate by expiry, never by force.

1. Stop new issuance from the outgoing provider for the routed cohort. Existing addresses remain monitored and creditable.

2. Let addresses age out against their natural TTL. For invoice-based rails this is minutes; for static or reusable deposit addresses it may be 30–90 days, so plan for the longer tail.

3. Keep the outgoing provider's webhook listener and credit path fully live for the entire tail period plus a safety margin. This is non-negotiable.

4. Instrument a "legacy address funded" counter. When it reaches zero and holds for 14 consecutive days, the tail is closed.

5. Only then consider disabling the outgoing integration — and even then, prefer leaving it dormant but callable.

For any address type without a hard TTV, set a published sunset date, communicate it through your normal cashier lifecycle, and continue crediting late arrivals manually with a documented exception process. Budget for the exceptions; they are cheap compared to an unexplained missing deposit.

What routing and failover rules should govern the ramp?

Define the rules in writing before the canary goes live, with numeric thresholds and a named decision owner. Rules that hold up in practice:

• Health-based failover. Two consecutive failed health checks, or issuance error rate above 2% on a 5-minute rolling window, automatically diverts new issuance to the healthy provider. Existing addresses stay monitored on both.

• Latency failover. Address issuance p95 above 3 seconds for 10 minutes triggers diversion.

• Automatic rollback on conversion. If canary deposit conversion rate sits more than 1.5 percentage points below the control cohort across a minimum sample of 2,000 deposits, revert weights to zero and investigate.

• Confirmation-time guardrail. p95 time-to-credit must not exceed baseline by more than 20%.

• No unattended ramps. Weight changes happen Tuesday to Thursday, in business hours, with an engineer on hand for four hours afterwards.

• Idempotency everywhere. Every credit keyed on txid plus provider ID, so a double webhook during failover cannot double-credit.

Test failover in both directions before you call the migration complete. A failover path you have never exercised is a hypothesis, not a control.

Which KPIs prove the migration worked?

Report against the frozen baseline, cohort-split, for 60 days post-ramp. The headline set:

• Deposit conversion rate delta, overall and for first-time depositors. First-deposit conversion is the most sensitive indicator of cashier friction.

• p50 and p95 time-to-credit delta.

• Failed deposit rate by cause, so you can distinguish player error from provider error.

• Effective cost per deposit in bps, fully loaded with network fees, spread and pre-funding cost.

• Settlement lag and treasury utilisation — how much working capital is no longer parked in float.

• Availability — minutes of degraded deposit capability, and how many were absorbed by failover rather than experienced by players.

• Reconciliation break rate and days-to-close at month end.

A credible result looks like: conversion up 1–4 points, p95 credit time down materially, cost per deposit down 10–40 bps, and zero deposit-outage minutes during the entire cutover. If you cannot evidence the last item, the plan was not followed.

Operators who want redundancy live before the next peak season can run LightningPay as your redundant crypto rail alongside an existing provider, starting at a 5% slice.

How do you reconcile across two providers?

This is the half that bites. Two rails mean two fee schedules, two reporting formats, two timestamp conventions and one cash position that finance has to sign.

Do the mapping in Phase 1, not Phase 4. Build a single normalised transaction ledger in your own warehouse, with provider as a dimension rather than a separate table. Key on on-chain txid where available.

Decompose every line into gross amount, processing fee, network fee and FX spread, and store the provider's raw payload alongside the normalised record so disputes are resolvable.

Then run a daily three-way tie-out: your platform ledger, each provider's settlement report, and the on-chain or treasury view. Set a break tolerance in absolute terms, not percentage, and escalate anything unmatched after 48 hours.

Agree with finance in advance how dual-provider months will be presented, and dry-run one month-end close while the canary is still at 5%. Discovering a reporting gap at 5% of volume is an inconvenience; discovering it at 50% is a close delay.

What makes the LightningPay rail specifically low-risk to migrate onto?

One capability matters most in a migration context: instant Lightning Network settlement with non-custodial treasury — no float to pre-fund, and no balances stranded at a departing provider.

The migration consequences are direct. There is no custodial balance to unwind, because funds settle to treasury you control rather than accumulating in a provider-held account. There is no withdrawal queue with the outgoing PSP competing for attention with your cutover, because you are not waiting on anyone to release your own money.

And the new rail can be switched on for a 5% traffic slice without moving treasury at all — no pre-funding decision, no capital committed to an unproven integration, no sunk position to defend if the canary underperforms and you roll back to zero.

That last point is what makes a genuine canary possible rather than theatrical. When standing up a second rail requires no capital allocation, the cost of testing it in production approaches the cost of a config change, and redundancy stops being a budget conversation.

When should you decommission the old provider?

Default answer: don't, at least not in year one. Once the routing layer exists, the marginal cost of keeping a second integration warm is a contract minimum and a quarterly failover test — cheap insurance against a rail-level incident.

Decommission only when the outgoing provider's legacy address tail has been closed for 14 days, two consecutive month-end closes have completed clean, failover has been exercised in both directions, and commercial terms make maintenance genuinely uneconomic. Even then, retain the integration code behind a feature flag and keep credentials valid.

If you'd rather validate the sequencing against your own deposit mix and address TTLs, get a cutover plan from the LightningPay team before you commit to dates.

Final thoughts

Redundancy, not replacement, is the correct default end state — the operators who sleep best are the ones who can move deposit traffic between two live rails with a config change and no capital movement.

The migration itself is a routing problem plus a reconciliation problem, and the reconciliation half is what actually bites: routing is a fortnight of engineering, while two fee models converging on one auditable cash position is a finance workstream that must start in week one.

Force nothing — let addresses expire, let the canary run through a real peak, and let the numbers rather than the calendar decide each ramp. Above all, freeze your baseline before you integrate; without it you will have changed your infrastructure and still be unable to say whether it helped.