Elements + 3DS
This pack validates an ecommerce CityPay Elements integration with 3DS enabled. It focuses on state handling, challenge orchestration, duplicate prevention, and support-grade evidence.
Use this pack when:
- checkout uses CityPay Elements
- the payment is an ecommerce cardholder-initiated transaction
- 3DS is required in scope
- you need a practical go-live pack before stored credential or MIT flows are added
| ID | Scenario | Lane | Profile | Severity | Pass criteria | Evidence |
|---|---|---|---|---|---|---|
E3-01 | Create payment intent and complete approved Visa flow | Automated | TD-VISA-APPROVAL-01 | Critical | intent is created and remains traceable through authorisation | payment_intent_id, trans_no, timestamp |
E3-02 | Create payment intent and complete approved Mastercard flow | Automated | TD-MC-APPROVAL-01 | Critical | approval path succeeds and identifiers are captured | payment_intent_id, trans_no, timestamp |
E3-03 | Declined payment returns a stable failed outcome | Automated | TD-VISA-DECLINE-01 | Critical | decline is handled safely without ambiguous state | payment_intent_id, trans_no, timestamp, response summary |
E3-04 | Frictionless 3DS authenticated path completes | Synthetic | use Visa or Mastercard with frictionless outcome | Critical | intent reaches the expected authenticated state without customer challenge UI | payment_intent_id, trans_no, timestamp, auth result |
E3-05 | Challenge-required path is accepted and results in success | Synthetic | use challenge outcome | Critical | challenge orchestration succeeds and final auth is traceable | payment_intent_id, trans_no, timestamp, challenge result |
E3-06 | Challenge-required path does not duplicate authorisation | Synthetic | use challenge outcome | Critical | same logical attempt results in one final authorisation only | payment_intent_id, trans_no, identifier, timestamp |
E3-07 | Duplicate-prevention controls work across the same logical attempt | Automated | approval profile | Critical | reuse of the same logical attempt does not create duplicate charging | payment_intent_id, trans_no, identifier or idempotency evidence, timestamp |
E3-08 | Evidence extraction bundle is complete | Automated | any completed scenario | Critical | support can trace the scenario using the standard identifiers | payment_intent_id, trans_no, timestamp |
E3-09 | Hosted field mount and submit affordance are visible | Manual only | n/a | Important | tester can mount fields, enter details, and see expected submit behaviour | tester notes, screenshots if needed |
E3-10 | Visible challenge smoke path behaves correctly | Manual only | challenge path | Important | tester can see the challenge handoff and expected post-challenge outcome | tester notes, timestamp |
Manual checks for this pack should be limited to:
- fields mount successfully
- card entry is possible
- visible challenge handoff works at least once
- final user-visible outcome is understandable
Do not use browser automation for these checks in v1.