CityPay Testing Framework
Use the CityPay testing framework to select the right test path for your integration, apply the required 3DS checks, and gather the evidence CityPay needs for a best-effort readiness review.
The framework is built around:
- one base pack per integration path
- a mandatory 3DS layer for ecommerce cardholder-initiated payments
- optional overlays for higher-risk use cases such as stored credential, scheduling, retries, and webhooks
- a small number of reference packs rather than one giant master guide
This section currently focuses on the first published packs:
Read these pages first:
Use the legacy Testing Best Practices page as a lower-level reference for the existing sandbox, but treat this /testing section as the structured framework going forward.
The first wave of published packs is intentionally narrow:
| Pack | Use when | Main focus |
|---|---|---|
| Elements + 3DS | You use CityPay Elements for ecommerce checkout | intent state, 3DS handling, duplicate prevention, evidence |
| API / server-led + 3DS | You run a direct API-led ecommerce flow | 3DS challenge handling, request flagging, evidence |
| Paylink + 3DS | You use Paylink hosted checkout | token flow, hosted 3DS, return paths, evidence |
Stored credential and MIT packs are the next step, but they are intentionally deferred until the recurring-intent and recurring-authority shape is fully documented.
Every scenario is marked as one of:
| Lane | Meaning |
|---|---|
Automated | Can be validated through a direct sandbox or API call |
Synthetic | Can be validated without a browser, but still depends on hosted or stateful payment orchestration |
Manual only | Requires a human-visible check of rendered form or challenge behaviour |
This keeps the framework practical without relying on browser automation.