Payology sends POST to the HTTPS receiver configured for your organization. Authentication/custom headers depend on that configuration; there is no universal signature header in the reviewed sender. Acknowledge durable receipt with any 2xx; the body is receiver-defined and may be empty. Delivery may be repeated: deduplicate by webhook_token and business identifiers. Network failures, 408, 429 and 5xx are retryable; other HTTP errors are terminal except for one configured OAuth token refresh on 401/403. Retry count, delay and HTTP timeout are configurable and were not checked in a live environment.
Receiver acknowledgement
After durably accepting the event, the receiver may return:
HTTP/1.1 204 No ContentAn empty HTTP 200 is also accepted. A response JSON body is optional and defined by the receiver.
Headers by file event
| Event | Payload | Additional headers |
|---|---|---|
| Check File Creation | Array of X9 file objects | event-type: Check File Creation |
| NACHA File Creation | Array of ACH file objects | event-type: NACHA File Creation |
| CC Settlements | One CC file object | event-type: CC Settlements; payment-method-type: CC; file-token; file-date |
Every delivery also contains webhook-notification: true and webhook_token. The examples below correspond to these event types.
Receiver accepted the event. Response body is optional and defined by the receiver.
Receiver accepted the event with no response body.
Receiver timeout; delivery is retryable.
Receiver rate limit; delivery is retryable.
Any successful 2xx response acknowledges delivery.
Other receiver errors generally end this delivery. Configured OAuth may refresh once after 401 or 403.
Receiver server error; delivery is retryable.