Real-Time Crypto Alerts: Price Apps vs. Webhook Alerts

Real-time crypto alerts fall into two different categories, and picking the wrong one wastes weeks. If you want to know when Bitcoin crosses a price, a consumer alert app is enough. If your product has to react the moment a customer’s deposit lands, you need on-chain event alerts delivered to your server by webhook, and that is a developer problem, not a notification-settings problem.

This guide covers both, then goes deep on the second: how event-driven alerts work, what to verify before you trust them, and how to wire them into a payment flow without double-crediting anyone.

TL;DR

• Price alerts are for people watching markets. They are informational and tell a human to look at a screen.
• Transaction alerts are for software. A webhook pushes an event to your backend so it can credit an account, unlock an order or flag a transfer, with no human in the loop.
• A signed webhook proves who sent it, not that it is new. You also need timestamps, event IDs and idempotent processing.
• Treat every alert as a hint and confirm the current state with an API read before you move money or ship goods.
• Chaingateway delivers HMAC-signed webhooks and decoded transaction data across Ethereum, Bitcoin, Tron, Solana, Polygon, BNB Chain and Arbitrum through one REST API.

Table of Contents

• Two meanings of “real-time crypto alerts”
• Price alerts vs. transaction alerts at a glance
• How event-driven alerts work
• A practical example: confirming a deposit
• What a signed webhook does and does not prove
• Assume events arrive late, twice or out of order
• Perspective: alerts are an input, not a verdict
• Where consumer alerts fall short for products
• Choosing an alerting setup: criteria that matter
• Getting started with webhook alerts on Chaingateway
• Compliance and risk alerts are a separate layer
• Common mistakes to avoid
• FAQ
• Sources

Two meanings of “real-time crypto alerts”

The phrase gets typed by two very different readers.

The first is a trader or holder. They want a push, email or text when an asset hits a level. Most exchange apps offer this for free, and as of mid-2026 these alerts are mostly tied to a watchlist and a preset price trigger, delivered by push, in-app message or email. They inform a person. They do not trigger anything automated.

The second reader is a developer or product owner. Their question is different: “How does my app find out, within seconds, that 150 USDT just arrived at the address I generated for this customer?” No price app answers that. The answer is a blockchain event feed that posts to an endpoint you control.

If you are in the first group, set a threshold in the app you already use and stop reading. If you are in the second, the rest of this article is for you.

Price alerts vs. transaction alerts at a glance

	Consumer price alerts	Webhook transaction alerts
Audience	Traders, holders	Developers, product teams
Trigger	Price crosses a level	Transfer, deposit, token or NFT event on a watched address
Delivered to	A phone or inbox	Your HTTPS endpoint
Action taken	A human decides	Your code decides
Failure mode	You miss a move	You credit twice, or never
Security concern	Little	Authenticity, replay, ordering

The last two rows are why the second category deserves real engineering attention. A missed price alert costs an opportunity. A mishandled payment alert costs money.

How event-driven alerts work

The mechanics are simple to describe and fiddly to run yourself.

1. You register an address or a set of addresses. Typically you generate one deposit address per customer or per order.
2. The provider watches the chain. Something has to read new blocks, find transfers that touch your addresses and interpret them.
3. The provider decodes the event. A raw transaction is bytes. A token transfer on an EVM chain is a contract log that has to be parsed into sender, recipient, token and amount. Decoded data saves you from maintaining ABIs and parsers per chain.
4. The provider POSTs to your endpoint. Your server receives JSON describing the event.
5. Your code verifies, deduplicates and acts.

Steps 2 and 3 are where building in-house gets expensive. You either run nodes for every chain you support, or you subscribe to node-level feeds and write the decoding yourself. On Ethereum, a proposed standard extension to eth_subscribe would let clients receive real-time notifications when a transaction is included in a block, which shows how much of this plumbing is still being worked out at the protocol level, and that is for one chain only. Bitcoin’s UTXO model, Tron’s resource system and Solana’s account model each behave differently.

If you want a map of the options, our comparison of six types of blockchain APIs and when to use each lays out where node access, indexed data and event notifications each fit.

A practical example: confirming a deposit

Take a checkout that accepts a stablecoin. The customer sees an address and an amount. Here is the sequence a sound integration follows.

1. Your backend creates a wallet address for the order and stores the expected amount, token and chain against the order ID.
2. The customer sends funds.
3. Your webhook endpoint receives an event for that address.
4. Your handler checks the signature, then the timestamp, then whether you have already processed this event ID.
5. It looks up the order, compares the token, chain and amount with what you expected, and reads the canonical transaction state from the provider’s API.
6. In a single database transaction, it marks the order paid and records the event ID.
7. It returns a 2xx response quickly and does slow work, such as sending emails, in a queue.

Nothing in that list is exotic. Each step exists because of a specific way things go wrong, which the next sections cover. For a deeper walkthrough of the deposit case, see our post on using webhooks to process deposits automatically.

What a signed webhook does and does not prove

Many teams stop at “the request is HMAC-signed, so we are safe.” A signature is necessary. It is not sufficient.

An HMAC signature lets you confirm the payload came from someone holding the shared secret and was not altered in transit. It does not tell you the message is fresh. An attacker, or simply a retrying network, can send the same valid message twice. The OWASP Webhook Security Cheat Sheet makes this point directly: verifying the signature does not stop replay, so you should pair it with an authenticated timestamp and an event ID, and process events idempotently so retries cause no side effects such as duplicate payments.

In practice that means:

• Verify the signature on the raw request body, before parsing. Use a constant-time comparison.
• Reject stale timestamps. Pick a tolerance window and drop anything older.
• Store event IDs. If you have seen the ID, return success and do nothing.
• Make the handler idempotent. Crediting an account should be an operation that is safe to run twice.

Chaingateway signs its requests with HMAC, and we have written about a feature that strengthens webhook security. Whichever provider you use, the checks above stay on your side of the wire.

Assume events arrive late, twice or out of order

Webhook delivery is at-least-once in practice. A timeout on your side can cause the publisher to retry, so one transfer may produce two deliveries. Two events about the same payment may also arrive in the wrong order.

OWASP’s guidance is to assume out-of-order delivery and not to base state transitions on arrival order. When a notification arrives, fetch the object’s current state from the provider’s API instead of trusting the payload alone. The same cheat sheet recommends treating incoming webhooks as untrusted data, validating them against your own records, and wrapping fulfilment in atomic database transactions, for example with row locking, to prevent race conditions.

The OWASP guidance on third-party payment gateway integration lands in the same place: verify payment status server-side with the gateway’s API before fulfilling an order, and match the expected amount, currency and order ID. For crypto, add the chain and token contract to that list. A transfer of the wrong token that happens to carry the same ticker is a classic way to get an order marked paid when it should not be.

Perspective: alerts are an input, not a verdict

We build for developers who put crypto payments inside products, and the pattern we see is consistent: teams treat the alert as the answer. We think of it as the question. The webhook says “something happened at this address.” Your system still has to decide whether that something matches an order, whether the amount and token are right, and whether it has already been counted.

That is why we focus on the parts that remove busywork without removing your control. Pre-decoded data means your handler reads a sender, recipient, token and amount instead of parsing logs. Automatic gas estimation means the outbound side of the flow, such as paying out or sweeping funds, does not need its own fee logic. One API across seven networks means your handler for an Ethereum deposit looks like your handler for a Tron deposit. And HMAC-signed requests give you a solid base to layer timestamp and idempotency checks on.

What we would not do is promise that a webhook alone makes a payment system safe. It does not, and any provider that implies otherwise is skipping the hard part. Build the verification loop first, then scale volume.

— Bitblade

Where consumer alerts fall short for products

It is tempting to prototype with whatever alert tool is at hand: a price bot, a wallet-tracking service that pings a chat channel, a mobile app. For a demo this works. For a product it breaks down in predictable ways.

• No programmatic contract. A chat message is not an API. You cannot reliably parse it, retry it or authenticate it.
• Watchlist logic, not account logic. Consumer tools track assets or public addresses you add by hand, not the thousands of per-customer addresses a live product generates.
• No signature. Nothing lets your server prove a message is genuine.
• No decoded, structured payload designed for your database schema.

If you run a business that moves customer funds and also need merchant-side card or ACH acceptance next to crypto, it helps to understand the wider crypto payment processing options on the fiat side, because reconciliation between the two rails is often where finance teams feel the pain. On the crypto side, the event feed is the part you want to be machine-readable end to end.

Choosing an alerting setup: criteria that matter

When you compare ways to get real-time on-chain events into your app, judge them on these points rather than on headline latency claims.

Chain coverage

List the networks and token standards you need today and the ones you may add next year. If you will accept stablecoins on several networks, you need ERC-20, BEP-20 and TRC-20 handled in the same shape. Chaingateway covers Ethereum, Bitcoin, Tron, Solana, Polygon, BNB Chain and Arbitrum, and supports the major token standards including ERC-20, BEP-20, TRC-20 and ERC-721.

Payload quality

Ask to see a sample event. Is the token identified, the amount already normalized for decimals, the direction clear? The more you must decode yourself, the more code you own and test.

Security model

Check for signed requests, a documented verification method, and a timestamp or ID you can use against replay. Then budget time for your own idempotency layer.

Operational burden

Running your own nodes means patching, syncing, monitoring and paying for storage on every chain. A hosted API trades that for a subscription. Be honest about which cost you would rather carry.

Pricing that tracks usage

Plans that scale with API volume are easier to forecast than infrastructure you must overprovision. Our published plans are below.

Plan	Monthly	Yearly
Plus	€49 per month	€490 per year
Pro	€99 per month	€990 per year
Premium	€249 per month	€2490 per year
Enterprise	€499 per month	€4990 per year

The current details for each tier are on the Chaingateway pricing page.

Getting started with webhook alerts on Chaingateway

If your use case is payment detection, wallet monitoring or token-transfer notifications, Chaingateway Webhooks lets you subscribe to blockchain events and receive them as signed HTTP callbacks. The underlying Blockchain API is one REST interface for creating wallets, sending token and NFT transfers, fetching decoded transactions and estimating gas, so the same integration that listens can also act. Our service runs on a subscription after a free trial, so you can test the flow with your own endpoint before committing to a plan.

A sensible first-week plan:

1. Create a test wallet and subscribe your staging endpoint.
2. Log raw deliveries, with headers, before writing business logic.
3. Implement signature, timestamp and event-ID checks.
4. Add the API read-back step and the atomic order update.
5. Replay the same event on purpose and confirm nothing is credited twice.
6. Send events out of order on purpose and confirm the final state is still correct.

If you are building for an online store specifically, our overview of blockchain APIs for e-commerce covers how these pieces fit around a checkout.

Compliance and risk alerts are a separate layer

Some teams searching for real-time alerts mean something else again: screening transactions for sanctions exposure or suspicious patterns. That is a compliance function, usually bought from specialist analytics vendors and wired into your workflow by API. It sits beside, not instead of, payment event notifications. Your payment webhooks tell you a transfer arrived. A compliance layer tells you whether you should accept it. If your business is regulated, plan for both, and speak with your compliance counsel or a qualified AML officer about what your jurisdiction requires. Rules differ by country and by license type.

If your concern is abuse of your own product, such as repeated signups or payment-instrument reuse, the OWASP Business Logic Security Cheat Sheet has a useful list of patterns worth alerting on inside your application, separate from anything on-chain.

Common mistakes to avoid

• Doing slow work inside the handler. Acknowledge fast, process in a queue, or the sender may retry while you are still working.
• Trusting the amount in the payload without comparing it to the order you created.
• Ignoring underpayments and overpayments. Decide the policy before launch: credit partial, refund, or hold for review.
• Reusing one address for many orders. It makes matching ambiguous. Generate per-order or per-customer addresses.
• No dead-letter path. If your endpoint is down, you need a way to reconcile by reading recent transactions through the API.
• Logging secrets. Keep your HMAC secret out of logs and repositories, and rotate it on a schedule.

Sources

• Webhook Security Cheat Sheet, OWASP
• Third Party Payment Gateway Integration Cheat Sheet, OWASP
• Business Logic Security Cheat Sheet, OWASP
• EIP-8072: Transaction Inclusion Subscription
• Best Crypto Price Alert Apps (2026), Traders Union

Recommended

• Blockchain Webhooks & Event Notifications
• The Use of Webhooks to Process Deposits Automatically
• Webhooks vs WebSockets for Developers: Ingest, Queue, Fan Out Pattern