Use a hosted payment gateway (Stripe, PayPal, or Square) instead of a gateway that collects card numbers on your own checkout page. Hosted gateways keep card data off your server entirely, which is what makes PCI compliance manageable for a small store. That single decision determines almost everything else in this guide.
Picking a gateway
WooCommerce supports dozens of payment gateways through official and third-party plugins, but nearly every store narrows down to a few real choices:
- Stripe - the most common default. Direct API integration, supports cards, Apple Pay, Google Pay, and local payment methods depending on region. Checkout can stay on your site (Stripe handles the card fields in an embedded, tokenized form) so the experience feels native.
- PayPal - widely trusted by shoppers, easy setup, and it doubles as a payment method many buyers already have funded. Offers both a redirect flow and an embedded checkout.
- Square - a natural fit if you already use Square for in-person sales and want unified reporting.
All three are hosted or tokenized gateways: the sensitive card data goes straight from the customer's browser to the payment processor, not through your WordPress server or database. That's the model to insist on. Avoid older "direct post" or manual gateways that pass raw card numbers through your own form fields unless you're prepared to take on full PCI scope, which is unrealistic for most small stores.
What actually changes between gateways
- Per-transaction fees (typically a percentage plus a fixed amount per transaction, varies by processor and region).
- Payout speed, some processors settle in 1-2 days, others hold funds longer for new accounts.
- Supported payment methods (buy-now-pay-later options, digital wallets, local bank transfers).
- Chargeback and dispute handling tools.
None of this is hosting-specific. Compare current fee schedules directly on each processor's site before committing, since rates change and vary by country and card type.
What PCI compliance actually requires from you
PCI DSS (Payment Card Industry Data Security Standard) is a set of rules for anyone who handles card data. The scope of what applies to you depends entirely on how much of that data touches your server.
If you use a hosted or tokenized gateway like the ones above, your PCI obligation shrinks to the simplest tier: an annual self-assessment questionnaire (SAQ-A), confirming you don't store, process, or transmit cardholder data yourself. You're not storing card numbers in your WordPress database, not logging them, and not passing them through your own server code. The gateway's iframe or redirect handles the sensitive part.
This is why gateway choice comes first in this article. Pick a plugin that embeds raw card fields directly into your own checkout form and posts them through your server, and you've taken on a much heavier compliance burden (SAQ-D territory) that requires network scans, stricter server hardening, and ongoing audits. Almost no small WooCommerce store needs to be there, and almost none should be.
On the hosting side, running current software matters for general security hygiene even though it isn't a PCI requirement by itself: keep WordPress core, WooCommerce, and your payment gateway plugin updated, and use SSL on your checkout pages. Flashcloud issues free Let's Encrypt SSL automatically once your domain's DNS points to us, so checkout traffic is encrypted without you doing anything extra there.
Don't collect card numbers anywhere outside the gateway's own flow. That includes not emailing yourself order details that contain full card numbers, and not building custom order-note fields where a support agent might paste one in. If a customer sends card details in a contact form or email by mistake, delete the message rather than storing it.
Test mode before you go live
Every major gateway plugin has a sandbox or test mode, a toggle in the gateway's WooCommerce settings that switches API keys from live to test credentials. Run through the full flow before flipping it live:
- Enable test mode in the gateway's settings (WooCommerce > Settings > Payments > click the gateway).
- Place a test order using the processor's published test card numbers (each gateway documents its own set, they don't charge real money).
- Confirm the order status updates correctly, a confirmation email sends, and the order appears in your processor's test dashboard.
- Test a failed payment too, an expired or declined test card, to make sure your checkout shows a clear error instead of a blank failure.
- If you sell internationally, test with a card in a different currency if your gateway supports multi-currency.
Once test orders behave correctly, swap in your live API keys and place one small real order yourself to confirm end to end before opening checkout to customers.
If you're testing on a copy of the site first rather than live production, that's exactly what WordPress staging is for: clone the site, wire up test-mode payments there, verify the whole checkout path, then push the working configuration to your live store.
Before you go live, back up
Changing payment gateways, updating WooCommerce, or switching plugins right before a launch is exactly the kind of change worth protecting against. Take a fresh backup first, see backing up your WordPress site and our backup options for what's already running automatically and how to trigger an on-demand one before a risky change.
When to contact support
Gateway account setup, API keys, and processor-side issues (declined test transactions, payout delays, chargeback disputes) go through the payment processor's own support, not ours. Contact us when the issue is on the hosting side: SSL not issuing on your checkout domain, a WooCommerce or plugin conflict after an update, or server errors during checkout. Open a ticket from Support > New ticket in the portal, or use live chat. Real people handle both.