Retries are dangerous when every failure is treated the same. A timeout, a hard decline, a failed capture, and a failed refund do not deserve one generic retry loop.
MasonXPay separates retry behavior by operation type so recovery stays useful without creating unsafe background money movement.
Three Different Retry Problems
MasonXPay keeps these concepts separate:
technical retry
Short retry inside one provider-call boundary.
route fallback
Try another route step when the normalized outcome allows it.
scheduled recovery
Delayed recovery for operations that can safely be retried later.
This separation matters because each path has different risk, user experience, and idempotency requirements.
Capture Recovery
Manual capture can fail after an authorization is already in a capturable state. If the failure looks recoverable, MasonXPay can schedule a bounded recovery job instead of immediately marking the payment terminal.
The due-job worker claims work, calls the provider outside the database transaction, and records the outcome with normal payment state and outbox events.
Refunds Stay Conservative
Refund retry is intentionally more conservative. A duplicate refund can cost the merchant money, so automatic refund retry is disabled by default.
Failed refunds can remain visible for review. MasonXPay can support provider-specific refund retry later, but it should require explicit approval, provider-specific retryability, and strong idempotency guarantees.
Invoice Dunning Is Its Own Worker
Recurring invoice retry is not part of customer-present checkout retry or Phase O route fallback. Billing owns invoice retry and dunning through its own worker and invoice state.
That keeps recurring payment obligations scoped to subscriptions and invoices instead of leaking into a generic payment retry engine.
Why This Is Operationally Better
Operators can answer:
- what failed
- whether it is safe to retry
- when the next attempt is due
- how many attempts remain
- whether a human should review the operation
The dashboard can show scheduled recovery without pretending every provider failure should be automatically retried.
The Rule
Retry only when the operation type, provider outcome, credential boundary, and idempotency key make it safe.
That rule is slower than “retry everything,” but it is the right tradeoff for payment operations.