Short answer

There is no 3D Secure version 7. The EMV 3DS specification versions in current use are 2.1, 2.2, 2.3, and 2.3.1. A "3D Secure test card v7" is a label on a vendor test card list, not a protocol version and not a card type. Test cards are sandbox credentials issued by a payment processor. They work in test mode and are declined in live mode.

read more

What test cards do

A test card number is a PAN a processor reserves for sandbox use. Each number is tied to a preset result. Common results:

3D Secure Test Card V9

• Frictionless approval. No challenge is shown.
• Challenge required. The ACS asks the cardholder to authenticate.
• Authentication failed. The ACS returns a failed status.
• Authentication unavailable. The ACS does not answer in time.
• Processing error. The processor returns an error code.

The 3DS authentication response carries a transStatus value. Y means authenticated. N means not authenticated. U means unable to authenticate. A means attempted. A merchant maps these values to its own authorization rules.

3d secure test card v9

Where the numbers come from

Processors publish their own lists. Stripe, Adyen, Checkout.com, Braintree, and Worldpay each keep one. Stripe documents 4000002500003155 as a card that requires 3DS and 4000000000003220 as a card that starts a 3DS2 challenge. Numbers differ between processors. A Stripe test number does not work in an Adyen sandbox, and the reverse holds.

related article

Why lists carry a version number

Processors add scenarios over time. Challenge window sizes change. New status codes appear with each EMV 3DS release. When the list changes, the vendor bumps a revision number in its own documentation. No industry registry assigns those numbers. One vendor's v7 has no relation to another vendor's v7.

Sandbox versus live traffic

In live mode, an enrolled card is routed to the issuer ACS through the 3DS Server and the DS. A sandbox PAN is not enrolled at any issuer, so the directory returns a not enrolled or unavailable result. PANs that no processor reserved for test mode do not act as test cards.

Test sequence

1. Get sandbox API keys and the current test card list from the processor.
2. Run one transaction for each scenario in the list.
3. Set the challenge window size the integration uses in production.
4. Log the transStatus, the eci, and the cavv or dsTransID for each run.
5. Re-run the suite after each processor changelog entry.

Not known: the origin of the v7 tag. No public spec uses that numbering. Check the processor docs for the list you are testing against.