Payment Reliability

Overview

• Logical operations combine connected attempts so retry-heavy transactions do not distort customer-operation counts.
• The cohort is selected by the first attempt, while final outcome/recovery is evaluated across the related operation.
• Retried / recovered shows how many operations required retry and how many ultimately succeeded.
• Stale pending is a current snapshot for attempts unchanged for 15 minutes.
• Refund pending/failed is shown separately from purchase reliability.

When to use this

• Use this after staff report terminal problems, unusually many retries, or uncertainty over whether payment failures are isolated or systemic.

Step-by-step

1. Set a representative period.
2. Review Approval rate and Stale pending.
3. Compare retry count with retry final success.
4. Review Provider/Terminal/Device breakdown.
5. Open payment diagnostics/logs for the affected hardware/provider.

Common mistakes

• Do not interpret every attempt as a unique sale.
• Do not ignore recovered retries; they still indicate reliability friction.
• Do not automatically retry a stale operation without first using the payment recovery/reconciliation workflow.

Troubleshooting

• If provider-level approval is normal but one terminal is poor, investigate the terminal/device path.
• If failures cluster across all terminals, investigate provider/network/system status.