Redirect
PCIComplianceHubLast updated
A payment integration that sends the cardholder away from the merchant site to a page on the provider domain, where the card data is entered, before returning them afterwards. The merchant page is out of the data path entirely, and no merchant page is open while the card is typed. It is one of the two SAQ A e-commerce integrations, alongside the embedded provider form. Unlike the embedded form, it does not carry the criterion that the merchant confirm its site is not susceptible to script attacks: the Council's FAQ 1588 says that criterion applies only to embedded forms.
Applies to. E-commerce merchants that hand the customer to a compliant provider's page for payment. The Council's glossary names the merchant-side component an E-commerce (web) Redirection Server.
Example. The customer clicks Pay on the merchant site and lands on the provider's domain; after paying they return to the merchant's confirmation page. The merchant's checkout never holds a card field.
Limits. The page that performs the redirect still matters: if it is compromised, the customer can be sent to a look-alike site instead of the provider. That is why SAQ A for v4.x added quarterly ASV scans and scans after significant change (11.3.2 and 11.3.2.1) for redirect and embedded merchants alike (FAQ 1604). The script-attack criterion is the one SAQ A condition a redirect does not carry, but that does not make the redirecting page safe to neglect.
Related. Hosted Payment Page, Iframe (Inline Frame), SAQ A, Direct Post, External Vulnerability Scanning
Sources. PCI DSS v4.0.1 SAQ Instructions and Guidelines, r1, PCI SSC FAQ 1588, How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts? (February 2025), PCI SSC FAQ 1604, Do ASV scans in SAQ A apply to merchants with webpages that redirect to TPSPs or include TPSPs' embedded iframes? (June 2026)