zift-webhooks

Zift Webhooks

Zift (a payments platform / gateway) delivers notifications — billing and processing events — to an HTTPS endpoint you register with Zift support. Each delivery is a plain HTTPS POST with a JSON body. There is no signature, no HMAC, and no auth header on the delivery. Instead, your endpoint proves it received the notification by echoing the notificationId back in the response body — that response is the acknowledgement, and skipping it triggers retries.

When to Use This Skill

• How do I receive Zift webhook notifications?
• How do I acknowledge a Zift webhook (the {"notificationId": ...} response)?
• Why is there no X-Zift-Signature / HMAC header to verify?
• How do I secure a Zift webhook endpoint with no signature?
• How do I handle Zift billing.* and processing.* events (chargeback, return, NOC)?
• Why does Zift keep retrying / marking my webhook Failed?

Verification & Acknowledgement (core)

There is NO per-message signature/HMAC header on Zift notifications. Do not look for X-Zift-Signature, webhook-signature, or any Standard Webhooks header — none exists, and Zift sends no Basic/token auth on delivery either. Authenticity relies on the transport and endpoint secrecy:

1. HTTPS only — publish the endpoint over TLS so the body can't be read or tampered with in transit.
2. Endpoint-URL secrecy — treat the path as a shared secret; use a long, unguessable path.
3. IP allowlisting (recommended) — restrict inbound to Zift's egress ranges at your load balancer / firewall (confirm ranges with Zift support).

Because there is no body signature, ordinary JSON parsing is fine — the raw bytes are not security-critical (unlike HMAC providers).

The critical part is the acknowledgement. To ACK a delivery your endpoint MUST return a JSON body echoing the received notificationId (Zift accepts an int or a string). Anything else — 200 OK, an empty body, {"received":true} — is not an acknowledgement and triggers Zift's retry schedule.