After a customer pays, your system needs to know. There are two ways to find out: ask repeatedly (polling) or be told (webhooks). For payments, webhooks win — if you handle them properly.
Why polling falls short
Polling wastes requests when nothing changes and adds latency when something does. Poll every minute and your customer waits up to a minute for order confirmation; every second, and you burn rate limits. Payment state changes are events — they deserve event delivery.
How payment webhooks work
When a payment changes state — authorized, captured, failed, refunded, disputed — the platform sends a signed HTTP POST to your endpoint with the event payload. Your job is to receive it, verify it, and act on it exactly once.
The five rules of reliable webhook handling
- Verify the signature. Anyone can POST to your endpoint. Only the platform can sign with your webhook secret. Reject anything that fails verification.
- Respond 200 fast, process async. Acknowledge within seconds and queue the work. Slow handlers cause timeouts, retries and duplicates.
- Make handlers idempotent. Deliveries can arrive twice. Key your processing on the event ID so a duplicate is a no-op, not a double shipment.
- Expect disorder. Events can arrive out of order. Treat the webhook as a hint and confirm current state via the API when order matters.
- Reconcile daily. Webhooks are the trigger; settlement reports are the truth. A daily job comparing your ledger against platform records catches anything missed.
Don’t trust the redirect
The customer’s browser returning to your success page proves nothing — people close tabs, connections drop. The webhook (confirmed by API lookup) is the authoritative signal to release goods.
Payixay sends signed webhooks for every payment, refund, payout and dispute event, with automatic retries for 24 hours. See the developer overview.