Overview
Webhooks deliver asynchronous notifications about the final result of a payment, so your internal transaction state stays accurate even if the authorization request times out or returns an ambiguous response. When an intent reaches a terminal state, Push sends a signed event —intent.approved or intent.declined — to an HTTPS endpoint you control.
Events are delivered at-least-once and may arrive in any order relative to the authorization response, so your endpoint must verify each event, process it idempotently, and tolerate out-of-order delivery.
Integration overview
The steps below show an overview of how to receive and process webhooks.-
Configure webhook delivery. When calling authorize-payment, provide:
webhook_url— where Push delivers webhook events.webhook_secret— used to sign each event so you can verify its authenticity (32 characters minimum).tag— maps each event back to your internal transaction record.
-
Expose an HTTPS endpoint. Create an endpoint at your
webhook_urlthat accepts POST requests and is reachable over HTTPS from the Push IP addresses. -
Verify each event. Verify the request signature and timestamp before processing, and reject invalid requests with
401 Unauthorized. See Security. -
Update your record and acknowledge. Parse the payload (see Webhook types), update the matching transaction record (keyed on the
tagor intentid), and return200 OK. Your integration must tolerate out-of-order and duplicate deliveries — see Independent ordering and Idempotency.
Webhook types
Push sends the following events. Each event has atype, a data object with the fields below, and a timestamp (ISO 8601).
intent.approved
Triggered when an intent is successfully approved.
| Field | Type | Description |
|---|---|---|
id | string | Unique identifier for the intent |
tag | string | Your internal transaction identifier (if provided) |
direction | string | Either cash_in or cash_out |
amount | integer | Amount in cents (e.g. 5000 = $50.00) |
status | string | Intent status (approved or pending) |
rail | string | Payment rail used (ach or card) |
currency | string | Currency code (USD) |
type | string | Payment type (secure_debit, card_only_credit, or card_only_debit) |
limits_utilization | object | Object containing limit utilization details |
limits_utilization.daily_cash_in | string | Daily cash-in limit usage |
limits_utilization.daily_cash_out | string | Daily cash-out limit usage |
limits_utilization.monthly_cash_in | string | Monthly cash-in limit usage |
limits_utilization.monthly_cash_out | string | Monthly cash-out limit usage |
intent.declined
Triggered when an intent is declined.
| Field | Type | Description |
|---|---|---|
id | string | Unique identifier for the intent |
tag | string | Your internal transaction identifier (if provided) |
direction | string | Either cash_in or cash_out |
amount | integer | Amount in cents (e.g. 5000 = $50.00) |
status | string | Intent status (declined) |
decline_category | string | Reason for decline – see the full list of decline categories |
currency | string | Currency code (USD) |
type | string | Payment type (secure_debit, card_only_credit, or card_only_debit) |
Independent ordering
Webhook delivery and authorization responses are independent and may arrive in any order. Your system must handle both scenarios by ensuring that the internal transaction record is committed to the database before the call to the authorization endpoint:- Webhook arrives first (before authorization response)
- Authorization response arrives first (before webhook)
Sequence diagram illustration
Sequence diagram illustration
Sequence diagram illustrates the two possible scenarios of ordering between webhook delivery and authorization results.

Idempotency
Push provides at-least-once delivery for webhooks. Your application must handle duplicate webhook deliveries gracefully using database transactions to ensure idempotency. In the case of a duplicated webhook delivery from Push either due to an error or timeout from your callback handler, you should discard the request and return a200 OK.
If Push does not receive a 200 OK response from your webhook endpoint, delivery will be retried with exponential backoff.
| Environment | Retry Behavior |
|---|---|
| Sandbox | Up to 3 attempts |
| Production | Up to 40 attempts over 3 days, then marked as expired |
Security
Webhooks deliver data directly to an endpoint you control over the public internet. Because they are invoked automatically by Push, webhook endpoints must be explicitly secured to prevent unauthorized requests, data tampering, and replay attacks. Without proper verification, a malicious actor could spoof webhook requests and falsely mark payments as approved or declined in your system.If your cloud data environment restricts network access from external IPs via a firewall, you may need to allow inbound
traffic from Push IP addresses in order to receive webhook requests.
Push webhook source IP addresses
Push webhook source IP addresses
Production
44.238.180.175Sandbox 34.209.246.44Signature verification
When awebhook_secret is provided, Push signs each webhook request using an HMAC-SHA256 signature derived from the raw
request payload. This allows your application to verify that:
- The request was sent by Push
- The payload has not been modified in transit
- Extract the signature from the
X-Webhook-Signatureheader - Read the raw request body as bytes (before parsing JSON)
- Compute an HMAC-SHA256 signature using your
webhook_secretand the raw body - Compare the computed signature to the received signature using constant-time comparison
- Reject requests with invalid signatures (
401 Unauthorized)
Code examples for signature verification
Code examples for signature verification
Timestamp Verification
Thetimestamp field in the webhook payload indicates when the webhook was created. To prevent replay attacks, verify that the timestamp is recent (within 10 minutes).Verification Steps- Parse the
timestampfield from the payload (ISO 8601format) - Compare with current time
- Reject requests older than 10 minutes (return
401 Unauthorized)