Sandbox and Test Data

Use named test profiles rather than ad hoc card details wherever possible. This makes execution repeatable and evidence review easier.

Recommended v1 named profiles:

Profile IDSchemePurposePANCSCAmount
TD-VISA-APPROVAL-01VisaStandard approval4000 0000 0000 00021231000
TD-MC-APPROVAL-01MastercardStandard approval5100 0000 0000 00081231000
TD-VISA-DECLINE-01VisaGeneric decline4000 0000 0000 00023333333
TD-VISA-AVSA-01VisaAVS address failure4000 0000 0000 00023443344
TD-VISA-AVSP-01VisaAVS postcode failure4000 0000 0000 00023553355
TD-VISA-CSC-01VisaCSC failure4000 0000 0000 00023663366
TD-VISA-FRAUD-01VisaFraud decline4000 0000 0000 00023773377
TD-VISA-COMMS-01VisaCommunication error4000 0000 0000 00026666666

The profile ID is the shorthand used in pack tables. For example, TD-VISA-APPROVAL-01 means “the first standard Visa approval dataset defined on this page”.

TD-VISA-APPROVAL-01

FieldValue
PurposeStandard Visa approval
PAN4000 0000 0000 0002
Expiry04/28
CSC123
Amount1000
Billing profiledefault known-good address
Expected auth outcomeapproved
Expected 3DS outcomepack-dependent

TD-MC-APPROVAL-01

FieldValue
PurposeStandard Mastercard approval
PAN5100 0000 0000 0008
Expiry04/28
CSC123
Amount1000
Billing profiledefault known-good address
Expected auth outcomeapproved
Expected 3DS outcomepack-dependent

TD-VISA-DECLINE-01

FieldValue
PurposeStandard generic decline
PAN4000 0000 0000 0002
Expiry04/28
CSC333
Amount3333
Billing profiledefault known-good address
Expected auth outcomedecline 090
Expected 3DS outcomenot applicable unless explicitly combined with a 3DS-specific scenario

The current sandbox cards are:

Card NumberSchemeTypeCSC Length
3743 871880 19714AmexCredit4
3014 445396 5469DinersCredit3
3528 0000 0000 0007JCBCredit3
4000 0000 0000 0002VisaCredit3
4659 0100 0000 0005VisaDebit3
5100 0000 0000 0008MastercardCredit3
5573 4700 0000 0001MastercardDebit3
4508 7500 0000 0009Visa ElectronDebit3
4857 7900 0000 0002Visa BusinessDebit3

Published v1 examples should focus on Visa and Mastercard unless scheme-specific behaviour is being tested.

The current test gateway maps amounts and CSC values to fixed outcomes.

AmountCSCBehaviourResponse
3333333Generic decline090
3344344AVS address failure095
3355355AVS postcode failure096
3366366CSC failure094
3377377Fraud decline091
4444444Referral089
6666666Communication errorF006
5544544AVS address failure if AVS is configured095
5555555AVS postcode failure if AVS is configured096
5566566CSC failure if CSC is configured094

Policy-dependent AVS and CSC cases should be recorded clearly in the scenario evidence, because they depend on merchant configuration as well as the test values.

For API-led 3DSv2 testing, the current CSC mappings are:

CSCBehaviour
731Frictionless processing, not authenticated
732Frictionless processing, account verification count not performed
733Frictionless processing, verification rejected
741Frictionless attempts processing
750Frictionless authenticated
7613DS error
Any other valueChallenge request

Use these mappings to classify the expected 3DS outcome for API / server-led + 3DS scenarios. Where a hosted flow abstracts these details, record the intended outcome and the returned authentication result.

Use the following defaults for v1 pack execution unless a scenario says otherwise:

FieldValue
Expiry04/28
First nameTest
Last nameCustomer
Emailtest.customer@example.com
Address line 1999 Nowhere Lane
Town / CityFakeville
PostcodeZZ9 9ZZ
CountryGB

There is currently no clean, realistic “bad address” data profile in the test gateway. Treat address-variation testing beyond the fixed mappings as deferred.