Data & Security
PCI Compliance for Small Manufacturers, Explained
PCI compliance for small business manufacturers: what PCI DSS asks of you, how hosted card fields shrink your scope, and the yearly steps you still own.
If you take card payments online, PCI DSS applies to you, even when a processor handles the card numbers. The good news: PCI compliance for a small business gets much lighter when card details go straight into your processor's secure fields and never touch your own systems. You still have a short list of yearly tasks. This post is general information, not legal advice: confirm your obligations with your acquirer or processor.
What PCI DSS is and who sets it
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements for anyone who stores, processes or transmits cardholder data. It is maintained by the PCI Security Standards Council.
The Council writes the standard. How each merchant proves compliance is set elsewhere. The Council's page on self-assessment says that whether a small merchant must validate compliance is set by the individual payment brands, and that merchants should ask their acquirer (merchant bank) or payment brand about validation and reporting.
Outsourcing payments does not remove PCI
A common misunderstanding: "Our processor handles cards, so PCI is their problem." The Council's FAQ on merchants who outsource all payment processing says PCI DSS still applies. Merchants remain responsible for confirming their providers are compliant, keeping written agreements about who does what, monitoring the provider's compliance and completing their own validation.
Stripe makes the same point in its integration security guide: PCI compliance is a shared responsibility, and a business accepting payments must do so in a PCI-compliant way and attest to that compliance every year.
How hosted card fields shrink your scope
The amount of work depends on whether card numbers ever reach your systems. Stripe's guide notes that a business handling raw card data directly may need to meet more than 300 security controls. A business that uses a low-risk integration, where card details go straight to the processor, has far fewer obligations.
| Setup | Card numbers touch your systems? | Typical burden |
|---|---|---|
| Staff type card numbers into your own software | Yes | Heavy: full assessment, network controls, audits |
| Your website form posts card data to your server | Yes | Heavy |
| Card fields hosted by the processor, embedded in your checkout | No | Light: short self-assessment questionnaire |
| Customer redirected to a processor-hosted payment page | No | Light |
The short form most online merchants with hosted fields use is a Self-Assessment Questionnaire (SAQ). Stripe states in its security overview that it analyzes each user's integration, tells them which validation form to use, and helps fill in the questionnaire in the Dashboard for integrations built on Stripe Elements or Checkout.
A recent change to know about
In February 2025 the Council published an FAQ on the revised SAQ A eligibility criteria under PCI DSS v4.0.1. For merchants using embedded payment forms (iframes), SAQ A now requires confirming that the site is not susceptible to attacks from scripts that could affect the e-commerce system.
The Council describes two ways to meet that: apply the script protection techniques from the standard's requirements on payment page scripts, or get confirmation from your payment provider that its embedded solution includes protection against script attacks when deployed as instructed. Ask your processor which applies to your setup.
In practice, that means your checkout pages should not load scripts you do not need. Every third-party tag on a payment page is something you have to account for.
PCI compliance for a small business: a yearly checklist
Here is a practical routine. Adjust it with your processor and acquirer.
- Confirm your integration type. Know whether you use hosted fields, a redirect or something else.
- Complete the right SAQ each year, using the form your processor or acquirer points you to.
- Keep proof your providers are compliant. Stripe, for example, states it is certified annually as a PCI Level 1 Service Provider.
- Never collect card numbers by email, phone notes or order forms. A single card number in an inbox brings that inbox into scope.
- Keep payment pages lean. Remove analytics or chat scripts you do not need on checkout pages.
- Limit and review access to your processor dashboard. Use two-factor sign-in for everyone.
- Write down who does what between you, your ordering software and your processor.
Item 4 matters in custom manufacturing. Phone orders and dealer orders often tempt staff to jot down a card. Send a secure payment link or invoice instead.
Where your ordering software fits
Your ordering platform is part of the picture even if it never sees a card. Ask any vendor whether card data ever reaches its servers, whether payments go to your own processor account, and how your other order data is stored. Our posts on payouts to your own Stripe account and isolated customer data cover the rest of those questions.
How Inlay handles this
- Card numbers are entered in Stripe's secure fields and never touch Inlay's servers.
- Stripe is a PCI DSS Level 1 certified provider, and payments run through your own Stripe account via Stripe Connect.
- Dealer invoices on net terms are sent through your Stripe account, so staff do not need to take card numbers by phone or email.
- Order data sits in a separate encrypted database per company, with AES-256 at rest and TLS 1.2 or higher in transit.
This post is general information, not legal advice. Confirm your PCI validation requirements with your acquirer or payment processor.
Book a 20-minute demo to see how payment fields sit inside a branded checkout.