Card Holder Account and Token API SAQ Guide
This decision guide is for merchants and integrators using CityPay cardholder accounts, card tokens or token-based API processing.
Token-based processing does not by itself determine SAQ eligibility. The key question is how the token or cardholder account was created, and whether merchant systems handled PAN or sensitive authentication data before tokenisation.
Use the guide that matches the original PAN capture method. A token created after merchant systems handled PAN does not usually make the earlier capture environment eligible for a reduced SAQ.
| Original capture method | Usual SAQ route | Use this guide |
|---|---|---|
| Paylink hosted form | Usually SAQ A | Paylink |
| Elements hosted fields/components | Usually SAQ A | Elements |
| Direct Post API browser submission from merchant checkout page | Usually SAQ A-EP | Direct Post API |
| Merchant server received PAN before creating or using a token | Usually SAQ D Merchant | API |
| Staff entered card details into CityPay Virtual Terminal | Usually SAQ C-VT | Virtual Terminal |
| CityPay-hosted IVR captured the card details | Usually channel-specific reduced scope | IVR |
Part 2b - Description of role with payment cards
Use this wording where the original token was created through CityPay-hosted capture and merchant systems did not handle PAN:
The merchant uses CityPay cardholder account or token references for subsequent payment processing. The original cardholder data capture was performed using CityPay-hosted payment capture, and the merchant systems did not electronically store, process or transmit PAN or sensitive authentication data before token creation. Subsequent processing uses CityPay-issued references rather than raw cardholder data.
Use this wording where merchant systems handled PAN before token creation:
The merchant uses CityPay cardholder account or token references for subsequent processing, but the original capture flow involved merchant systems receiving, processing or transmitting PAN before token creation. Those merchant systems are included in the assessed cardholder data environment.
Part 2c - Description of payment card environment
The assessed environment is determined by the original card capture method used to create the CityPay token or cardholder account. Systems that only store or transmit CityPay token references may be separate from systems that handle PAN, but any system that captured, processed, transmitted, logged or could affect PAN capture must be assessed under the relevant SAQ route.
Part 2f - Third-party service providers
| Service provider | Description |
|---|---|
| CityPay Limited | CityPay PSP and TPSP operating its own gateway, providing cardholder account, tokenisation, gateway, authorisation, processing and related payment services. |
Also list any third party that can affect the original capture flow or token-based processing environment.
Retain:
- CityPay AOC or PCI DSS compliance confirmation
- documentation showing how tokens or cardholder accounts are created
- data-flow evidence for the original PAN capture method
- product guide evidence pack for the applicable capture route
- access controls for systems that can use tokens
- controls preventing token misuse, such as authentication, authorisation and logging
- TPSP list and annual review
- incident response plan