Implement handler
When you build a webhook endpoint to receive events from PaySway, your handler must be prepared for both successful and failed deliveries, as well as the structure of the JSON payload that arrives with each event. Below are key considerations and technical details to help you implement a robust endpoint.
Delivery and retry logic
PaySway delivers events one at a time, sending each as a separate HTTP request to your webhook endpoint. Here’s how delivery and retries work:
-
Single-Event Requests
Each HTTP request contains exactly one event in JSON format.
-
Successful Deliveries
If your handler processes an event successfully, it should return an HTTP 200 status code. This indicates that PaySway can safely mark the event as delivered.
-
Retries on Failure
- If your endpoint returns any status code other than 200, the delivery is considered failed.
- PaySway will retry delivering that event using an exponential backoff strategy.
- There is no limit on the number of retry attempts, so your handler should be idempotent and prepared for possible repeated messages.
-
Independent Deliveries
Failed deliveries for one event do not prevent PaySway from sending subsequent events. Each event is processed independently in its own request.
-
Final Confirmation
As soon as a 200 response is received, PaySway treats the event as delivered and will not attempt to send it again.
Request structure
PaySway packages each event in a single JSON payload, which includes metadata about when the event occurred and the type of activity, along with an object specific to that event type. The JSON payload has the following fields:
Field Name | Type | Description |
---|---|---|
id | string (uuid) | A unique identifier for the event |
createdAt | string (date-time) | The date and time the event was created, in ISO 8601 format |
eventType | string (enum) | The type of event |
object | JSON object | A structured event object containing event-specific data |
Example payload
Event types
Event category | Event types |
---|---|
RECIPIENT | RECIPIENT.CREATED ,RECIPIENT.UPDATED , RECIPIENT.DELETED |
Because the object field can vary based on the event type, you should consult the full reference for each event’s specific schema. You can find a detailed breakdown of object structures for all event types here.