Failure scenarios
How the controller responds when payment evidence is incomplete, conflicting, or unsafe to act on. Entries are grouped by the step where the failure happens, in the order the loop reaches them.
Evidence in
- Provider API timeout
- Retries the read up to the retry limit, then escalates.
- Provider rate limit
- Waits with exponential backoff, then retries the read.
- Evidence connector denied
- Continues with provider API evidence and records the evidence connector gap.
- Webhook absence
- Fetches the payment and order directly from the provider API.
- Duplicate webhook
- Suppresses the duplicate webhook and continues processing.
- Stale provider read
- Discards the stale read and fetches a fresh one from the provider.
- System restart
- Resumes from the last saved completed step.
Checked
- Reordered webhook
- Rebuilds the evidence in the order the events occurred, then classifies the exception.
Diagnosed
- Model failure
- Falls back to the rule-based diagnosis and records the model failure.
- Research failure
- Continues with the evidence already cited and records the research gap.
Applying
- Merchant acknowledgement loss
- Pauses execution and re-verifies the current state before making another change.
Verifying
- Conflicting verification result
- Keeps the exception open and escalates the conflicting observations.