Mercuryo integration: what breaks without deposit and withdrawal
A crypto project enables card payment, the user reaches the form, clicks "pay" — and then nothing happens.
The external deposit and withdrawal channel is not connected or is half-connected: the interface can show the payment screen but cannot bring the operation to a final status.
Funds go to the provider, and the callback notification — confirmation or refusal — does not arrive, gets lost, or is not matched with the internal request ID.
The cost of failure is visible in metrics: the share of incomplete operations grows, payment status hangs in "pending" for hours, the user closes the app and leaves.
Support manually reconciles statements, refunds are processed by request, and the discrepancy between the balance in the crypto project and the actual receipt accumulates until the first reconciliation.
The most expensive thing is not an individual payment but a lost channel: a person who once did not see the result no longer pays by card within the product — and this cannot be restored by fixing the interface.
Mercuryo integration closes exactly this gap: a status model, matching operations by ID, handling repeated notifications and automatic recovery of incomplete scenarios.
Below we analyze how working deposit and withdrawal are structured and where it most often breaks — at the junction of identifiers, retries and provider refusals.
What connected deposit and withdrawal gives the project
Connected deposit and withdrawal via Mercuryo is not a separate "buy crypto" button, but part of the main payment scenario. After launch, we check the result against a checklist: each item is measured before and after, so the effect is visible in numbers, not feelings.
- Share of completed payment scenarios. Previously, a person left to a third-party platform and did not always return; now deposit and withdrawal happen inside the product, and the funnel is counted as a single slice, without dropped steps.
- Crediting time. Operation status is visible in the interface, rather than being clarified through support: crediting fits within minutes, and repeated payment attempts that inflated the load disappear.
- Support requests. Questions "where is my money" and "why didn't it arrive" are resolved by a clear status and error text on the screen — the share of such requests drops severalfold in the first month.
- "No channel" failure class. If a deposit method is unavailable for a region or amount, the scenario offers the next one instead of a dead end — this failure disappears from reporting as a phenomenon.
- Operation reconciliation. Each operation is assigned an identifier linking payment, crediting and entry in the accounting system: discrepancies are caught automatically, not at period closing.
We run the checklist on a test environment before release — that's why on the production channel the effect is visible from the first weeks, not after a quarter of observations.
Connection methods: own gateway, service partner, hybrid
Deposit and withdrawal are rarely covered by one solution: the three schemes differ not so much in feature set as in who is responsible for identity verification and operation routes.
We examine where the boundary lies between an own gateway, an external service partner and their combination.
How the options differ in practice
| Option | When it fits | Limitations |
|---|---|---|
| Own gateway | Own user flow, non-standard scenarios, full control over identity verification needed | Longest launch time; you keep route support and verification with your team |
| External service partner | Fast launch and low volume needed, ready to delegate identity verification | Flexibility of currencies and directions limited by partner's capabilities, growth hits its limits |
| Hybrid scheme | Critical directions on your own gateway, the rest via partner | More complex accounting and reconciliation: unified reporting on operations needed |
A hybrid scheme appears where it is important to keep some directions in-house — for control over identity verification — while it is faster to give the rest to Mercuryo as a partner.
A unified accounting and reconciliation layer is mandatory here, otherwise discrepancies in operation reporting turn into a separate project.
The final choice rests on launch time and readiness to maintain a team that supports payment routes.
Implementation stages: from scenario audit to handover
We start not with code but with an operation registry: which deposit and withdrawal methods are needed, in which currencies, who initiates payment and who bears the refund in case of failure.
The scenario audit shows where limits and client verification are required, and where the flow is fully automatic.
- Scenario audit. We compile into a table card and transfer deposits, card and account withdrawals, retries, cancellations, refunds, manual adjustments — with limits and client verification requirements opposite each.
- Flow diagram. We fix the operation movement from interface to bank: where the identifier is created, where status changes, where history is stored, at what point a rollback is provided and who is responsible at each section.
- Channel setup. We create keys and request signing, separate test and production environments, define currency pairs, limits and rules for processing status change notifications with protection against reprocessing.
- Test operations. We run not only successful passes but also failures: insufficient funds, rejected verification, response timeout, duplicate notification. We reconcile amounts and statuses for each operation.
- Reconciliation and recovery. We set up regular comparison of our registry with Mercuryo reports and auto-retry of incomplete operations — discrepancy is found the same day, not surfaced in support.
- Handover to operation. We provide documentation, flow diagram and incident handling regulations, enable failure alerts, support the channel after launch and make adjustments when adding new payment methods.
What remains with the team after implementation: configurations and regulations
After implementation, the team retains not only a working deposit and withdrawal scenario but also a kit by which the integration can be maintained on its own — without contacting the code authors. We complete the integration with Mercuryo with a set of artifacts:
- Integration configurations — parameters per environment with an explanation of purpose: per-operation limits, available currencies and payment methods, timeouts, failure behavior.
- Interaction diagram — flows from client to provider and back via webhooks, with points of payment creation, confirmation and closure.
- Access rules — roles, rights to change settings, signing key rotation, procedure for suspected compromise.
- Event log — unified recording format for each operation with payment identifier: status, time, error code, initiator.
- Incident regulations — classification of failures (payment not received, lost webhook, double crediting), procedure and response times.
- Documentation — deployment instructions, environment composition, acceptance checklist and record of decisions made.
The kit removes the main maintenance risk — when one person keeps the integration in their head. Changing limits, connecting a new payment method or analyzing a failure follows a document and takes hours, not days of searching through chats.
Case study: share of incomplete operations and refund time
The project is a crypto service with fiat deposit and withdrawal.
Before integration, the user underwent verification and payment on the side of the payment window, and at each transition part of the audience was lost: a person reached payment method selection and closed the page.
Support received requests "money was debited, balance empty" and manually reconciled statuses.
What was measured before
Over a month of observations: share of abandoned deposit scenarios — about one third of started, average crediting time — from twenty minutes with manual reconciliation, refund of erroneously debited funds — up to three business days. Support accounted for about half of all product requests.
What was changed
We moved deposit and withdrawal inside the product on Mercuryo: the user does not leave the interface, operation status arrives via webhooks and is immediately reflected in the personal account.
Verification and payment method selection were combined into one step, idempotent retries were added for stuck operations and automatic refund on provider-side failure.
What was achieved
The share of incomplete operations decreased to 11%, crediting time — to 2-4 minutes in most scenarios, refunds are processed within an hour without operator involvement.
Support requests on deposit and withdrawal decreased by about three times — the freed time went to handling complex cases.
How Mercuryo integration differs from your own payment infrastructure
Short answer: Mercuryo is a ready-made provider that takes on deposit and withdrawal, identity verification and work with local payment methods. Own infrastructure means all this is built and maintained inside the company.
The difference shows in four things: launch speed, responsibility area, flexibility of rules and operational costs.
In terms of timelines and responsibility, the picture is this. With Mercuryo integration, the main work is connecting the ready-made module to your application, setting up deposit and withdrawal scenarios and passing compliance review.
Identity verification, operation processing, payment method support and fraud prevention remain on the provider's side.
With own infrastructure, the team itself negotiates with banks and payment intermediaries, maintains user records, handles refunds and disputed operations — launch timelines are measured in months, not weeks.
Flexibility of rules is the flip side of this speed. With a provider, limits, country list and document set for verification are set by its policy: this is predictable and compliant, but you can adjust them to your model only within available settings.
Own infrastructure gives full freedom of rules, but also full responsibility for their compliance with the regulator.
Operational costs in the two models are of different nature. An own solution means constant on-call duty, monitoring, updating bank integrations, audit and user support. With a provider, these costs are distributed across all clients, and you pay for completed operations. Own infrastructure pays off when volumes and special scenarios no longer fit into ready-made rules.
Technical concerns: limits, failures, operation verification
Deposit and withdrawal via Mercuryo is an asynchronous process: confirmation arrives as a separate notification and on the network may overtake the response to the original request or arrive again.
Therefore, we proactively close the scenarios that most often break acceptance and turn into manual operation handling.
What to do if the response to a request did not arrive or arrived twice?
Each operation is assigned a unique idempotency key, so resending a request with the same key returns the original result rather than creating a second operation.
We reconcile the actual state with a separate status request — discrepancy between our database and the provider is closed in one pass, without manual balance adjustments.
What are operation limits and what do they depend on?
Minimums and maximums depend on region, payment method and identity verification level. We move them into configuration, not code: changing a threshold does not require a release.
On failure, the client receives a specific reason — limit exceeded, region not supported, verification not completed — rather than a generic execution error.
How is request retry structured?
Retries use increasing delay and a limited number of attempts; after exhaustion, the operation goes to a queue for review rather than being lost. Each attempt and its result are recorded in the log, so the incident shows exactly what and when was sent.
Who has access to identity verification data?
Documents and personal data are processed on the provider side — we store only the verification identifier and status. Access to logs is role-based, accesses are logged, revocation of access to data is a managed operation, not a manual export.
Let's discuss the task: what data is needed for assessment and plan
An accurate Mercuryo integration assessment does not require production access — inputs on scenarios and fund movement are enough. The more specific the initial data, the fewer clarifying rounds and edits in the implementation plan midway.
Below is the minimum sufficient to assemble the flow architecture and give timelines. If something is not at hand, describe it in words: we will close the gaps on a call with engineers.
- Scenarios: which operations the on/off-ramp covers — deposit, withdrawal, conversion, recurring charges, mass payouts.
- Current fund movement scheme: where the balance is stored, through which accounts and custodial services money flows, what is currently done manually.
- Regions and requirements: user countries, mandatory local payment methods, settlement currencies, data storage rules.
- Identity verification: required verification level, document set, who handles rejections and how this is shown to the user.
- Technical environment: backend and mobile app platforms, availability of a test environment, readiness for API exchange.
- Event handling: whether notifications about operation status changes are needed, protection against repeated requests, how accounting and reconciliation are maintained.
- Restrictions and timelines: regulatory prohibitions on certain directions, operation ceilings, launch date and external partners in the schedule.
This is sufficient for assessment: we will describe the flow diagram, break down stages, risks and points where decisions are made on your side. Describe the task — we will come back with an assessment and plan.