API / Server-Led + 3DS

This pack validates a server-led ecommerce card flow where your system controls the request and challenge handling directly. It is higher risk than hosted flows because incorrect 3DS orchestration, flags, or evidence capture are easier to get wrong.

Use this pack when:

• your application calls the payment API directly
• you handle ecommerce 3DS request and response processing
• you need to validate challenge initiation, challenge completion, and evidence quality

ID	Scenario	Lane	Profile	Severity	Pass criteria	Evidence
A3-01	Approved Visa ecommerce payment	Automated	TD-VISA-APPROVAL-01	Critical	payment is authorised successfully and request identifiers are traceable	context_id, trans_no, identifier, timestamp
A3-02	Approved Mastercard ecommerce payment	Automated	TD-MC-APPROVAL-01	Critical	payment is authorised successfully and evidence is complete	context_id, trans_no, identifier, timestamp
A3-03	Generic decline is returned safely	Automated	TD-VISA-DECLINE-01	Critical	decline is explicit and no ambiguous partial success remains	context_id, trans_no, identifier, timestamp, response summary
A3-04	AVS, CSC, fraud, and comms mappings behave as expected	Automated	mapped negative profiles	Important	sandbox mappings produce the expected outcome and are recorded correctly	context_id, trans_no, identifier, timestamp
A3-05	Frictionless authenticated 3DS path succeeds	Automated	CSC 750	Critical	3DS result is authenticated and the final auth is traceable	context_id, trans_no, identifier, timestamp, auth result
A3-06	Challenge-required path reaches request-challenged state	Automated	challenge-triggering CSC	Critical	API returns the expected challenge response and session identifiers	context_id, identifier, timestamp, challenge response
A3-07	Challenge result can be completed safely	Synthetic	challenge path	Critical	challenge-result handling produces one final traceable outcome	context_id, trans_no, identifier, timestamp
A3-08	Failed or rejected challenge does not produce an approved authorisation	Synthetic	challenge-failed path	Critical	failed authentication is preserved and not treated as success	context_id, trans_no, identifier, timestamp, auth result
A3-09	Duplicate-prevention behaviour is stable	Automated	approval profile	Critical	same logical attempt does not create multiple charges	context_id, trans_no, identifier, timestamp
A3-10	Visible challenge handoff can be smoke-tested once	Manual only	challenge path	Important	tester can observe the challenge handoff controller working end to end	tester notes, timestamp

Manual checks for this pack should stay narrow:

• one visible challenge handoff smoke test
• confirmation that the cardholder-facing handoff is understandable

Everything else should be exercised through Automated or Synthetic lanes.