---
title: "Verify refreshing the payment return page does not repeat purchase effects"
description: "Complete a sandbox redirect payment, revisit its application return URL, and verify the same order is displayed without repeating charge or fulfillment actions."
canonical_url: "https://vostride.com/agent-library/checkout-payments/payment-return-refresh.md"
md_url: "https://vostride.com/agent-library/checkout-payments/payment-return-refresh.md"
content_kind: "recipe"
topic: "checkout-payments"
---

# Verify refreshing the payment return page does not repeat purchase effects

Complete a sandbox redirect payment, revisit its application return URL, and verify the same order is displayed without repeating charge or fulfillment actions.

## Risk

Payment return handlers may be visited repeatedly through refresh or browser history. Rendering an existing confirmation should be safe; payment capture, inventory deduction, and fulfillment enqueueing must follow the application one-order contract.

## Fixtures

- A sandbox redirect-payment method and a test cart with known item quantity.
- A run-owned order marker and a fulfillment fixture that records enqueue events without shipping anything.
- Hooks for order identity, captured payments, inventory movements, and fulfillment job identifiers.

## Steps

1. Complete the sandbox redirect payment and verify the application return page displays the intended order identifier and amount.
2. Refresh the return page twice through normal browser navigation and verify each result references the same order.
3. Navigate away to order history and return through browser history; verify the confirmation remains coherent and does not ask for another payment.
4. Inspect payment and inventory hooks to confirm one successful capture and one intended inventory movement.
5. Inspect the fulfillment fixture and verify only the documented one logical fulfillment request exists for this order, accounting for retried job attempts separately.

## Expected results

- Repeated visits render the existing order rather than create another purchase.
- Payment capture and inventory effects remain singular.
- Fulfillment scheduling refers to the same logical order and is not duplicated by page navigation.

## False-pass traps

- A stable confirmation number can conceal repeated downstream fulfillment jobs.
- Queue retry attempts must not be confused with separate logical fulfillment requests.

## Cleanup

- Cancel the sandbox order, drain its test fulfillment jobs, and restore inventory.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa test](/docs/agent-qa/configuration/test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa auth state](/docs/agent-qa/guides/auth-state.md)

- [Checkout and payment QA recipes](/agent-library/checkout-payments.md)
- [Software factory QA library](/agent-library.md)