Retry policy

A retry policy governs what software does after a provider call or event-processing attempt fails. It distinguishes temporary conditions, such as a timeout or rate limit, from permanent conditions, such as invalid account data. A retry should preserve the original business intent rather than manufacture another charge, message, or work order.

The governing artifact should name retryable errors, maximum attempts, delay and jitter, deadline, idempotency requirement, owner of the terminal exception, and evidence retained for each attempt. It should also define when the system queries the provider instead of writing again. Generic “three retries” configuration is incomplete without those decisions.

Consider an accounting sync that receives a rate-limit response while posting a tenant payment. Waiting and retrying the same idempotent request may be appropriate. Retrying a validation error without correcting the mapping wastes calls. Retrying after a response timeout with a new request identity risks a duplicate. Each branch requires a different control.

For a small portfolio, judge the policy by its failure boundary, not by how quickly the happy path completes. Ask to see a transient error recover, a permanent error stop, and an unknown payment result enter reconciliation. If all three become the same red banner, the integration is transferring diagnostic work to the landlord.