Key Events
Tonder sends webhook notifications for various transaction events:Event Type | Description | Example Status Flow |
---|---|---|
Payment Status Changes | Real-time updates as payments progress through different states | pending → authorized → success |
Payment Failures | Notifications when payments are declined or fail | pending → declined or failed |
3DS Authentication | Updates when users complete 3D Secure challenges | pending_3ds → success or failed |
Cash Payment Confirmations | Notifications when customers pay OXXO vouchers | pending → success (when paid at store) |
Withdrawal Updates | Status changes for payout transactions | processing → success or failed |
Webhook Payload Structure
All webhook notifications follow a consistent payload structure with these key fields:Field | Type | Description |
---|---|---|
event_type | string | The type of event that occurred (e.g., transaction.status_changed ) |
event_id | string | A unique identifier for this specific webhook event |
created_at | string | An ISO 8601 timestamp of when the event occurred |
data | object | The full transaction object related to the event |
data.status | string | The new, current status of the transaction |
data.previous_status | string | The status of the transaction before this change |
Getting Started with Webhooks
To start receiving webhook notifications, you need to:- Create a publicly accessible HTTPS URL that can receive POST requests.
- Secure your endpoint to verify requests come from Tonder.
- Register your endpoint using our API.
- Process incoming webhook notifications in your application.
Prerequisites for webhook endpoints:
- Must use HTTPS (not HTTP) for security.
- Should respond within 30 seconds to avoid timeouts.
- Must return a 2xx status code to acknowledge receipt.
- Should implement authentication to verify request source.
Reliability and Delivery
Tonder ensures reliable webhook delivery through built-in resilience mechanisms:Feature | Details | Benefit |
---|---|---|
Automatic Retries | Up to 3 delivery attempts with 60-second intervals between retries | Handles temporary outages and network issues |
Response Timeout | 30-second timeout per delivery attempt | Prevents hanging requests and ensures timely retries |
Dead Letter Queue | Failed events stored for 30 days with manual reprocessing | No events lost, manual recovery for persistent issues |
Success Criteria | Any 2xx HTTP status code within timeout window | Simple and flexible acknowledgment requirements |
Common Use Cases
Here are practical examples showing how to implement webhook handlers for the most common scenarios you’ll encounter in production applications:Real-time Payment Status Updates
Real-time Payment Status Updates
Handle payment status changes to automatically fulfill orders and notify customers when payments complete or fail.
3DS Authentication Handling
3DS Authentication Handling
Process 3D Secure authentication completions to finalize payments that required additional customer verification.