Direct Post
PCIComplianceHubLast updated
An integration in which the payment form is served from the merchant origin but submits card data straight to the provider, bypassing the merchant server. Because the data never lands on merchant infrastructure this is often mistaken for full outsourcing. It is not: the merchant controls the page and the form, so anything that alters that page can change where the post goes. Direct post is an SAQ A-EP integration, not SAQ A.
Applies to. Merchants whose own website creates the payment form and whose form sends card data from the browser straight to the provider.
Example. The merchant's checkout serves a form with card fields whose submission goes to the provider's API, so the values never reach the merchant's server. The merchant receives a token afterwards.
Limits. Because the merchant serves the form, anything that can change the page can change where the data goes. It is therefore an SAQ A-EP integration, at 139 requirements against SAQ A's 27, and the page is subject to 6.4.3 and 11.6.1 in full. A form assembled by a script the merchant page loads is the second pattern in the Council's A-EP examples; check which side of that line a provider's 'hosted fields' fall before assuming SAQ A.