Clover's hosted card fields do not make a WooCommerce store compliant. They move the card number away from your server. Your website, your admin logins and your checkout scripts stay your job. That is the honest shape of woocommerce pci compliance for a small store.
This guide follows the card number from the shopper's browser to Clover's iframe. It shows what that takes off your plate and what it leaves. Our Clover POS integration plugin uses that hosted flow. No plugin can promise your store is compliant, and this guide will not either.
Table of Contents
- What WooCommerce PCI Compliance Asks of a Small Store
- Which Fits Your Checkout, SAQ A or SAQ A-EP?
- What Your WooCommerce Store Still Owns
- Keep an Evidence File and Test the Flow
- Frequently Asked Questions
What WooCommerce PCI Compliance Asks of a Small Store
PCI DSS is the card industry's rulebook. The PCI Security Standards Council (PCI SSC) publishes it. It applies to any business that takes cards. A small store is covered even if it never sees a card number.
What changes is how much you must prove. You prove it with a Self-Assessment Questionnaire, or SAQ. A short one fits a simple setup. A long one fits a store that handles card data itself.
Is WooCommerce PCI compliant if I use Clover?
No one can promise that. A hosted gateway shrinks your scope. It does not remove your duties. "Clover is PCI compliant" describes Clover. It does not describe your WordPress site.
The questionnaire comes from your acquirer, processor or other compliance-accepting entity, as PCI SSC guidance describes. So confirm your SAQ type with your Clover or processor account. In the US and Canada, that means your merchant account provider. For setup and payment details, see our post on the Clover payment gateway for WooCommerce.
Which Fits Your Checkout, SAQ A or SAQ A-EP?
SAQ A fits stores that fully outsource payment handling. Every element of the payment page must come from a compliant third party. PCI SSC says eligibility depends on meeting all criteria, not just one. If any payment-page element comes from your own site, SAQ A may not apply.
SAQ A-EP covers a different case. Your site does not take the card, but your pages can still affect how the card is sent. PCI SSC's FAQ on payment pages explains where that line sits.
How the Clover iframe works
The plugin loads Clover's hosted checkout SDK from checkout.clover.com/sdk.js. The SDK draws the card fields inside an iframe. The shopper types the number into Clover's frame. It goes straight to Clover and never reaches the WordPress server. Clover's documentation describes this tokenization flow, and WooCommerce only receives the result.
A short decision path
Ask how the card is collected:
- Hosted iframe. Clover serves the card fields. This usually points toward the lighter end.
- Redirect. The shopper leaves your site to pay. PCI SSC treats this differently from embedded pages.
- Embedded fields. A third party's fields sit on your page. Script risk on your page matters more here.
- Direct API card submission. Card data passes through your server. This is not the Clover flow, and the burden is much heavier.
Custom checkout code or extra scripts can change the answer. Treat "usually" as a reason to ask, not as an answer.
What Your WooCommerce Store Still Owns
Hosted fields cut card-data risk. The site around them is still yours.
Site basics
- HTTPS on every page, not only checkout.
- Strong, unique admin passwords.
- Multi-factor authentication (MFA) wherever available.
- Few admin accounts, each with the least access needed.
- Updates for WordPress, WooCommerce, your theme and every plugin.
- Removal of plugins you no longer use.
Ask your host what security it handles and what it leaves to you. Do not assume.
The checkout page itself
PCI DSS v4.0.1 pays close attention to scripts on payment pages. PCI SSC says a merchant using an embedded payment page must confirm its site is not open to script attacks. List every script on checkout: analytics, chat, tag managers and heat maps. Approve each one, confirm it is what you expect, and watch for changes.
Pro Tip: A tag manager can load scripts you never reviewed. Treat the container itself as a script that needs approval.
Keeping card data out of the wrong places
A card number should never appear in:
- Order notes and order metadata
- Customer or admin emails
- Support tickets and chat transcripts
- WordPress debug logs
- Webhook payloads
- Analytics events and database tables
If a customer emails a card number, delete it and point them to checkout. Clover's documentation also says ecommerce API requests need an authorization token, and each merchant needs its own. Keep those credentials restricted. Do not import old card numbers either. Clover says card-on-file records need the customer to enter payment details again.
Keep an Evidence File and Test the Flow
An evidence file is a simple folder. Keep these items in it:
- Your processor's written SAQ confirmation
- A note on how checkout loads card fields
- Your script list with approval dates
- Update records
- An admin access list
- The completed SAQ
Test in Clover’s sandbox
Use test mode so no real card data is shared anywhere. Run each step and note the result:
- Authorize a payment.
- Capture it.
- Refund it.
- Run a failed payment.
- Check that WooCommerce creates the order.
- For restaurants, confirm the order prints in the Clover kitchen.
Tokenization protects the card number. It does nothing for menu accuracy, item stock, order routing, refunds or kitchen printing. Those are operations, and they need their own testing. Also check tax and regional checkout settings for your state or province, because custom checkout changes can alter your scope.
Keep security and operations separate
Our WooCommerce sync features cover products, stock, orders and customers, and orders can auto-print in the Clover kitchen. Sync improves accuracy. It does not take over any website-security duty, and it does not change your SAQ. PCI SSC also says a listed product does not guarantee that a merchant has met its own obligations.
Good woocommerce pci compliance rests on the hosted payment flow plus your own controls. If you want payments and sync in one plugin, See CloverWoo pricing. Free setup help comes after purchase.
Frequently Asked Questions
Does the Clover iframe mean I only need SAQ A?
It may point that way. SAQ A depends on every eligibility criterion, including where payment-page elements come from. Confirm the exact type with your Clover or processor account.
Can card numbers or CVV be stored in WooCommerce, logs or order notes?
They should never be. Keep them out of every field, note, log and email. If one appears, delete it and tell the customer to pay at checkout.
Does a PCI-compliant gateway make my hosting and plugins irrelevant?
No. Site security, updates and access control stay with you. A compliant gateway covers its own systems, not your WordPress site.
What happens if I add Google Tag Manager, Meta Pixel or chat scripts to checkout?
Extra scripts on a payment page can change your scope. Review each one and approve it. Then ask your processor whether it affects your questionnaire.