Test an iDEAL redirect and the state it returns with

The contract this flow keeps

A redirect flow makes three promises, and each one breaks independently of the others.

• The method changes the form - choosing iDEAL reveals a bank selector rather than card fields.
• The chosen issuer is carried - the button names the bank the shopper picked, so a silent default is visible.
• The redirect presents the right amount - the issuer page shows the same figure as the checkout.
• The return is interpreted correctly - an authorised result naming iDEAL and the specific bank.

The last assertion carries the most weight. A redirect that returns and is read as pending or failed loses a payment the bank has already approved, and the shopper is charged with no order to show for it.

The objective in plain English

The issuer is selected by name and then asserted on the continue button, which is a cheap way to prove the selection reached the redirect rather than falling back to a default.

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

# Adyeen 13.2: iDEAL redirect

Catalog objective: select iDEAL in test and complete the issuer simulation.
Key assertion: the redirect returns with an authorised state.

## Choose iDEAL
Choose "iDEAL" in the drop-in and verify a "Your bank" dropdown appears.

## Pick the issuer
Select "Rabbo Bank" in "Your bank" and verify the button reads "Continue to Rabbo Bank".

## Complete the issuer simulation
Click "Continue to Rabbo Bank" and verify a dialog titled "Rabbo Bank - issuer simulator" opens showing "Amount" of "€129.50", then click "Approve payment".

## Verify the redirect returned authorised
Verify a green banner titled "Payment authorised" shows "Result code" of "Authorised", with "Method" of "iDEAL" and "Detail" of "Rabbo Bank".

The final step asserts both the result code and the method detail, so a payment that authorises but is recorded against the wrong instrument fails.

Assertion by assertion

Each assertion sits on one side of a boundary the payment has to cross.

Asserting the bank name on the result, and not just the method, is what distinguishes a correctly attributed payment from one that authorised through some other route.

Putting it in CI

kane-cli testmd run tests/adyen/ideal-redirect_test.md

In a pipeline this runs headless with the same file. Redirect flows are exactly the case people assume needs a person watching, and they do not.

A redirect that never returns is the failure mode to plan for. Agent mode and NDJSON output covers reading that result programmatically, and the three modes covers running it interactively first.