Test that the merchant status matches the webhook

Failure modes in this flow

Status divergence is expensive precisely because every individual screen looks correct. Nothing throws an error when two systems disagree.

• The shopper is told authorised - with a PSP reference on the confirmation.
• The merchant page shows authorised - against the same order reference and the same PSP reference.
• The notification says authorised - an AUTHORISATION event with success true.
• The parity is stated - a card comparing the UI status to the notification status directly.

The PSP reference is what ties the three together. Without asserting it on each surface, three screens reading authorised could refer to three different payments and the test would still pass.

Writing the objective

The test takes a real payment first rather than reading an existing record, so the status being compared belongs to a transaction this run created.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/adyen-clone-app/checkout?reset=true
max_steps: 45
tags: [adyen, payments, webhooks]
---

# Adyeen 13.4: Webhook status parity

Catalog objective: after a payment, verify the merchant order page shows the authorised status.
Key assertion: the UI status equals the notification status.

## Take a payment
Type nothing yet - first choose "Card", type "4111 1111 1111 1111" into "Card number", "03 / 30" into "Expiry", "737" into "CVC", and click "Pay €129.50".

## Verify the shopper result
Verify a green banner titled "Payment authorised" shows "Result code" of "Authorised" and "PSP reference" of "PSP883000001717".

## Open the merchant order page
Click "View the merchant order page" and verify "Order reference" reads "ORD-55120", "Status shown to merchant" reads "Authorised" and "PSP reference" reads "PSP883000001717".

## Verify the notification agrees
Verify the webhook list shows "AUTHORISATION · ORD-55120" with "success: true", and the parity card reads "UI status" of "Authorised", "Notification status" of "Authorised" and a badge saying "UI status matches the notification".

The final assertion reads the webhook list and the parity card together, which is what turns three separate observations into a single verified claim.

The assertions in detail

Each step moves to a different surface and asserts the same facts there.

This is a browser test doing work that is usually split between a UI test and a backend integration test, which is what makes it able to catch a divergence between them.

Running it locally

kane-cli testmd run tests/adyen/webhook-status-parity_test.md

Run it after any change to notification handling, since that is the code most likely to drift from the interface it feeds.

For checks against the provider API rather than its rendered pages, the same run can call it directly. Calling APIs inside a browser flow covers that, and evidence based QA covers keeping the proof a reconciliation dispute needs.