Paylink SAQ Guide

This guide is for merchants and integrators using CityPay Paylink as a hosted payment form, either by redirecting the customer to Paylink or embedding Paylink in an iframe.

Paylink usually supports SAQ A where cardholder data is entered only into CityPay-hosted payment pages or forms, and the merchant's own systems do not electronically store, process or transmit PAN or sensitive authentication data.

Part 2a - Merchant business payment channels

Tick:

E-Commerce

Do not include card-present unless that channel is separately assessed.

Part 2b - Description of role with payment cards

The merchant accepts e-commerce card-not-present transactions using CityPay Paylink. Cardholder data is entered into a payment form hosted by CityPay. The merchant website creates or initiates the Paylink payment journey but does not store, process, or transmit cardholder data or sensitive authentication data electronically. Payment processing, authorisation and handling of account data are outsourced to CityPay Limited.

Part 2c - Description of payment card environment

The assessed environment consists of the merchant e-commerce website pages and systems used to create, link to, redirect to, or embed CityPay Paylink payment sessions. The merchant website does not receive PAN, CVV, track data, or other sensitive authentication data. CityPay provides the hosted payment form that collects and processes cardholder data.

For iframe integrations, include:

Where Paylink is embedded in an iframe, the merchant page that hosts the iframe is treated as security-relevant because it can affect the payment journey. The merchant maintains controls over secure configuration, patching, access control, change control, vulnerability scanning where applicable, and script management for that page.

Part 2f - Third-party service providers

Service providerDescription
CityPay LimitedCityPay PSP and TPSP operating its own gateway, providing Paylink hosted payment forms, payment data capture, authorisation, processing and related payment services.

Also list hosting providers, CDN providers, web developers or other third parties if they can affect the checkout or payment page.

Part 2h - Eligibility to complete SAQ A

Only tick eligibility statements that are true:

  • the assessed channel accepts only card-not-present transactions
  • all account-data processing is outsourced to CityPay Limited or another compliant TPSP
  • no electronic storage, processing or transmission of account data occurs on merchant systems
  • CityPay's PCI DSS compliance has been confirmed for the Paylink services used
  • all payment form elements delivered to the browser originate directly from CityPay
  • the merchant has assessed relevant website pages against script-based attacks

Redirect

In a redirect integration, the customer is sent from the merchant website to the CityPay-hosted Paylink payment form. The merchant site should not collect cardholder data before redirecting the customer to CityPay.

The merchant page that creates or links to the Paylink session should still be protected against unauthorised changes, especially where an attacker could alter the destination, order details, scripts, or payment journey.

Iframe

When Paylink is embedded in an iframe, the merchant page that hosts the iframe can affect the payment journey and should be treated as security-relevant. Merchants should maintain secure configuration, patching, access control, change control, vulnerability scanning where applicable, and script-management controls for that page.

Requirement 2 - Secure configurations

Applies to merchant systems and pages that create, link to, redirect to, or embed Paylink. For iframe integrations, include the iframe host page and any CMS, tag manager or deployment path that can modify it.

Requirement 3 - Stored account data

Usually not applicable if the merchant does not print or store paper records containing account data.

Appendix C wording:

The merchant does not store paper records containing account data for CityPay Paylink transactions.

Requirement 6 - Secure systems and software

Evidence should cover vulnerability monitoring, critical patching within one month, change control for payment journey pages, and review of scripts on pages that link to or embed Paylink.

Requirement 8 - User access

Applies to admin access to merchant systems that can affect the Paylink integration. Evidence should include unique user IDs, no shared admin accounts, leaver access removal, MFA where used, and password standards.

Requirement 9 - Physical access to cardholder data

Usually not applicable unless the merchant stores paper receipts or reports containing account data.

Appendix C wording:

The merchant does not store, distribute, or destroy paper media containing account data for this payment channel.

Requirement 11 - Vulnerability scanning

Include quarterly passing ASV scan reports for public-facing in-scope systems where applicable, scans after significant changes, and remediation records for findings.

Requirement 12 - TPSP management and incident response

Maintain a TPSP list including CityPay Limited, written agreement or terms with CityPay, evidence of CityPay PCI DSS compliance for Paylink, annual TPSP review, and an incident response plan that includes CityPay, acquirer and payment-brand escalation.

Retain:

  • CityPay AOC or PCI DSS compliance confirmation
  • Paylink integration documentation
  • TPSP list and annual review
  • hosting and web platform patching records
  • admin access list and leaver review
  • ASV scan reports where applicable
  • change records for pages that create, link to, redirect to, or embed Paylink
  • iframe host page script/change review where iframe is used
  • incident response plan
  • Appendix C explanations for Not Applicable requirements