Webhooks That Update Website Orders Automatically

Customers come to MONA asking how their website can know a customer has paid without someone watching the banking app all day. We once met a shop that lost a whole morning just checking who among yesterday's 50 orders had paid and who had not. Staff had to open the banking app, match each line against the order list, and only then dared tell the warehouse to pack. A webhook that updates website orders automatically solves exactly that problem: when money arrives at the bank, the website changes the order status within 2 seconds. Nobody has to click.

How a webhook works the moment money lands in the account

As soon as the bank records incoming money, the system signs the packet with HMAC-SHA256 plus an X-Mona-Signature header and sends it straight to the website address configured in advance. The website server reads the packet, matches the order code and amount, then switches the order to paid by itself in about 2 seconds. The whole flow runs in the background, and the customer sees the thank-you page appear almost instantly after clicking transfer. No human involvement is needed. E-commerce customers at MONA often ask why every packet needs a digital signature. We explain it simply: to stop impostors from firing fake webhooks that mark unpaid orders as paid. Without a signature, anyone could send a fake packet and pretend to have paid. The system also rejects any request more than 5 minutes off from the signing time to prevent replays, a protection layer we added after seeing a few cases of abnormal repeated sends.

The risk when a website relies only on SMS or manual calls

SMS balance-change messages are not a reliable basis for automation. Telecom networks sometimes jam and a message arrives more than 2 hours late, while the shop owner is busy advising other customers and cannot check the phone in time. One beat too slow and the order is lost. We once heard a shop owner say a customer cancelled right away after waiting over 3 hours for payment confirmation while the website still showed unpaid even though the money had arrived long before. This is why a webhook fully replaces checking messages: the data comes straight from the bank's server, not through an intermediary channel that can lag. There is no more dependence on phone signal or on whether the phone battery is enough to receive a message.

What we ran into when a bank sent data outside the standard

Banks do not always send data exactly as their technical documents describe. Once, a bank sent a transaction notice with the header in the wrong position, and our standard system immediately returned a 422 error and rejected that transaction within 2 seconds. A bank cannot fix this on request within 1 week or even 1 month. If they cannot fix it, we patch it ourselves. By the time the bank fixed it, the customer's order would have gone cold long ago and the sale would have drifted away too. We had to write our own middle layer to read the data and straighten out the structure, then replay the dropped transactions within the same day so customers' orders were credited correctly. Incidents like this come with no warning, so the monitoring system must detect them on its own through an abnormal error rate.

The missing-key incident in September 2026 and the lessons we took from it

In September 2026 we had a memorable incident when reconfiguring the server dropped a webhook secret key. The webhook still fired as soon as a new transaction came in, but it carried an empty signature, so the receiving system returned a 401 error even though the customer had paid. Customers complained immediately. Orders were not credited even though the money was already in the account. We had to reopen the webhook history on the dashboard, add the key back and resend in bulk within 1 day, so no customer had to wait until the next day. The lesson we often give customers using an automatic credit-notification service is to never trust “it worked once, so it will work forever”, and always turn on an alert when the webhook success rate drops abnormally so you catch problems early. Catching it the same day is very different from letting customers find it first and complain on the fanpage.

Under 20-30 orders a day, you do not need to write a webhook yet

If your website sells fewer than 20-30 orders a day, we honestly advise that you do not need to hire a developer to write a custom webhook, which only adds complexity. A payment page set up with a Telegram or Zalo credit-notification bot is enough, and setup takes about 10 minutes. Try it first. The money you do not spend on a developer, put into advertising, works far better. This is what we tell new customers asking to buy a solution. We see many shops rush to connect an API when they only have a few dozen orders, spending on developers when a single payment link would do. When order volume rises to a few hundred a day, or you need scenarios like auto-dispatching goods once money arrives, that is when connecting a webhook is truly worth it.

View webhook history and resend when a transaction is dropped

The full webhook history, success rate and every dropped attempt are displayed right in the my.monapay.vn admin page. If a send fails, the system automatically resends within 2 seconds on schedule rather than leaving the transaction behind. No transaction is missed. MONA customers who build sales management software often rely on this feature for end-of-day reconciliation, instead of asking the bank about each transaction one by one, saving accountants a few hours every week. A shop selling 2,000 orders a month can still check everything in a few minutes instead of a whole morning as before. The fully stored data also helps resolve complaints faster when a customer asks about an old transaction.

Webhook integration for WooCommerce or a custom-built system

A website running WooCommerce, with a plugin that confirms transfer orders automatically, installed directly has a sandbox test mode, and setup takes just 10 minutes with no coding. For a custom-built system, we provide complete webhook API documentation so developers can fit it into the existing ordering flow, usually done in 1 working day. The docs include sample code in several popular programming languages to save you time looking up syntax. Sign up for a trial right now at my.monapay.vn, no approval needed, and you can even try the sandbox before linking a real bank account. In a few minutes you see how the admin interface runs before deciding to use it for real. No more guessing. If you have any technical questions, call 1900 636 648 and we will connect you the same day.

FAQ

Is a webhook safer than checking phone text messages? Yes. A webhook sends data over an encrypted HTTPS channel directly between two servers, with an HMAC-SHA256 signature to verify the sender, which removes the risk of leaked messages or dependence on unreliable mobile signal.

What if my website is down just as a customer is paying? The webhook system is designed to resend automatically many times over the following hours. As soon as the website is back, all unprocessed transaction data is delivered in full, with no transaction lost. You can also click resend yourself on the dashboard if you do not want to wait for the system.

Does setting up a webhook take a lot of developer time? With WooCommerce you only need to install a plugin, about 10 minutes. Not long at all. For a custom-built system, the developer reads the API docs and tries it in the sandbox, usually done in one working session.

Why does the webhook reject requests that are more than 5 minutes off? This is a replay protection layer. It stops bad actors from capturing an old packet and sending it again and again to falsely mark an already processed order as paid, so each transaction is credited exactly once. The 5-minute threshold is wide enough for normal network delay while still blocking this kind of repeat attack. We settled on this number after tracking the real latency of many banks over a long period.