Webhooks and callbacks

Webhooks and callbacks: signed, retried, resendable, journaled for five years

Tranzify callbacks: every provider callback parsed, verified and journaled; merchant webhooks signed and retried on a schedule; manual resend and reprocessing from the back office; per-brand webhook domains; the whole chain of a payment in one trace.

Two directions, one journal

Providers call Tranzify when a payment changes; Tranzify calls the merchant. Both directions go through the same service: signatures verified, statuses mapped, bodies stored, retries scheduled, and every event tied to the payment’s reference so that the back office shows the whole chain in one trace. The service runs apart from the payment flow, so a slow merchant endpoint never slows a payment, and a burst of provider callbacks never loses one.

What merchants get

Signed webhooks with the merchant’s secret; every event carries its own identifier and the payment’s reference.
Retries on a schedule, the attempt history with the endpoint’s answers, and a resend button in the merchant cabinet and the back office.
Payment, refund, payout and chargeback events in one format for every method, with the payment’s reference, the merchant’s order identifier and the amounts.
A webhook domain per network, so brands stay separate; the sender’s address and the signature’s secret belong to the merchant’s network.

What operators get

The received callbacks with their raw bodies, the outcome of each (applied, ignored, conflict), manual reprocessing when a provider’s data arrives late, and the rules that keep a final status final. A callback that would move a successful payment back to pending is recorded as a conflict and shown for review, not applied; an operator who changes a status by hand writes a reason that stays in the journal.

The rules of the chain

Situation	What the platform does
The provider’s signature does not verify	The callback is stored, marked rejected and alerted; nothing changes on the payment
The callback repeats one already applied	Ignored, with a record that it came
The callback contradicts a final status	Logged as a conflict for the operator; the status stays
The callback arrives late, after the payment expired	Reprocessed on the operator’s command, with the amount and the time received
The merchant’s endpoint answers 5xx or times out	Retried on a growing schedule; every attempt and answer stored

For the merchant’s developer

A webhook is an HTTPS request to the merchant’s endpoint with a JSON body and a signature header. The body carries the event’s name and identifier, the payment’s or payout’s reference, the merchant’s own order identifier, the status, the amounts and the currency, the method, and the time; the signature is computed over the body with the merchant’s secret. The endpoint answers 2xx when it has stored the event, and does its own processing afterwards, so a slow database never makes the platform retry. The documentation gives the algorithm, examples and the list of events; the sandbox lets the handler be tested before the first real payment.

Why it is a product of its own

Callbacks are where payment platforms break: a status applied twice, a late callback that re-opens a closed payment, a webhook lost because the merchant’s server was restarting at the wrong second. Treating them as a service with its own journal, retries and screens is what makes support able to answer “what happened to this payment” with the full chain in front of them, and finance able to trust that the ledger saw every event once. Every entry is kept for five years, searchable by the payment’s reference, the merchant and the provider.

Frequently asked questions

What if the merchant's endpoint is down?+

The webhook is retried on a growing schedule until the merchant answers 2xx or the schedule ends; every attempt is visible, and an operator can resend from the back office at any time.

How does Tranzify handle provider callbacks?+

Each provider’s signature is verified and its statuses mapped; the original body is kept; a callback for a payment already in a final state never rolls it back — conflicts are logged for review.

Can callbacks carry the client's brand?+

Yes: webhooks are sent from the network’s own domain and sender, so a white-label partner’s merchants see only the partner’s name.

How does a merchant verify a webhook?+

By recomputing the signature over the body with its secret and comparing it with the header; the documentation gives the algorithm and examples.

What if a provider's callback arrives before the answer to the request?+

The platform orders them by the payment’s reference: the callback is kept, the payment’s state is updated once, and the merchant gets one webhook with the final status, not two in the wrong order.

Are webhooks sent for every change?+

For every change of a payment, refund, payout or chargeback: creation, pending, success, failure, expiry, refund, reversal, with the same format for every method.