Avoiding sensitive data in forms (PCI DSS for payment data)

If your form collects payment information, you are subject to strict security rules whether you realize it or not. The Payment Card Industry Data Security Standard (PCI DSS) sets requirements for anyone who accepts, stores, or processes payment card data. Violating PCI DSS carries fines of thousands of dollars per day, plus the liability if card data is stolen.

The fundamental rule of PCI DSS is simple. Never store raw payment card data yourself. Avoiding sensitive data in forms and using proper payment processors protects your brand, your customers, and keeps you compliant.

What you'll learn: What PCI DSS is and when it applies, what payment data you must never collect, how to structure payment forms safely, how to use payment processors correctly, and what to do if you have already collected sensitive data.

What is PCI DSS?

PCI DSS (Payment Card Industry Data Security Standard) is a set of security standards created by the major credit card companies (Visa, Mastercard, American Express, etc.). It applies to any company that accepts, stores, transmits, or processes credit card information.

PCI DSS applies to you if:

• You run an e-commerce site that accepts credit cards
• You have a form that collects payment information
• You use email invoices with payment instructions
• You store customer payment information for recurring billing
• Any employee has access to payment card data

You may think you are not subject to PCI DSS if you use a payment processor, but you are responsible for how you collect the data before it reaches the processor.

PCI DSS levels and who is required to comply

PCI DSS compliance requirements vary by the volume of transactions you process:

Level 1: Companies processing over 6 million transactions per year. Must be annually audited by an external assessor. Most strict requirements.

Level 2: Companies processing 1 to 6 million transactions per year. Must complete a detailed self-assessment.

Level 3: Companies processing 20,000 to 1 million transactions per year. Must complete a self-assessment.

Level 4: Companies processing under 20,000 transactions per year. Simplest requirements. Most small businesses fall here.

Even Level 4 (small business) has strict requirements. You cannot just take payment card data however you want.

The cardinal rule: never store raw card data

The most important PCI DSS rule: do not collect or store full credit card numbers, expiration dates, or security codes (CVV) in your own database or servers.

NEVER collect:

• Full credit card numbers (PAN: Primary Account Number)
• Expiration dates
• Security codes (CVV/CVC)

NEVER store these even if you encrypt them.

If your form collects this data and you store it yourself, you are violating PCI DSS. The penalties are severe:

• Fines of 5,000 to 100,000 dollars per month of non-compliance
• Liability if card data is stolen and used fraudulently
• Liability for fraud losses and customer notification costs
• Credit card processors may revoke your ability to accept payments

What you CAN collect and store

Some payment-related data is safe to collect:

• Billing name and address: For verification and shipping
• Email address: For receipt and communication
• Last 4 digits of card number: For reference (e.g., "payment method ending in 4242") - but only if you do not collect the full number
• Payment amount and date: For record-keeping
• Transaction ID from the payment processor: For matching and reconciliation

The key: you can store customer information, order information, and reference numbers. You cannot store the actual payment card data.

How to handle payment data safely

Never create a custom payment form

Do not build a form that collects credit card information directly. The moment a payment form sends card data to your server, you are responsible for PCI DSS compliance.

Use a payment processor with hosted payment pages

Payment processors like Stripe, PayPal, Square, and Shopify provide hosted payment pages. These are forms that live on the processor's secure servers, not your servers. When a customer fills out the payment form, the card data goes directly to the processor. Your server never sees the full card number.

Example flow:

1. Customer fills out your order form (name, email, shipping address)
2. Customer clicks "Pay"
3. Browser redirects to the payment processor's secure form
4. Customer enters card information on the processor's form
5. The processor processes the payment and sends you a notification
6. Your form receives only a transaction ID, not the card data

You never handle the card data, so PCI DSS compliance is the processor's responsibility.

Use an iframe for payment

Some processors provide an iframe that you can embed on your form. The iframe is actually hosted on the processor's secure servers, but it appears as part of your page. The customer sees one unified form, but the payment section is actually on the processor's servers.

Use a payment API with tokenization

Advanced payment processors allow you to collect payment information on your form using their JavaScript library. The library encrypts the data on the customer's browser before it reaches your server. It sends you a token (a secure reference) instead of the actual card data. You store the token, not the card.

This requires careful implementation to avoid handling unencrypted card data. Only use if you fully understand the process.

What NOT to do

Do not email payment information. Do not ask customers to send you credit card numbers via email. Email is not encrypted and is not secure.

Do not ask for CVV if you are storing the card. If you are storing a card for recurring payments, you should not ask for or store the CVV. The CVV is only needed at the moment of payment.

Do not collect card data on a regular form and email it to yourself. This sends payment information via unencrypted email, which is a PCI DSS violation.

Do not store card data in a spreadsheet, text file, or database without encryption. If you have already collected card data (which you should not have), you must encrypt it or delete it immediately.

If you have already collected sensitive payment data

If you have a form that has been collecting full credit card numbers or CVVs, stop immediately:

1. Stop collecting the data. Remove card fields from the form immediately.
2. Secure what you have. If you have stored card data, encrypt it or delete it.
3. Switch to a payment processor. Set up a compliant payment method using a third-party processor.
4. Notify affected customers. If you have had a breach, or if customers' card data is still stored, notify them.
5. Consult with legal counsel. If you have been collecting card data unsafely, you may have regulatory exposure. Get legal advice.

Tokenization: the safe way to store payment methods

Tokenization is the process of replacing sensitive payment information with a non-sensitive reference number.

Without tokenization: You store "4532-1234-5678-9010" in your database.

With tokenization: The payment processor stores "4532-1234-5678-9010" and gives you a token like "tok_abc123def456". You store the token.

When you need to charge the card again (for recurring billing), you send the token to the processor. The processor uses the token to retrieve the original card data and process the charge. You never handle the card itself.

Tokens are safe to store. They cannot be used to process payments without the processor's knowledge, and they do not reveal the card number.

PCI DSS requirements beyond payment forms

Even if you use a payment processor correctly, PCI DSS has other requirements:

• Secure your servers. Update software, use firewalls, restrict access.
• Use strong passwords. For your payment processor account and all admin accounts.
• Encrypt data in transit and at rest. Use HTTPS, encrypt databases.
• Monitor and audit. Log access to payment-related systems, review logs regularly.
• Train employees. Anyone with access to payment data needs security training.
• Comply with network security standards. PCI DSS includes 12 major requirements covering access control, monitoring, and incident response.

If you process payments, familiarize yourself with all 12 PCI DSS requirements. Many are beyond just form security.

What WEMASY does for payment security

WEMASY's e-commerce forms do not collect or store raw payment data. When you set up a payment form in WEMASY, it integrates with PCI-compliant payment processors. The payment form redirects to the processor's secure system, or embeds a secure iframe provided by the processor. You never handle card data, and WEMASY never stores it. Your business stays compliant with PCI DSS automatically.

Learn more about how WEMASY handles payments safely in your account settings or on the pricing page.

Frequently asked questions

With WEMASY's <a href="/website-builder" target="_blank">website builder</a>, you can set this up directly on your website.