Why a crypto payment gateway mobile app breaks during peaks
A peak failure of a crypto payment gateway is almost never about a "crashed server." It looks different: the customer tapped "Pay," the app showed "awaiting confirmation," the network confirmed the transfer, but the payment status in the interface just kept hanging.
The user leaves, writes to support, and on the business side there's a stuck transaction that no one can unambiguously close.
The root of the problem is confirmation desynchronization. The network doesn't confirm instantly and not always on the first try: a transaction can land in the mempool, get stuck due to the fee, or be replaced.
If the app polls the payment status on a timer, during a volatility spike or a listing the timers break down, responses arrive out of order, and the last received status turns out to be stale.
The customer sees "processing" where the payment has already gone through, or conversely — "success" on a transaction that later rolled back.
Peak loads finish off this scenario. At the moment of a listing or a sharp price move, the number of simultaneous payments grows severalfold, and an app tied to synchronous requests to a network node starts accumulating stuck transactions in batches.
The error isn't isolated — it reproduces on every spike, and support can't keep up with handling requests manually.
Let's break down how this gets closed: idempotent operations, confirmation intake that's resilient to reordering, and an explicit payment state machine where every status has a lifetime and an escalation rule.
What the reworked gateway application delivers
The reworked application changes not the appearance but the behavior of the gateway under load.
The operation status reaches the client as confirmations arrive on the network — instead of waiting for the final settlement — so the confirmation speed on screen drops from tens of seconds to a few, and the user sees intermediate states rather than an empty indicator.
The share of stuck operations that previously required manual review falls thanks to explicit handling of every state: the application knows what to do when a transaction is replaced, a signature is rejected, or a timeout expires, and does not leave a payment in limbo.
Resilience to spikes is ensured by the fact that status requests go through a local cache and a retry queue rather than hitting the gateway every time a screen is opened.
During a massive influx — a sale, a listing, a price jump — the application does not create an avalanche of requests: some responses are served from the cache, the rest are queued with an increasing delay.
This eliminates the class of failures related to overload: timeouts, duplicate charges, and "stuck" waiting screens disappear because the client stops hammering the server at the moment of peak load.
A separate class of network-side failures is also closed: a connection drop in the middle of a signature, a network switch, the application going to the background.
An unfinished operation is restored from local state on the next launch rather than lost — recovery time after a failure is measured in seconds because the application does not need to go through the entire path again.
The bottom line on metrics: status confirmation speed is several times higher, the share of stuck operations is a few percent instead of a noticeable share, behavior during spikes is predictable, and the class of failures is network and overload related.
Integration options: custodial, non-custodial, hybrid
The choice of mode determines where private keys live and who signs transactions — this affects both the threat model and the amount of work on the application side.
In custodial mode, keys are stored by the payment service, and the application only initiates operations and displays the balance. In non-custodial mode, keys are generated and remain on the user's device, and transaction signatures are formed locally.
The hybrid scheme separates the roles: hot operations go through the service, while withdrawal of large amounts requires a signature from the device.
| Mode | When it fits | Limitations |
|---|---|---|
| Custodial | Mass payments, recurring charges, an audience with no experience with crypto | Key storage on the service side: a hardware module and access separation are required, higher requirements for perimeter protection |
| Non-custodial | The user manages funds independently, independence from the service is needed | Access recovery rests entirely with the user; part of the audience drops off at the wallet creation stage |
| Hybrid | Large amounts and frequent small operations in a single product | More complex signing and state logic: two key contours, more consistency tests |
In practice, the mode is chosen by scenario, not by ideology. If the product is about accepting payments and withdrawing funds, a custodial contour with hardware key storage and permission separation provides predictable support.
If the value lies in self-custody of assets, a non-custodial mode with local transaction signing and clear access recovery meets the need.
The hybrid scheme is justified when fast small operations and rare large transfers coexist in a single application: transaction signing is split by thresholds, and key storage is divided between the service and the device.
We design mode switching at the architecture level so that transitioning between contours does not turn into rewriting the application.
How we conduct implementation: from audit to handover
Implementation in a payment circuit begins not with code, but with an inventory of what already works.
An application audit shows exactly where transaction statuses are lost, how repeated webhooks from the provider are handled, and what happens to the balance when the connection breaks in the middle of a confirmation.
Without this map of edits, any modification risks breaking reconciliation — and a discrepancy in accounting in crypto payments costs more than the failure itself.
Next, we build a payment flow scheme: the path from initiation to final confirmation on the network, idempotency points, behavior during reorgs and stuck operations.
Based on it, we configure queue processing, retries, and an event log so that every state is recoverable rather than "drawn in" manually.
- Application audit — analysis of the current logic, integrations, and bottlenecks based on actual logs, not documentation.
- Payment flow scheme — we fix transaction states, idempotency points, and rules for handling repeated events.
- Configuration and refinement — we implement the missing branches and bring error handling to a single regulation.
- Load testing — we run scenarios of peak inflows and disconnections, and observe degradation under queue pressure.
- Support regulation — we describe monitoring, alerts, and the procedure for actions during incidents.
- Handover to the team — we train your engineers and hand over access, schemes, and rollback instructions.
The key result of each step is reproducibility. After load testing, it becomes clear at what flow intensity the application begins to lose events, and this threshold is fixed in the support regulation along with the escalation procedure.
Handover to the team is not a formal act: your specialists go through recovery scenarios on the stand so that after we leave, an incident is closed according to the instructions, not from memory.
What the client receives upon completion
The implementation of a crypto payment gateway ends not with a demo of the payment screen, but with the handover of a set of artifacts that allow the application to be operated, evolved, and handed over to another team. Below is what exactly remains with the client.
- Application configurations — iOS and Android builds with environment separation (dev / staging / production), externalized keys and node addresses, separate profiles for the testnet and mainnet. Switching environments does not require a rebuild.
- Flow diagrams — payment lifecycle diagrams: invoice creation, tracking confirmations on the blockchain, crediting, refund, handling of a stuck transaction. With indication of points where a timeout and retry are possible.
- Access policies — a role matrix for the admin panel and API: who creates an invoice, who confirms a withdrawal, who sees the transaction history. Separately — rules for signing key rotation and secret storage.
- Documentation — an integration guide for merchants, an API method reference with request examples and error codes, and a local setup guide for new developers.
- Incident response procedures — the course of action for a balance discrepancy, network node unavailability, or suspected key compromise. With indication of who makes the decision and within what timeframe.
- Monitoring and alerts — configured metrics for the share of successful payments, confirmation time, withdrawal queues, with trigger thresholds.
- Rollback plan — build versioning and the procedure for reverting to a previous release without losing already initiated transactions.
The set is designed so that the client's team can make changes to configurations and respond to incidents independently, without waiting for the contractor. Describe your task — we will come back with an estimate and a plan for the composition of artifacts.
Case Study: How a Gateway Application Stopped Losing Transactions
The client came with a working gateway and a complaint that was hard to catch in tests: some operations would "hang" — the payment would go out to the network, but the status in the application wouldn't update.
The user would see "processing" where everything had actually been confirmed, would contact support, and sometimes would pay again.
During peak loads, the share of such operations reached 6-8% of the daily volume — with a flow of thousands of transactions, that meant daily manual investigation.
A crypto payment gateway is not "send and forget": confirmation arrives asynchronously, the network can reorganize a block, and the fee changes priority.
We traced the path of the status from submission to final confirmation and found three places where the application lost touch with reality.
What It Was and What We Changed
The application polled the status on a timer and relied on a single source. If no response came, the operation remained in an indeterminate state until manual intervention.
We switched status updates to an event-driven model with idempotent keys: redelivery of an event no longer creates a duplicate, and the operation state is restored from the journal rather than from the screen's memory.
We separately addressed behavior during network interruptions and when the application is minimized: missed updates are caught up upon return rather than lost.
For peaks, we added a queue with a limit on concurrent requests — the application stopped overwhelming the gateway and receiving rejections.
Metrics Before and After
| Metric | Before | After |
|---|---|---|
| Share of stuck operations | 6-8% | less than 0.3% |
| Status confirmation time | up to several hours | seconds after a network event |
| Support requests regarding status | a regular stream | isolated cases |
| Behavior during peaks | rejections and duplicates | smooth processing |
Resilience to peaks was confirmed by load runs with a multiple of the usual flow: the queue keeps pace rather than returning errors. Manual investigation of stuck operations as a daily procedure disappeared — the client's team returned to developing the product.
How custodial mode differs from non-custodial in practice
The difference shows up not in the interface, but in who is responsible for the keys and what happens when they are lost.
In custodial mode, private keys are stored and maintained by the payment service: the user goes through a standard registration, and transaction signing is initiated on the platform side.
In non-custodial mode, the keys remain with the client — the application merely forms and signs operations on their device, without gaining access to the key itself.
This is where responsibility diverges. The custodial model takes on storage, access recovery, and resolution of disputed transactions — but it is precisely this model that becomes a magnet for attacks, because the keys of all clients are concentrated on the server.
The non-custodial model removes the risk of a mass breach from the platform, but all responsibility for safeguarding the recovery phrase falls on the user: lose access — and there is technically no way to restore it.
UX is the price of the choice. The custodial scenario fits into the familiar logic of a banking app: biometric login, access reset through support, a clear transaction history.
The non-custodial one requires deliberate actions from the client — backing up the recovery phrase, confirming every signature — and part of the audience drops off at this point.
We usually propose a hybrid: non-custodial storage by default, with a custodial contour as an option for those who value simplicity more.
The risks are also different in class. Custodial mode is vulnerable to compromise of the server side and requires access regulations, key rotation, and separation of powers.
Non-custodial mode is vulnerable to social engineering and the user's own mistakes, so warnings, delays on large amounts, and recipient address verification are built into the application.
Choosing a mode is not a technical detail, but a decision about where you are prepared to hold the risk. Describe your scenario — we will come back with an assessment and a plan tailored to your operations profile.
Technical concerns before starting work
Before starting work, the customer's technical team usually checks three things: how the application will fit into the existing processing, whether it can withstand peak loads, and who is responsible for incidents after launch.
Below are answers to the questions that most often come up at this stage. If something is missing for your case, we will discuss it separately and come back with an estimate.
How does the application integrate with an already running gateway?
Through the server layer: the application does not store keys and does not sign transactions on the device — it exchanges data with the backend over a secure channel, while all signing and confirmation logic remains on the gateway side.
This removes the question of compatibility with the current processing: only the client layer changes, we do not touch the payment core. If you already have an API, we connect to it; if not, we design the contract and fix it in the documentation before development begins.
What about security and key storage?
Private keys and seed phrases do not end up in the application or on servers in plaintext. To confirm operations, we use a hardware module on the device, biometrics, and short-lived session tokens.
Every release undergoes a leak check and an access rights review — this is a standard stage, not a separate service.
Will the application withstand peak load?
We conduct load testing before release: we run scenarios with massive simultaneous operations and see where response degrades.
Bottlenecks are usually not in the application but in the confirmation queue on the gateway side — they are visible in tests and we close them in advance. After launch, we maintain monitoring of response and the share of successful operations.
Who supports the application after launch and how does updating work?
Support includes incident resolution, updates for new versions of mobile systems, and scheduled releases. We roll out critical fixes out of turn, and rollback to the previous build is possible at any moment — we keep a release history.
We fix access rights and the escalation procedure at the start, so that no one has to look for the person responsible at the moment of failure.
Let's discuss the task and come back with an estimate and a plan
To come back with an estimate and a work plan rather than generalities, we need to understand your scenario: where the application interacts with the blockchain, which assets and networks it serves, and who holds the keys.
The more specific the inputs, the more accurate the estimate of timelines and team composition — without rebuilding the architecture midway through the project.
What to send for an accurate estimate
- List of networks and assets: which blockchains, tokens, and whether we support fiat deposits and withdrawals.
- Fund flow diagram: where the keys are stored, who signs transactions, and whether there is a custodial provider.
- Confirmation requirements: how many confirmations we wait for before crediting, and how we handle chain reorganizations.
- Refund and stuck transaction scenarios: who handles them and how, and whether manual moderation is needed.
- Current materials: mockups, payment core API description, and access to test networks.
- Constraints: launch timelines, platforms (iOS, Android), compliance and customer verification requirements.
What the response will include
We will review the inputs, ask clarifying questions on contentious points, and come back with a work plan: stages, team composition, the order of integration with the payment core, and the points where your decisions are needed.
We will also separately discuss how release rollback and transaction monitoring are set up — so that a failure in one network does not block the others.
Describe the task in whatever form is convenient — we will come back with an estimate and a plan. The next step is ours: we will review the materials and suggest where to start.