Two completely different requests share the phrase credit card payment form, and the answer to one is dangerous applied to the other.
The first is a form that takes a payment now: the customer types a card number, money moves, the transaction is done. The second is a card authorisation form, which records permission to charge a card later, often on paper or as a PDF, and is common in professional services, accounting practices, clinics and recurring billing arrangements. The first is a payments integration problem. The second is a records problem, and it is the one where organisations most often build something that quietly puts them in breach.
The line between them is not the purpose. It is whether the card number comes to rest anywhere you control.
What the standard covers, in its own words
The Payment Card Industry Data Security Standard is described by the PCI Security Standards Council as applying to entities that store, process, or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. That last clause is broader than most people expect. The council's definition of the cardholder data environment includes not only the systems, people and processes that touch card data, but also system components that never touch it and have unrestricted connectivity to ones that do.
The distinction between the two data categories is the practical one. The council's glossary defines cardholder data as, at a minimum, the full primary account number plus any of cardholder name, expiration date or service code. Sensitive authentication data is the separate category covering additional elements that might be transmitted or processed, but not stored, as part of a payment transaction. The security code printed on the card sits there. So does magnetic stripe and chip data, and the PIN.
Read the parenthesis again, because it is the whole rule in three words: but not stored. A form that captures the security code and emails it, or writes it into a spreadsheet, or keeps it in a submissions database, has retained something the standard says is only ever in transit.
Whether any given organisation must formally validate compliance is a separate question. The council states that this is at the discretion of the organisations that manage compliance programmes, such as a payment brand or an acquirer. That is not a loophole. It means the requirement to protect the data stands regardless, and the paperwork you owe depends on who you process through and how much.
Why a general form tool is the wrong container
Stripe's integration security guidance puts a number on the cost of handling card data directly: a business that takes untokenised card numbers on its own payment page may be required to meet more than 300 security controls. The standard's own documentation set runs past 1,800 pages, with more than 300 of those pages devoted only to the forms used to validate compliance.
The reason this lands so hard on form builders is the connectivity clause. A form is never just a form. A submission arrives, and then it is stored in the tool's database, copied into a notification email, delivered to one or more inboxes, downloaded in an export, indexed for search, and swept into whatever backups the vendor runs. Every one of those becomes part of the environment that has to be protected, including the mailboxes of the people who received the notification.
That is why a card number in a general purpose form is worse than it first looks. The number does not stay in one place; it fans out into systems that were never designed to be assessed, and it does so within seconds of submission.
When a card number has already arrived
This happens without anybody asking for it. A customer types their card number into the free text box of an enquiry form because it seemed helpful, or pastes it into a reply, and now it is sitting in a submissions list and in however many inboxes received the notification.
The instinct is to forward it to whoever handles billing. That is the one thing not to do, because forwarding multiplies the copies and puts the number into a thread that will be replied to, quoted and archived.
A workable sequence is short. Take the payment by the correct route first, using a hosted page or link, so the customer is not left waiting while the cleanup happens. Then delete the submission from the form tool, including any trash or archive the tool keeps, and delete the notification from every mailbox that received it, sent items and deleted items included. Tell the customer plainly that the details were not retained and give them the link for next time. Finally, remove the free text box that invited it, or add a line under it saying not to enter card details, because the same thing will happen again otherwise.
What you can collect and keep
There is a well defined set of card details that sit outside scope, and knowing it removes most of the temptation to collect the rest.
Stripe's guidance states directly that the non sensitive card information returned with a charge, specifically the card type, the last four digits of the card and the expiration date, is not subject to PCI compliance and can be stored in your own database. That trio is enough for almost every operational purpose a form was collecting a card number for in the first place: telling two saved cards apart, letting a customer confirm which card was used, and matching a payment to an enquiry.
Alongside that, the things a form is well suited to holding are the ones the payment does not involve. The billing name and address. The purchase order or reference number. The signature or ticked acceptance of the terms, with a timestamp. The amount and the frequency that were agreed. A token or customer reference issued by the payment processor, which stands in for the card without being it.
What that leaves out is the number itself and the security code. Not "store them carefully". Leave them out of the form.
The routes that keep the number out of your systems
The established pattern is to have the card fields belong to the payment provider rather than to your page, so the number travels from the customer to the processor without passing through anything of yours.
Stripe's documentation describes how this affects the paperwork. With Checkout or Elements, every card data input is hosted inside an iframe served from Stripe's domain rather than yours, so the customer's card details never touch your server, and the applicable self assessment questionnaire is SAQ A. Where card data is entered into a form hosted on your own site and transmitted with the older Stripe.js v2, the applicable document is SAQ A-EP, a substantially longer assessment. In person card presence through Terminal maps to SAQ C. Stripe itself is certified annually by an independent Qualified Security Assessor as a PCI Level 1 Service Provider.
If even an embedded field is more integration than the situation needs, a hosted link is the smallest possible version. Stripe's Payment Links are created without code and render a Stripe hosted page supporting more than 40 payment methods, with language matched to the customer's browser from over 30 options, automatic receipts and refunds handled from the dashboard. The intake form collects the enquiry, and a link handles the money.
One requirement applies to any of these routes: payment pages must use TLS 1.2 or above, and every resource on the page, including scripts, stylesheets and images, must be served the same way.
Where the number is typed decides the paperwork
| Where the card number is entered | Whose systems see it | Typical self assessment |
|---|---|---|
| Provider hosted page or payment link | The provider only | SAQ A |
| Provider iframe embedded in your page | The provider only | SAQ A |
| A form on your own site, transmitted by your code | Yours, then the provider | SAQ A-EP |
| A general form tool, stored and emailed | Yours, your vendor's, your mailboxes | Full scope assessment |
| Card present reader | The reader and the provider | SAQ C |
Merchant level, which sets what evidence is required, is driven by volume. Stripe's compliance guide sets out four levels: Level 1 is more than six million Visa or Mastercard transactions a year, or 2.5 million American Express, or any organisation that has had a breach, or one a card brand has designated; Level 2 is one to six million; Level 3 is 20,000 to one million online transactions; Level 4 is under 20,000 online. A Level 1 merchant cannot validate with a self assessment questionnaire at all and needs an annual report on compliance. Volume decides how much proof you owe. Integration choice decides how hard that proof is to produce.
The authorisation form, without the card number
Which brings us back to the second reading of the phrase, the one the template sites are answering. An organisation wants written, signed permission to charge a card on an agreed schedule, and every downloadable template it finds has a box for the full number and often one for the security code.
The same outcome is available without either. Have the customer complete the authorisation form with their name, billing address, the amount, the frequency, the end date and their signature, and have the card itself saved through the provider's hosted flow, which returns a token. The signed form references the token and the last four digits. The agreement is documented, the card is charged on schedule, and no part of your filing system contains a number worth stealing.
This also fixes the quieter problem with paper authorisation forms, which is retention. A scanned form in a shared drive persists long after the arrangement ends, gets copied when somebody reorganises folders, and is read by people who joined years later. A token in a payment provider can be revoked. A PDF cannot be un-copied.
Two decisions belong to the intake side rather than the payments side, and they are worth settling explicitly: who owns each authorisation once it arrives, and what status it carries between received and set up. Both are the same questions that apply to any submission that needs a human to act, which is what a response with an owner and a status is for. Sector examples of intake that continues after submission are collected under the situations forms get used for.
None of this is formal advice. Stripe attaches the same caveat to its own guide, recommending a Qualified Security Assessor for specifics, and your acquirer determines what you actually have to file.
What to change first
Open the form and delete the card number and security code fields, then replace them with a link to a provider hosted payment page, which is the change that moves the number out of every system you run. Keep the brand, the last four digits and the expiry if you need them for reconciliation, since those sit outside scope. Then decide who owns an arriving authorisation and what status it carries, which is the part Halict exists to handle.
Q1. Can a credit card number be collected in a normal online form?
It should not be. The moment a submission containing a card number is stored, emailed or exported, the form tool, the mailboxes that received the notification and the vendor's backups all fall inside the environment that has to be protected. The established alternative is a provider hosted payment page or an iframe, where the number goes from the customer to the processor without passing through anything of yours.
Q2. Which card details are safe to store?
Card type, the last four digits and the expiration date are described as non sensitive information that is not subject to PCI compliance and can be kept in your own database. That combination covers most operational needs, such as telling two saved cards apart or matching a payment to an enquiry.
Q3. Is it acceptable to store the security code if it is encrypted?
No. The security code is classified as sensitive authentication data, defined as elements that may be transmitted or processed but not stored as part of a payment transaction. Encryption does not change the classification, which is why authorisation form templates with a box for the code should not be used as printed.
Q4. How do I take recurring payments without keeping the card on file?
Save the card through the payment provider's hosted flow, which returns a token that represents it, and keep the token rather than the number. The signed authorisation then references the token and the last four digits, the charges run on schedule, and revoking the token ends the arrangement in one place.
Q5. How much compliance paperwork does a small business actually owe?
It depends on volume and on integration. Merchant levels run from under 20,000 online transactions a year up to more than six million, and the self assessment questionnaire is determined by where the card number is entered: a provider hosted page or iframe maps to the shortest one, while a form on your own site maps to a substantially longer version. Your acquirer confirms what must be filed.