Accepting Crypto Payments in an App: Where the Chain Breaks
Accepting crypto payments in a mobile app doesn't break on the blockchain — it breaks at the junction of the wallet, the network, and the merchant's logic.
The customer taps "pay," the transaction goes into the mempool — and from there begins a zone where typical mistakes cost real money and reputation.
The first class of failures is a mismatch in the amount. The exchange rate is recalculated at the moment the invoice is created, but payment confirmation arrives minutes later, when the quote has already moved.
If the app compares "how much arrived" against "how much was expected" without an allowance for volatility and network fees, the payment falls into an error state even though the customer paid correctly.
The second is a lost confirmation: the provider's webhook didn't arrive, the app closed in the background, and the transaction status got stuck in a "pending" state.
The third is a stuck payment, when the transaction is on the network but the required number of confirmations doesn't come for hours due to congestion or a fee set too low by the wallet.
A separate headache is double sending. The customer didn't see a response, tapped again, and two transactions for a single purchase went out to the network.
Without idempotency on the merchant's side and a unique invoice identifier, such cases get resolved manually, and refunding funds in crypto is a separate operation with its own fee and risk.
The cost of every failure isn't just a lost payment.
It's manual investigations, a customer's loss of trust, and support drowning in tickets saying "the money left, the goods never arrived." Let's break down how to build the chain "invoice — payment — confirmation — crediting" so that it doesn't break at any of these points.
What a correctly built crypto payment acceptance flow delivers
The key measurable effect is the share of successful transactions. When the application itself tracks confirmations on the blockchain and correctly handles retries, stuck payments, and fee replacement, the percentage of operations abandoned midway drops severalfold.
The client sees an "paid" status in the app instead of guessing whether it went through — and doesn't write to support.
The second effect is crediting time.
The network may confirm a transfer in minutes or tens of minutes depending on load, and the application must honestly show intermediate states: "awaiting confirmation," "funds received." This removes the main reason for inquiries: a person doesn't understand why the money left but the order wasn't activated.
The third is a reduction in manual operations. Automatic reconciliation by address and amount, rule-based resolution of discrepancies, and re-checking on network failure eliminate manual payment searches by hand.
The support team stops manually matching transfers and dealing with "paid but it didn't arrive."
The fourth is resilience to network spikes. When fees and confirmations are configured dynamically, and the operation queue survives an application restart, surges in network load don't turn into lost orders. Crypto payment acceptance stops depending on how lucky the moment the client chose was.
Taken together, the implementation delivers a predictable flow: fewer abandoned carts, fewer inquiries, a clear picture for every payment. Let's break down how this is structured in a merchant application and what exactly affects these metrics.
Integration Methods: Direct Connection, Gateway, Hybrid
The integration method determines who holds the private keys, who counts confirmations in the blockchain, and who is responsible for handling forks and transaction replacements.
This affects the requirements for the team, the crediting speed, and the class of failures the application must survive.
Direct Connection
The application generates addresses itself, monitors incoming transactions, and maintains its own balance accounting. Suitable when full control over crediting logic is needed and there are no intermediaries in the chain.
Limitations: you need to deploy and maintain network nodes, keep hot wallets in a secure environment, and handle blockchain reorganizations and stuck transactions yourself.
Payment Gateway
The provider handles address generation, network monitoring, and conversion, and delivers webhooks about payment status to the application. Suitable when fast launch matters and you don't want to maintain node infrastructure.
Limitations: dependence on the provider's availability, its confirmation count rules, limits and fees, as well as being tied to its API when switching providers.
Hybrid Scheme
Keys and accounting remain with us, while network monitoring and some operations are delegated to the provider. Suitable when control over funds is needed but there are no resources for full node maintenance.
Limitations: the scheme is more complex — you need to clearly divide areas of responsibility and synchronize statuses between your system and the external service.
| Option | When it fits | Limitations |
|---|---|---|
| Direct Connection | Full control over keys and crediting logic is needed | Your own nodes, wallet security, handling network reorganizations |
| Payment Gateway | Fast launch without your own infrastructure | Dependence on the provider, its limits, fees, and confirmation rules |
| Hybrid Scheme | Control over funds without full node maintenance | More complex status synchronization between your system and the service |
The choice of method is dictated by the number of assets, the required crediting speed, and the team's readiness to maintain infrastructure. During a task review, we will compare your conditions against these options and propose a scheme tailored to them.
How we build crypto payment acceptance in an app
Work begins with an audit of the scheme: we look at how payment acceptance is currently structured, where keys are stored, who confirms crediting and how, and which events go to the backend and accounting.
At this stage it is important to understand whether you have a custodial service or your own wallets, whether automatic conversion is supported, and how the app withstands a network interruption at the moment of a transaction.
Based on the audit results, we identify bottlenecks and risks — from lost events to a balance discrepancy between the blockchain and internal accounting.
Next, we design the target scheme: we choose the acceptance model (a personal address per payment, a merchant account, or a payment gateway), determine which networks and assets we support, how we count confirmations, and at which threshold we credit funds.
Separately, we work through the idempotency of operations and behavior on repeated notifications — this is what most often breaks accounting during failures.
- Audit of the current scheme — analysis of payment flows, key storage, failure points, and current accounting.
- Architecture design — acceptance model, list of networks and assets, logic of confirmations and crediting.
- Integration setup — connecting a provider or your own nodes, webhooks, processing transaction statuses.
- Implementation in the app — payment screen, statuses, transaction history, correct operation when connectivity is lost.
- Testing on test networks — running scenarios: success, underpayment, expiration, repeated notification, rollback.
- Security and access — role separation, key protection, logging of operations.
- Documentation handover — regulations, flow diagrams, instructions for support and accounting.
We carry out testing on test networks, where we reproduce not only successful payments but also exceptional ones: underpayment, an expired invoice, a repeated webhook, cancellation.
Each scenario must lead to a predictable status in the app and in accounting — otherwise in production this turns into manual investigations.
We finish with the handover of documentation: flow diagrams, regulations for handling disputed operations, instructions for support, and rules for reconciliation with the blockchain.
The client's team receives not only working crypto payment acceptance but also a clear process for maintaining it.
What the client receives upon completion of implementation
Implementation ends not with a demonstration of a working screen, but with the handover of a complete set of materials that your team can use to operate crypto payment acceptance without us.
Each artifact addresses its own class of tasks: configurations — reproducibility of environments, diagrams — understanding of the payment route, policies — access separation, instructions — on-call actions, regulations — behavior during failures and refunds.
- Environment configurations — connection parameters to blockchain nodes and providers, limits on amounts and operation frequency, retry settings for network failures. Deployed from a repository, not assembled by hand.
- Payment flow diagrams — from invoice initialization in the application to confirmation on the network and crediting: where the address is generated, how many confirmations we wait for, at what point the order is marked as paid, how underpayment and overpayment are handled.
- Access policies — roles for support, development, and finance, separation of rights for viewing operations and for refunds, handling of keys and secrets, rotation of access credentials when an employee leaves.
- Support instructions — what to do when a transaction is stuck, how to check the status on the network, when to escalate to an engineer, which actions are prohibited without approval.
- Regulations — the procedure for refunds, handling discrepancies between the application and the network, response to a provider outage, the plan for switching to a backup route.
- Integration documentation — description of merchant interfaces, request and response formats, error codes and their interpretation for customer support.
- Monitoring and alerts — a set of checks for the share of unconfirmed operations, crediting delays, and growth in declines, with thresholds at which the on-call operator receives a signal.
We hand over the complete set in your format: repository, wiki, or internal portal — as is customary for you.
After handover, we conduct a walkthrough with the team so that the artifacts do not remain unread, and we remain on support until the moment your engineers run the system on their own.
Case study: how we reduced the share of stuck crypto payments
A merchant with a turnover of several thousand orders per day came with a problem: some crypto payments were "stuck" between network confirmation and crediting in the app.
The customer's funds were debited, the order status did not change, and support handled each such order manually.
The share of stuck payments reached 6% of all transactions, the average crediting time was 40+ minutes, and manual investigations took several hours of support work daily.
What it was before
The payment module polled the network on a timer and did not distinguish between the statuses "transaction in mempool", "partially confirmed" and "finally confirmed".
When the network was congested or the fee was replaced, the transaction fell out of the polling window — the order remained in the "awaiting payment" state, even though the money had already been sent.
A separate pain point was the lack of idempotency: a repeated webhook from the provider created a duplicate order, and accounting reconciled the discrepancies manually.
What was changed
We switched acceptance to an event-driven model: instead of a timer — a subscription to confirmations via the provider's webhooks with mandatory verification by transaction hash.
We introduced a finite state machine for order statuses with explicit transitions and protection against repeated processing — each webhook is checked for uniqueness by event identifier.
We added a background reconciler: every few minutes it reconciles open orders with the state of the blockchain and brings them to the final status without human involvement.
For networks with high fees, we configured dynamic estimation and resubmission with a correct confirmation threshold.
Metrics before and after
| Indicator | Before | After |
|---|---|---|
| Share of stuck payments | ~6% | less than 0.4% |
| Average crediting time | 40+ min | 2-4 min |
| Manual investigations per day | dozens | isolated cases |
| Duplicate orders from repeated webhooks | regularly | eliminated |
Manual investigations were reduced by an order of magnitude, and support switched to customer questions instead of reconciling transactions.
The solution was built on Coinbase Commerce as a payment provider with an open API — this provided transparent status reconciliation and the ability to add a custom reconciler for specific networks.
How does a direct integration differ from a payment gateway?
A direct integration means the application itself generates the payment address, monitors incoming transactions on the blockchain, and confirms crediting based on the required number of network confirmations.
A payment gateway is an intermediary: it takes on address generation, network monitoring, conversion, and webhooks, while the application communicates with it through a single API.
The difference shows up not in interface convenience, but in who holds the keys, who is responsible for a failure, and how deeply you can control the logic.
Control is the first divergence. With a direct integration, private keys and crediting logic remain with you: you can set your own rules for confirmations, fees, and refunds, and connect any networks and tokens without being constrained by someone else's functionality.
A gateway limits that flexibility — you operate within its rules, and support for new networks depends on its timelines, not yours.
Launch speed is the opposite: a gateway can be set up in a matter of days, because all the blockchain work has already been done for you. A direct integration requires your own infrastructure — nodes, a transaction indexer, handling reorgs and retries.
On the other hand, after launch you don't pay an intermediary for every operation and don't depend on its availability.
Support complexity is the main dividing line. A gateway takes on network monitoring, protocol updates, and resolving stuck payments, but adds a point of failure: its downtime halts acceptance.
A direct integration doesn't create that dependency, but it requires your own team to keep nodes up to date and handle incidents. The choice here isn't about "better or worse," but about whether you're ready to keep that area of responsibility in-house.
Common technical concerns about accepting crypto payments
Accepting crypto payments in a mobile app works differently from card acquiring, and this raises the same questions among clients. Below are answers to the technical concerns that most often come up before integration starts.
How is the security of accepting crypto payments ensured?
The merchant's wallet private keys are not stored on the client's device and do not end up in the mobile app. Transaction signing is performed on the service side, and the app only receives the payment address and the operation status.
Access to funds is restricted by a role-based model and confirmation through a separate secure channel, so compromising the client device does not give access to the merchant's balance.
Are refunds possible if the client paid with cryptocurrency?
A refund in the original coin is technically possible, but it depends on the exchange rate and network fee at the time of the operation, so the interface includes a refund scenario in a fiat equivalent or via an internal balance.
We design the logic so that disputed situations are resolved predictably for the client and do not create discrepancies in accounting.
Who pays the network fee and how does it affect the final amount?
The network fee is paid by the sender, and its size varies depending on blockchain load.
So that the client does not encounter an unexpected amount, the app calculates the fee in advance and shows it before payment confirmation, and also tracks the transaction status until final crediting.
How does accepting crypto payments integrate with the existing stack?
Integration goes through API and webhooks: the app initiates a payment, the service confirms crediting and passes the event to your accounting system.
The existing logic of orders, statuses and notifications is preserved — crypto payments are added as another payment method rather than replacing the current ones.
If you still have concerns about a specific scenario — describe the task, and we will come back with an estimate and a plan.
Let's discuss your crypto payment acceptance task
To come back with an estimate and a work plan rather than generalities, we need to understand your crypto payment acceptance scheme at the level of flows: who pays, on which networks and in which tokens, how crediting is confirmed, and what happens in case of underpayment, overpayment, or a stuck transaction.
Send us your current logic — even as a description or a napkin sketch — and we'll clarify the details ourselves.
What's worth clarifying at the start:
- Which networks and assets you accept and plan to add — the choice of provider and the confirmation logic depend on this.
- Who holds the keys: a custodial service, your own wallet, or a hardware signing module.
- How payments are currently reconciled — manually, via provider webhooks, or through your own blockchain indexer.
- Requirements for the number of confirmations and acceptable crediting time for different amounts.
- Whether fiat conversion is needed and at which stage — upon crediting or on a schedule.
- How refunds, partial payments, and disputed transactions are handled under your rules.
- What reporting data accounting needs and how it gets into the books.
- Whether there are restrictions on payer jurisdictions and address screening.
Based on these answers, we'll put together a work plan: the acceptance architecture, the confirmation scheme, error and rollback handling, and the scope of pre-release checks.
The estimate will be broken down by stages, with explicit assumptions — so you can see what's included in the work and what stays on your side.
Describe the task in free form — we'll come back with an estimate and a plan, and along the way we'll work through the contentious points and suggest how to close them.