When a payment times out, can checkout safely retry?

Assume the order already has the authorization needed for capture. The evaluation covers one logical payment with one intended capture for the agreed amount. Split tender, partial captures, refunds, and settlement reconciliation sit outside its scope. They need their own rules and checks.

A normal test confirms that a response marks the order paid. The harder case starts when the response is missing. Creating a new payment operation can duplicate the charge. Suppressing every retry can leave the customer charged while the order remains unresolved. The recovery rule must address both states.

The payments owner supplies the API version, operation identity, allowed amount, retry window, and reconciliation method. The team selects a payment test account or a simulator whose behavior is documented. No live payment credentials belong in the fixture.

Stripe documents that API v1 retries with the same key return the saved result after execution begins. Parameters must match, and retained keys can be removed after at least 24 hours. That is one provider contract, not a universal payment rule. The actual integration determines which recovery cases are valid.

In the proposed Zof workflow, the engineering owner provides the candidate change, relevant service interfaces, existing checks, and fixture assumptions. System Graph supplies the connection between the handler and its dependencies. The resulting scope should include order reconciliation as well as the immediate payment response.

The Verification Engine selects and runs verification using approved tools, customer validators, and existing CI evidence. Here, the useful output is a finding tied to the candidate, failure condition, and affected order. Engineers still define correct financial behavior, approve access, and decide whether the evidence supports rollout.

The timeline deliberately separates provider state from checkout state. An HTTP success on the recovery request is insufficient. The reviewer needs the final capture count and amount, the order state, and the connection between both attempts and the original logical payment.

A delayed confirmation, repeated recovery request, and reconnect after interruption exercise different paths. Stripe’s network error guidance explains why restored connectivity alone cannot establish whether an earlier request succeeded. Unresolved outcomes need reconciliation under the provider’s rules, rather than a fresh operation created merely to clear an error.

A simulator can establish that checkout reacts correctly to a defined response sequence. It cannot establish that a real provider produces that sequence under every condition. Record what the fixture represents, which store configurations are covered, and which behavior still needs a provider test environment.

If local connectivity changes the result, assess execution inside the store network during scoping. The owner approves the accounts, paths, and evidence location. Any proposed fix returns through engineering review and the same recovery checks before a wider rollout is considered.

The release owner should stop the rollout for an unintended additional capture, a wrong amount, or an order that remains unresolved beyond the agreed recovery policy. Missing evidence is an open question, not a pass. Each exception needs an owner and a disposition.

Measure review effort separately if efficiency is an evaluation goal. Use comparable releases and a consistent definition of review time. Keep that measurement separate from the payment correctness checks, and retain the fixture’s provider and tender limits in the release record.