StoreSteadyStoreSteady
StoreSteady taxonomy v1.0

Checkout recoverability

The classification of a checkout exception by whether the agent can resolve it automatically, whether the buyer must provide input, or whether a human review is required.

Term code: CHK-RECOVERFamily: CHK · Agentic checkout exceptionsLast reviewed: 2026-05-20

Definition

The classification of a checkout exception by whether the agent can resolve it automatically, whether the buyer must provide input, or whether a human review is required.

StoreSteady treats checkout recoverability as a reference term because No recoverability classification: Every error is unclassified, forcing agents to give up or escalate.

Why it matters

  • No recoverability classification changes what a crawler, shopping channel, or AI assistant can safely infer about the merchant surface.
  • Without a named category, operators tend to treat checkout recoverability as generic AI noise instead of a reproducible finding with evidence and a validation path.

Evidence sources

  • per-exception recoverability classification on checkout responses; the operational metric "% of exceptions resolved without human intervention."

How StoreSteady detects it

Planned - Breakage Index

Inventory the merchant's checkout exception responses against the three recoverability classes (`agent_can_resolve`, `buyer_input_required`, `buyer_review_required`). Replay each class and measure actual resolution.

False positive risks

  • A merchant returning an HTTP 500 with no business-logic classification at all.
  • A merchant returning `failure: true` with no machine-readable reason.

How to fix it

  1. Identify the merchant-controlled source that creates the checkout recoverability signal.
  2. Reconcile visible copy, machine-readable data, policy text, feed state, and checkout behavior where the term applies.
  3. Keep the fix high-level in public docs; detailed remediation belongs inside paid scan workflows.

How to validate it

Rerun the same evidence capture used for detection. The finding is validated only when the original checkout recoverability signal no longer reproduces and adjacent source surfaces still agree.

Example finding

info

No recoverability classification

Observed: A merchant returns `out_of_stock` with `recoverability: agent_can_resolve` and an alternate-variant payload. The agent autonomously substitutes.

Likely impact: No recoverability classification: Every error is unclassified, forcing agents to give up or escalate.

Probable fix location: Checkout or cart flow

Related StoreSteady issue codes

CodeTitleScanner mapping
CHK-001Recoverable stock or address blockPlanned detector
CHK-002Buyer-input-required exceptionPlanned detector
CHK-003Buyer-review-required exceptionmerchant_pending_policy_review
CHK-004Payment or fraud blockPlanned detector
CHK-005Non-standard error signalinglanding_page_error, image_link_internal_error

Related standards

See also

Sources

Run a scan against this category

StoreSteady scans public commerce evidence and maps findings back to documented taxonomy terms.

Run a free scan