Direct Post API SAQ Guide

This guide is for merchants and integrators using the CityPay Direct Post API, where the customer browser posts cardholder data directly to CityPay from a merchant-controlled checkout page.

Direct Post API is usually SAQ A-EP. Merchant systems may be designed not to receive PAN, but the merchant-controlled payment page collects or influences the submission of payment data and is security-relevant.

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 the CityPay Direct Post API. The merchant checkout page presents the payment form in the customer's browser and submits cardholder data directly from the browser to CityPay. The merchant systems are designed not to store or receive PAN or sensitive authentication data, but the merchant-controlled checkout page can affect payment data collection and submission. Payment processing and authorisation are outsourced to CityPay Limited.

Part 2c - Description of payment card environment

The assessed environment includes the merchant e-commerce checkout pages, scripts, hosting environment, deployment pipeline, administrative access and any supporting systems that can affect the Direct Post API payment form or the browser submission to CityPay. CityPay receives and processes the cardholder data submitted from the customer's browser.

Part 2f - Third-party service providers

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

Eligibility notes

Only rely on SAQ A-EP where the relevant eligibility statements are true. In particular, confirm that:

• account data is not electronically stored by the merchant
• cardholder data is submitted directly from the customer browser to CityPay
• the merchant website cannot expose cardholder data through insecure scripts, code, redirects or unauthorised changes
• CityPay's PCI DSS compliance has been confirmed for the Direct Post API services used

Requirement 1 and 2 - Network and secure configurations

Applies to public-facing merchant systems that host or support the checkout page. Evidence should cover firewall or hosting controls, secure configuration, removal or change of vendor defaults, hardened admin access, and secure CMS/plugin settings.

Requirement 3 - Stored account data

The merchant should not store PAN or sensitive authentication data for this channel. If any account data is retained, confirm whether it changes SAQ eligibility.

Appendix C wording, if true:

The merchant does not electronically store account data or sensitive authentication data for Direct Post API transactions.

Requirement 6 - Secure systems and software

Direct Post API places stronger emphasis on the security of the merchant checkout page. Evidence should cover vulnerability monitoring, critical patching within one month, secure development or change control, script review, and controls over any code that can alter the payment form or submission target.

Requirement 8 - User access

Applies to admin and developer access to systems that can affect the checkout page. Evidence should include unique user IDs, no shared admin accounts, MFA where used, leaver access removal, and periodic access review.

Requirement 11 - Vulnerability scanning and testing

Include quarterly passing ASV scan reports for public-facing in-scope systems, 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 Direct Post API, annual TPSP review, and an incident response plan that includes CityPay, acquirer and payment-brand escalation.

Retain:

• CityPay AOC or PCI DSS compliance confirmation
• Direct Post API integration documentation
• data-flow description showing browser-to-CityPay submission
• checkout page change records
• script inventory or script review evidence
• hosting and web platform patching records
• admin/developer access list and leaver review
• ASV scan reports
• remediation records for findings
• incident response plan
• Appendix C explanations for Not Applicable requirements