A webhook retry happens when a payment provider tries again to send a webhook notification that did not get through. The provider posts each event, such as a payment succeeding or a payout failing, to the client's callback URL and waits for a success response. If the client's server is down, slow or returns an error, the provider queues the event and sends it again later, typically at lengthening intervals over several hours or days before giving up.
Retries make delivery reliable but introduce duplicates. A client may receive the same event twice. Its handler must therefore apply idempotency, recording each event identifier and ignoring repeats, so that an order is not shipped or a ledger credited twice. Good practice is to acknowledge quickly, place the event on a message queue for processing, verify the provider's signature and use status polling to recover anything missed after retries are exhausted.