PCI DSS SAQ Guide
Use this guide to understand the usual PCI DSS Self-Assessment Questionnaire (SAQ) route for CityPay payment products.
SAQ eligibility depends on your actual implementation, business process, cardholder data flows, and the requirements of your acquirer or Qualified Security Assessor (QSA). This page is general technical guidance and does not determine your PCI DSS validation route.
CityPay is a PCI DSS Level 1 service provider. CityPay's compliance can support your PCI DSS obligations where payment processing is outsourced to CityPay-hosted services, but it does not automatically make your organisation PCI DSS compliant.
You remain responsible for understanding whether your systems electronically store, process or transmit cardholder data or sensitive authentication data, and for maintaining the controls that apply to your environment.
These guides are written for merchants and integrators working with PCI DSS v4.0.1 SAQ forms. Confirm the current form version and your validation route with your acquirer or QSA before submission.
| CityPay product | Integration pattern | Usual SAQ | Merchant guidance |
|---|---|---|---|
| Paylink | CityPay-hosted payment form, either redirect or iframe | Usually SAQ A | Cardholder data is entered into CityPay-hosted payment pages or forms. Merchant systems should not electronically store, process or transmit cardholder data. Evidence CityPay PCI DSS compliance and maintain security of any webpage that links to or embeds Paylink. |
| Elements | CityPay-hosted payment components or fields | Usually SAQ A | Payment form elements originate from CityPay. Merchant website pages that host the integration remain security-relevant and should be patched, access-controlled, scanned where applicable, and protected from unauthorised script changes. |
| Direct Post API | Customer browser posts cardholder data directly to CityPay from a merchant-controlled checkout page | Usually SAQ A-EP | Merchant systems may not receive cardholder data, but the merchant checkout page can affect payment data collection. Stronger e-commerce website controls are expected. |
| API | Merchant server sends cardholder data to CityPay API | Usually SAQ D Merchant | Merchant systems store, process or transmit cardholder data and are part of the cardholder data environment. Full PCI DSS scope may apply. |
| Card Holder Account / Token API | Merchant uses CityPay tokens or cardholder account references | Depends on original card capture method | SAQ depends on how the token or cardholder account was created. If card capture used Paylink or Elements, SAQ A may apply. If PAN touched merchant systems first, SAQ D is likely. |
| Virtual Terminal | Merchant staff enter card details into CityPay-hosted virtual terminal | Usually SAQ C-VT | Applies where staff manually enter cardholder data into a CityPay-hosted browser-based virtual terminal and merchant systems do not electronically store card data. |
| IVR | Customer or staff card entry is captured through CityPay-hosted IVR in CityPay's CDE | Usually channel-specific reduced scope | Applies where cardholder data is captured by CityPay-hosted IVR and merchant systems do not electronically store, process or transmit PAN or sensitive authentication data. Confirm the channel and SAQ route with your acquirer or QSA. |
Use the product guide that matches how PAN is first captured.
| Guide | Use when |
|---|---|
| Paylink | You use Paylink as a redirect or embedded iframe hosted payment form. |
| Elements | You use CityPay-hosted payment fields or components. |
| Direct Post API | Your checkout page posts cardholder data directly from the browser to CityPay. |
| API | Your server handles PAN or sensitive authentication data before sending it to CityPay. |
| Card Holder Account / Token API | You use CityPay tokens or cardholder accounts and need to identify the original capture route. |
| Virtual Terminal | Staff manually enter card details into CityPay's hosted browser-based interface. |
| IVR | Cardholder data is captured through CityPay-hosted IVR in CityPay's CDE. |
When completing an SAQ, describe the actual payment journey and the systems involved. Include:
- the CityPay product used, such as Paylink, Elements, Direct Post API, API, Card Holder Account / Token API, Virtual Terminal or IVR
- whether cardholder data is entered into CityPay-hosted pages, CityPay-hosted fields, a merchant-controlled page, or a merchant server
- whether the merchant website redirects to CityPay, embeds an iframe, hosts CityPay Elements, or submits directly to CityPay
- whether any merchant system can electronically store, process or transmit PAN, card security code, or other sensitive authentication data
- how tokens are created before any later token-based processing
- the controls applied to security-relevant merchant pages, including patching, access control, change control, vulnerability scanning where applicable, and script management
- evidence that CityPay is used as a PCI DSS Level 1 service provider for outsourced payment processing
Example wording for SAQ A:
Cardholder data is collected using CityPay-hosted payment forms/components. The merchant website initiates or embeds the payment journey but does not electronically store, process or transmit cardholder data or sensitive authentication data. Payment capture, authorisation and processing are outsourced to CityPay Limited, a PCI DSS Level 1 service provider.