KEY TAKEAWAYS
- Errors are provider-side events, not card verdicts.
- Fallback routing converts many transient failures into answers.
- Timeouts tuned to p95 latency prevent error storms.
- Errors are never charged.
Errors are inevitable when checking cards through third-party gateways — the question is how the platform handles them. This page publishes the error kinds we observed over the last 90 days (31 of 278 checks, 11.2%).
Error kinds observed
| Kind | Count | Share |
|---|---|---|
| unknown | 30 | 96.8% |
| timeout | 1 | 3.2% |
What each kind means
- timeout / deadline: the gateway did not answer in time — usually provider congestion or a slow upstream.
- http_5xx: the provider returned a server error. Transient by nature.
- transport: connection reset or DNS/TLS failure on the route.
- empty / unknown: a response arrived but contained no usable classification.
How we reduce their impact
- Fallback routing: a transient error on the primary gateway is retried on a fallback before the card is ever marked as an error.
- Per-gateway timeouts: tuned to each provider's p95 so slow tails do not turn into error storms.
- Rolling concurrency windows: keeps throughput stable and stops waves of queued requests from timing out together.
- Error typing: every failure records its kind, which is how this page exists.
The practical checklist for your own runs is in how to reduce checker error rates.
Methodology
Error kinds are recorded per failed check and aggregated over the last 90 days. Errors are not billed. No customer data is used or published.