---
title: "Verify asynchronous payment confirmation updates a pending order honestly"
description: "Keep a sandbox payment pending, inspect the customer-visible order state, then deliver the supported completion event and verify one durable paid transition."
canonical_url: "https://vostride.com/agent-library/checkout-payments/pending-payment-webhook.md"
md_url: "https://vostride.com/agent-library/checkout-payments/pending-payment-webhook.md"
content_kind: "recipe"
topic: "checkout-payments"
---

# Verify asynchronous payment confirmation updates a pending order honestly

Keep a sandbox payment pending, inspect the customer-visible order state, then deliver the supported completion event and verify one durable paid transition.

## Risk

Asynchronous payment methods separate browser return from settlement. A pending order must not be presented as paid, and processing the eventual completion event should update the same order without duplicating fulfillment or inventory effects.

## Fixtures

- A provider-supported asynchronous sandbox payment fixture with controlled pending and completion states.
- A test customer and uniquely identified checkout intent.
- Application hooks for order status, payment state, webhook processing, and logical fulfillment requests.

## Steps

1. Submit checkout using the asynchronous fixture and return to the application while payment remains pending.
2. Verify the confirmation clearly says payment is pending or awaiting confirmation and shows the intended order identifier without a paid receipt claim.
3. Open order history and reload; verify the same pending state persists while the independent payment hook remains unsettled.
4. Complete the payment through the supported sandbox event fixture and wait for the documented processing boundary.
5. Reload the order and verify paid status; inspect hooks for the matching successful payment, one state transition, and one logical fulfillment request.

## Expected results

- The application does not claim settlement before the provider fixture settles.
- Completion updates the existing order identity to paid.
- Downstream fulfillment follows one logical successful-payment event.

## False-pass traps

- A browser return URL containing a success-like word does not establish asynchronous settlement.
- Directly editing the order status bypasses the event-processing behavior this scenario needs to verify.

## Cleanup

- Cancel or refund the sandbox order and remove its queued test fulfillment work.

## 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)