A payment can be verified while the merchant application still shows pending because event delivery and application processing are separate systems. Delivery monitoring makes that boundary visible: event ID, attempt number, destination result, HTTP response code, latency, timestamp, and a safe response or error summary.
Use the API Credentials page as a workbench. Save an HTTPS endpoint, send a test event, inspect the real response, and compare retries that share the same event ID. A green test means the endpoint returned 2xx; it does not prove that your application updated the correct order, so application-side event logs remain essential.
Design principles
The boundaries that keep this flow reliable
Group by event ID
Multiple attempts for one event belong together. Attempt count alone cannot distinguish retries from separate payment events.
Separate transport from processing
A 2xx proves acceptance at the endpoint boundary. Track your own event ID through database commit and fulfilment for end-to-end visibility.
Protect observability data
Store useful codes and timings while redacting secrets, authorization headers, and unnecessary payment details.
Implementation workflow
From request to a durable result
- 1
Validate the destination
Use a public HTTPS URL, reject redirects to sign-in pages, and ensure the route accepts POST requests with JSON.
- 2
Send a real test
Use the Webhook Workbench and require an actual 2xx response before marking the endpoint passed.
- 3
Trace one event
Copy event_id into your application logs and compare delivery time, receive time, database commit, and fulfilment start.
- 4
Resolve by response class
Fix authentication for 401/403, routing for 404, application exceptions for 500, and capacity or timeout issues for slow/no response.
Useful structured log fields
json{
"component": "payment_webhook",
"event_id": "evt_reference_from_payload",
"order_id": "gateway_order_reference",
"attempt": 2,
"signature_valid": true,
"result": "accepted",
"duration_ms": 84
}Production checklist
Verify before going live
- Each delivery record includes event ID and attempt number
- HTTP code and latency are visible to authorized merchant users
- Merchant logs carry the same event ID
- Secrets and raw authorization headers are never logged
- Alerts distinguish repeated 4xx from transient 5xx/timeouts
Failure recovery
Reading delivery results
401 or 403
The route rejected authentication or signature validation. Verify raw-body handling, secret environment, timestamp tolerance, and proxy header forwarding.
404
The deployed URL or method does not match the route. Check base path, trailing rewrites, environment hostname, and POST handling.
500 or timeout
The merchant handler crashed or performed too much synchronous work. Persist the event quickly, acknowledge, and move fulfilment to a worker.
FAQ
Questions developers ask
Does a 200 response mean the order was fulfilled?
It means the endpoint accepted the request. Your own event-to-order audit trail must confirm database processing and fulfilment.
Why are there several attempts with one event ID?
They are retries of the same logical event. Your handler must use event_id to avoid duplicate effects.
Can I test localhost?
VyaparGateway needs a reachable callback. Use a controlled HTTPS development endpoint and never expose an unprotected local admin service.