Testing Overview

CityPay testing guidance is structured to be concise, practical, and scalable. Instead of one giant testing guide, each integration starts with a base path and then adds only the layers that actually apply.

Pack Model

The framework is built from:

a base pack: Elements, Paylink, or API / server-led
a mandatory 3DS layer for ecommerce CIT
optional overlays for higher-risk behaviour such as stored credential, scheduling, retries, refunds, and webhooks
reference packs that combine the right pieces for common launch paths

The first published reference packs are:

Readiness

CityPay currently uses a best-effort readiness model rather than a formal certification programme.

Status	Meaning
`Ready`	Critical scenarios passed and evidence is complete
`Ready with risks`	Critical scenarios passed, but important gaps remain
`Not ready`	A critical scenario failed, is missing, or cannot be evidenced

Scenario severity is defined as:

Severity	Meaning
`Critical`	Must pass before CityPay recommends go-live
`Important`	Should pass; failures raise risk
`Advisory`	Useful, but non-blocking

Execution Lanes

Each scenario is assigned one execution lane:

Lane	Use
`Automated`	Direct sandbox or API validation
`Synthetic`	Non-browser hosted-flow or intent-flow validation
`Manual only`	Visible form, challenge, or redirect behaviour

This is deliberate. CityPay’s highest-risk failures are usually in state handling, flags, retry behaviour, and evidence quality rather than browser mechanics.

Evidence

The minimum evidence bundle depends on the path.

Path	Minimum evidence
`Paylink`	`paylink_token`, `trans_no` where available, timestamp
`Elements`	`payment_intent_id`, `trans_no`, timestamp
`API / server-led`	`context_id`, `trans_no`, `identifier`, timestamp

For higher-risk stored credential or MIT flows, add:

agreement reference
original setup reference
card holder account / stored credential reference where applicable

Use the Sandbox and test data page for the named test profiles and expected sandbox outcomes.