Separate transport data from business meaning
Your server receives bytes before it receives an application object. A framework may then parse the JSON into a convenient structure. That parsed object is useful for reading an event identifier or a payment field, but it is not automatically the material that was signed. Whitespace, escaping and property order can change when JSON is decoded and encoded again.
WATADCASH documents signing the timestamp, a dot and the original body bytes. Preserve that raw body for verification before using the parsed event to make a business decision. This keeps the security check tied to the actual message delivered to your endpoint, rather than a new representation created inside your application.
Read the signature contract precisely
The public guide shows a WATADCASH-Signature header containing timestamp and signature components. It documents HMAC SHA256 and explains how the signing secret is used. Follow that contract exactly; do not replace it with an assumption based on another provider’s webhook format.
In particular, the guide says to use the secret as the returned 64-character text rather than applying a hexadecimal-to-binary conversion. That detail is easy to overlook when a secret visually resembles a hexadecimal value. It illustrates why a signature integration should be checked against the provider’s actual documentation instead of a generic example copied from a different service.
Make time validation explicit
A timestamp helps the receiver judge whether a message fits the documented acceptance window. WATADCASH’s published example accepts a difference of up to five minutes. Treat that as part of the documented example you must review when implementing the endpoint, rather than silently omitting time handling because the signature itself matches.
Time checks and event deduplication address different problems. A message can be authentic and still arrive more than once. A timestamp check does not tell you whether your application already delivered the associated order. Keep the security decision separate from the record of business effects that have already been completed.
Verify first, then apply the event once
After validating the signature, connect the event to the payment and order records it concerns. The documentation lists event information including an identifier, type, creation time and data. Use the documented identifiers in your processing design and retain enough state to recognise a repeated notification.
A second delivery should not automatically create a second shipment, second credit or second activation. Plan a durable transition from the previous order state to the new state. If processing fails halfway through, your retry path should be able to determine what was completed. This is a business-state problem as well as an HTTP endpoint problem.
Make failures diagnosable without exposing secrets
When verification fails, record a small, useful diagnostic instead of logging everything. An event reference, failure category and internal request reference can be more useful than an unrestricted dump containing sensitive headers or data. Keep signing secrets and API credentials out of browser code and ordinary support screenshots.
During integration review, test malformed headers, changed body bytes and repeated delivery alongside the successful example. The point is not to build a complicated receiver for its own sake. It is to know that an order changes state because a verified, relevant event was processed correctly. WATADCASH’s public webhook and authentication guides provide the service-specific details to start that review.
Frequently asked questions
Can I verify a JSON object after re-encoding it?
Do not assume so. The documented signature uses the original request bytes. Parsing and re-encoding can change those bytes even when the JSON means the same thing. Preserve the original body for the signature check and parse it separately for business processing.
Does a valid signature make a duplicate safe automatically?
No. A repeated event can have a valid signature. Your application must still recognise an event or business transition it has already processed and avoid repeating delivery, crediting or other effects.
Should the webhook signing secret be sent to the browser?
No. Verification belongs on your server. WATADCASH’s documentation also says integration keys stay on the server. Keep secrets out of client-side code, support messages and public examples, and use placeholders in any shared technical material.
Sources and verification
- WATADCASH webhook signing and event guidanceReviewed 2026-10-18
- WATADCASH authentication and permissionsReviewed 2026-10-18
