PCI compliance starts with knowing where payment data goes and who can affect its security. A hosted checkout can reduce your responsibilities, but a processor logo or a completed questionnaire does not establish that your business meets every applicable requirement.
For a high-risk merchant applying for processing, a useful compliance file explains the checkout integration, payment channels, service providers, and evidence already available. Cybin can help organize the processing application; the acquirer and your qualified security adviser determine the validation requirements that apply to your setup.
The PCI DSS dates to keep straight
- PCI DSS v3.2.1 retired on March 31, 2024.
- PCI DSS v4.0 retired on December 31, 2024. Version 4.0.1 was a limited revision, not a new set of additional requirements.
- The future-dated requirements retained their March 31, 2025 effective date. Those dates are not a new deadline for September 2026.
Use the current documents from PCI SSC and confirm the submission schedule with your acquirer. Do not infer a compliance failure solely from the retirement date of an older standard or from the date of a previous assessment.
Choose the SAQ from the complete payment flow
A Self-Assessment Questionnaire, or SAQ, is a validation tool for eligible businesses. Its eligibility conditions matter as much as its questions. Before selecting one, document whether the customer leaves your site, enters payment details inside a provider-hosted frame, or submits data through code or systems you control.
- List every acceptance channel: website, payment links, terminals, telephone orders, and recurring payments.
- Show which provider serves the payment form and where the card data travels.
- Identify website administrators, integrations, support tools, and service providers that can affect payment security.
- Ask the acquirer which SAQ or other assessment it accepts for the complete environment. Record the answer and its assumptions.
A gateway name, JavaScript library, or terminal connection type is insufficient to choose the questionnaire. When evaluating two proposed integrations, ask each provider to explain its specific implementation instructions and what the merchant remains responsible for.
The August 2026 clarification for larger assessments
PCI SSC’s August 2026 revision of FAQ 1331 addresses merchant assessments documented in a Report on Compliance. It says SAQ eligibility should not guide requirement applicability unless the approach is reviewed, discussed, and agreed with the compliance-accepting entity. If your business needs a Report on Compliance, do not shorten the assessment just because the checkout resembles an SAQ A integration. Confirm the approach with the acquirer and assessor.
What changed for SAQ A and payment-page scripts
PCI SSC revised SAQ A in January 2025. Requirements 6.4.3 and 11.6.1, plus the related 12.3.1 targeted risk analysis, were removed from that questionnaire. A script-attack eligibility confirmation was added. This changed SAQ A reporting; it did not mean that payment-page security stopped mattering.
PCI SSC FAQ 1588 distinguishes embedded payment forms from redirects. The script eligibility criterion applies to an embedded provider payment page or form, including an iframe. It does not apply to a full redirect or fully outsourced payment-link flow. All other applicable SAQ A eligibility conditions still need to be met.
For an embedded form, the FAQ describes options including techniques that protect the merchant page, or confirmation from the compliant payment provider that its correctly implemented solution supplies that protection. Retain the relevant implementation instructions and confirmation. An iframe alone is not the evidence.
SAQ A can still require external vulnerability scans
PCI SSC FAQ 1604, updated in June 2026, confirms that SAQ A external vulnerability-scan requirements apply to merchant e-commerce webpages using either redirects or embedded iframes. The scan must use a listed Approved Scanning Vendor’s ASV solution. Do not confuse exemption from the script-attack eligibility criterion with exemption from scanning. Confirm which systems the scan must cover and retain the required results.
Keep an evidence checklist with named owners
Use a short responsibility checklist during onboarding. For each item, record the responsible person, the supporting document, and the next review date. Mark unanswered items as open rather than checking them off because a vendor handles part of the payment flow.
- Payment-flow diagram and inventory of websites, terminals, applications, and providers.
- Written confirmation of the validation route accepted by the acquirer.
- Provider compliance evidence covering the specific service you use, together with shared responsibilities.
- Your applicable assessment, attestation, and any required scan or testing evidence.
- A change-review process for checkout modifications and an incident contact list.
Outsourcing reduces scope; responsibilities remain
PCI SSC FAQ 1092 says merchants that outsource processing still have responsibilities. These include confirming the provider’s compliance for its services, maintaining appropriate written agreements, checking its compliance status at least annually, and understanding shared duties. Confirm your own validation obligations with the organization accepting the assessment.
When a provider changes its checkout product, ask whether the existing evidence still covers it. Keep a dated record of the configuration used for the assessment so future developers do not accidentally replace it with a different integration.
Prepare your processing application with Cybin
Bring your current integration details, available compliance documents, and the acquirer’s instructions to Cybin. We can use that information when discussing processor fit and application requirements. Any unresolved security or assessment question should go to the provider or a qualified assessor before you rely on the answer. Processing approval and PCI validation are separate decisions.