Test a drop-in payment component with 3DS2

The checks that matter

The assertions worth making about a drop-in are the ones that survive the component being rebuilt underneath you.

Asserting the amount inside the authentication dialog, and not only on the checkout page, is the check that matters most. A challenge presenting a different figure than the order is something the shopper approves without realising.

The flow as a test file

The card number chosen is what triggers the challenge. A standard test card would settle directly and the authentication path would never be exercised.

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

# Adyeen 13.1: Drop-in payment

Catalog objective: pay via the Adyeen drop-in with a test card and 3DS2.
Key assertion: the authorised result is surfaced to the shopper.

## Choose the card method
Verify the page subtitle reads "Northwind Software · €129.50", then choose "Card" in the drop-in.

## Use the 3DS2 test card
Type "4212 3456 7890 1237" into "Card number", "03 / 30" into "Expiry", "737" into "CVC", and click "Pay €129.50".

## Complete the 3DS2 challenge
Verify a dialog titled "3DS2 authentication" opens showing "Amount" of "€129.50", then click "Complete authentication".

## Verify the authorised result
Verify a green banner titled "Payment authorised" shows "Result code" of "Authorised" for ORD-55120, with "PSP reference" of "PSP883000001717", "Method" of "Card", "Amount" of "€129.50" and a badge reading "3DS2 authentication completed".

The final assertion checks five values at once, including the badge stating authentication completed, which is the detail that determines liability on a disputed charge.

Step by step coverage

Every step leaves the flow somewhere the next assertion can see, which is what keeps a multi-stage payment readable as a file.

The PSP reference is the value that ties this run to the provider record. Asserting it means a failed run hands support something to search on rather than a screenshot.

Adding it to a suite

kane-cli testmd run tests/adyen/drop-in-payment_test.md

The same file runs against a test environment and a live integration by changing only the starting URL and the card values.

Payment components update without asking, which makes this worth scheduling rather than running on request. Kane CLI in a pipeline covers the flags and exit codes, and how browser agents interpret a page explains why the plain English steps survive a component rewrite.