Setting Up Payments on WooCommerce Properly

A gateway here is a plugin, and the account is separate

WooCommerce states it plainly: "A payment gateway, in WooCommerce terms, is a WordPress plugin that enables WooCommerce to connect a customer to a payment processor so that they can pay for goods and services." It adds that all processors require an account, normally called a merchant account, and that each processor has terms and fees separate from the cost of the plugin itself, directing merchants to contact the processor about account requirements, terms and fees. Two things follow. The plugin's price is not the processing price, and the plugin vendor is not the party that can answer a pricing question. Merchants who treat a premium extension purchase as the end of the commercial decision are usually surprised later by the processor's own schedule. Our guide to the difference between a gateway and a processor covers which party owns which part of the transaction.

Redirect or direct is the decision that sets your scope

WooCommerce's documentation frames the security choice as two options. Redirect: "Customer is forwarded to the Payment Gateway site to process payment, then redirected back to your site to complete checkout." Direct: "Customer purchases and pays directly on your site, requiring an SSL certificate as part of PCI Compliance." It notes that most gateways require an SSL certificate to encrypt communications between your site and customers, and between your site and the processor, and that PCI DSS applies to anyone storing, processing or transmitting credit card data. On a self-hosted stack you make this choice deliberately every time you install a plugin, which is exactly the flexibility that gets people into trouble — nobody chooses it for you, and the default is whatever the plugin ships with.

What the PCI Council actually says about embedded forms

The Council describes SAQ A as covering merchants with account data functions completely outsourced to PCI DSS validated and compliant third parties, where the merchant retains only paper reports or receipts with account data, and where the merchant does not store, process or transmit any account data in electronic form on their systems or premises. In January 2025 it removed Requirements 6.4.3 and 11.6.1 for payment page security and Requirement 12.3.1 from SAQ A, and added an eligibility criterion for merchants to confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems. Its FAQ limits that criterion: it "only applies to e-commerce merchants with a webpage that includes a TPSP's/payment processor's embedded payment page/form (for example, one or more inline frame(s) (iframes))" and "does not apply" where the merchant's page redirects the customer to the provider — by HTTP 30x redirect, meta redirect tag or JavaScript redirect — or where payment functions are fully outsourced, for example by emailing the customer a link to pay on the provider's site.

Third-party scripts are the WordPress-specific risk

The reason that criterion exists is a WordPress reality. A self-hosted site accumulates plugins, and every plugin that loads script on the checkout page is a party to the payment page whether anyone intended it or not. An embedded-form checkout therefore carries an obligation to be able to say something defensible about what runs alongside it. A redirect checkout moves the card entry off your page entirely, which is why the Council's criterion does not reach it. Neither option is automatically correct — a redirect costs you checkout continuity, and that is a real conversion question — but the two have different compliance consequences and should be chosen with both in view. Our SAQ comparison sets out which questionnaire each shape of checkout points to.

The settings to fix before launch, and why

Whatever shape you pick, the card rules still apply to what the plugin sends. A merchant must submit an authorisation request for the final transaction amount when that amount is known and it is above the applicable floor limit, and above the floor limit the clearing amount and authorisation amount must match unless the transaction falls into one of Visa's listed exceptions. On a WooCommerce store that means capture behaviour, partial refunds and any post-purchase amount change need testing before launch, not after the first complaint. Visa's Table 5-14 also requires a merchant to submit an authorisation reversal where the final transaction amount is less than the sum of the authorised amounts. Test a decline, a partial refund, a full refund and a stored-card update, and confirm the plugin's webhook handling records all four.

An illustrative example of a setup that passes and one that does not

Illustrative example, made-up round numbers. Two stores install the same processor's extension. Store A uses the redirect flow; its checkout page loads 12 plugin scripts, none of which touch a card field, and it sits outside the Council's script eligibility criterion. Store B uses the embedded-iframe flow on the same page with the same 12 scripts, and now has to be able to confirm the site is not susceptible to attacks from scripts affecting its e-commerce systems. Same processor, same fees, different obligation. Deciding which you want before installing is a ten-minute conversation; discovering it during an assessment is not. This is general information and not legal advice (September 17, 2026); confirm your validation requirements with your acquirer, who sets them.