Real-time Transaction Status Tracking for Crypto Wallets

Transaction sent — and the user stares at a Pending status for the next 10 minutes. That's fine for blockchain, but not getting a notification when the transaction is confirmed or fails is not. Tracking transaction status is a real-time task with multiple layers: blockchain polling, WebSocket connection, push notification on final status. Without timely updates, users lose trust, and in high-traffic crypto wallets (e.g., 8000 transactions per day) even a 5-second delay creates a negative experience.

Our engineers with 5+ years of experience in blockchain projects have implemented tracking for 15+ crypto wallets. Apple and Google certified, we have worked with Ethereum, Bitcoin, Solana, and other networks, integrated WebSocket via Alchemy WebSocket API and Infura, and configured push notifications through APNs and FCM. We guarantee stable operation and timely status updates.

What does the transaction lifecycle look like?

An Ethereum transaction goes through states: submitted → pending (mempool) → confirmed (1 confirmation) → finalized (12+ confirmations) → failed (reverted / dropped). Bitcoin: mempool → 1 confirmation → 6 confirmations (finalized). Solana is much faster: slots ~400ms, processed → confirmed → finalized in seconds. On the client, you need to show the current state and number of confirmations.

What strategies exist for obtaining status?

Polling every 3–5 seconds with the screen open is fine. In the background — only via silent push or WebSocket API. Infrastructure savings of up to 40% when using WebSocket instead of frequent polling. Typical cost for basic integration starts from $1,500.

Polling via node RPC

// iOS — polling ETH transaction status via JSON-RPC
func pollTransactionStatus(txHash: String) async throws -> TransactionStatus {
    let params: [AnyEncodable] = [txHash, false]
    let receipt = try await ethClient.call(method: "eth_getTransactionReceipt", params: params)

    if receipt == nil {
        return .pending // Still in mempool
    }

    let confirmations = try await getConfirmationsCount(txHash: txHash)
    return confirmations >= requiredConfirmations ? .confirmed : .confirmingWith(count: confirmations)
}

Why is WebSocket faster than polling?

WebSocket provides instant data transmission when a new block appears, while polling has a delay of up to 5 seconds. For critical transactions, WebSocket is the preferred choice. We help you choose the optimal option for your budget and requirements.

WebSocket subscription via Alchemy / Infura / QuickNode

// Backend — subscribing to an event via Alchemy WebSocket
const { createAlchemyWeb3 } = require("@alch/alchemy-web3");
const web3 = createAlchemyWeb3(process.env.ALCHEMY_WS_URL);

async function watchTransaction(txHash, userId) {
    const subscription = web3.eth.subscribe('newBlockHeaders');

    subscription.on('data', async (blockHeader) => {
        const receipt = await web3.eth.getTransactionReceipt(txHash);
        if (receipt) {
            subscription.unsubscribe();
            await updateTransactionStatus(txHash, receipt.status ? 'confirmed' : 'failed');
            await sendPushNotification(userId, txHash, receipt.status);
        }
    });
}

How to set up transaction status tracking via WebSocket?

1. Set up a WebSocket endpoint on the server, authorized by user token.
2. On the client, establish a connection when navigating to the transaction list screen.
3. Subscribe to events by tx_hash — the server sends status updates.
4. Close the connection when the final status is received.
5. Reconnect when the screen is reopened or after an error.

// Android — subscribing to transaction status via WebSocket
class TransactionStatusSocket(
    private val token: String,
    private val okHttpClient: OkHttpClient
) {
    fun subscribe(txHash: String): Flow<TransactionStatus> = callbackFlow {
        val ws = okHttpClient.newWebSocket(
            Request.Builder()
                .url("wss://api.yourwallet.app/ws/tx/$txHash")
                .header("Authorization", "Bearer $token")
                .build(),
            object : WebSocketListener() {
                override fun onMessage(webSocket: WebSocket, text: String) {
                    val status = json.decodeFromString<TransactionStatusUpdate>(text)
                    trySend(status.status)
                    if (status.isFinal) close()
                }
                override fun onFailure(webSocket: WebSocket, t: Throwable, response: Response?) {
                    close(t)
                }
            }
        )
        awaitClose { ws.close(1000, "Subscription ended") }
    }
}

Progress indicator for confirmations

For ETH, we show progress towards 12 confirmations. Use a ProgressView with a gradient from orange to green as the count increases. Transaction design in different statuses:

• pending — animated spinner, yellow accent
• confirming — progress bar with confirmation count
• confirmed — green checkmark, animation
• failed — red, error reason if available (revert reason from receipt)

Push notifications on status change

On final status, we send a push to the user:

{
  "title": "Transaction confirmed",
  "body": "0.05 ETH sent to 0x742d...3B8C",
  "data": {
    "screen": "transaction_detail",
    "tx_hash": "0xabc123...",
    "status": "confirmed"
  }
}

For failed transactions, a separate template with a reason description (revert reason or dropped from mempool).

How is dropped transaction handling set up?

A transaction may disappear from the mempool if the gas price was too low. After 15–30 minutes without confirmation, the transaction is considered dropped. We need to detect this:

suspend fun checkDroppedTransactions() {
    val pendingTxs = transactionDao.getPendingOlderThan(minutes = 20)
    pendingTxs.forEach { tx ->
        val receipt = ethClient.getTransactionReceipt(tx.hash)
        if (receipt == null) {
            transactionDao.updateStatus(tx.hash, TransactionStatus.DROPPED)
            pushService.notifyUser(tx.userId, "Transaction did not make it into a block", tx.hash)
        }
    }
}

What's included in the work

Analysis of the current wallet architecture and strategy selection (polling/WebSocket/webhook). Integration with blockchain nodes (Infura, Alchemy, QuickNode) or your own node. Implementation of client-side logic: polling/WebSocket client for iOS and Android. Development of a progress bar to display confirmation count. Configuration of push notifications (APNs, FCM) on final status. Handling of dropped transactions and errors (revert reason, timeout). Testing on testnets (Goerli, Sepolia) and mainnet. Documentation and source code delivery. We also provide access to development environments, training for your team, and post-launch support.

Timelines and cost

Basic implementation of tracking with polling and push notifications takes 6–10 business days. Full cycle with WebSocket, progress bar, dropped transaction handling, and custom push takes from 2 weeks. Cost is calculated individually after project analysis. Typical cost for basic integration starts from $1,500. Contact us for a consultation and accurate estimate.

We guarantee quality and provide post-launch support. Our developers' experience is confirmed by Apple and Google certifications. Get a free consultation on tracking architecture for your crypto wallet.

Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push

We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.

How the Infrastructure Works: APNs and FCM

APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.

A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.

FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.

Why Segmentation Is the Foundation of Effective Push Notifications?

Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.

Proper segmentation is built on several levels.

Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.

Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.

Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.

What Is Rich Push and How Does It Boost Conversion?

A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.

On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.

On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.

How to Track Delivery and Conversion of Push Notifications?

Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.

FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.

OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.

How We Implement Push Notifications: Typical Process

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. Documentation and training — hand over operational materials to the team.

Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.

Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.