Never Collect Card Numbers in a WordPress Authorization Form

A credit card authorization form should not store a card number, expiration date, or CVV inside WordPress. Collect the customer’s authorization and transaction details in your form, but let a PCI-compliant payment provider collect the card data.

This split gives the business the written approval it needs without turning every WordPress backup, administrator account, CSV export, and email notification into a payment-data risk.

Why the traditional authorization form is dangerous

The paper form pattern is familiar: cardholder name, card number, expiration date, CVV, billing address, amount, and signature. Copying that layout into an HTML form looks straightforward. It is not.

Once the visitor types card data into ordinary WordPress inputs, the data may reach:

• the Core Forms submissions table;
• notification emails;
• database backups;
• server logs;
• analytics or session-recording tools;
• webhook and CRM payloads;
• CSV exports downloaded to staff laptops.

Deleting the submission later does not remove all those copies.

The PCI Security Standards Council classifies CVV, CVC, CID, and similar card verification values as sensitive authentication data. Its card-verification-code guidance says they cannot be stored after authorization, even when encrypted. A generic WordPress form field cannot enforce that boundary across every copy.

Split authorization from payment

Use two connected records.

The WordPress form collects:

• customer and company name;
• invoice, booking, or estimate reference;
• approved amount or maximum amount;
• description of the goods or service;
• one-time or recurring authorization;
• cancellation terms;
• typed acknowledgement or separate signature workflow;
• email and billing contact.

The payment provider collects:

• primary account number;
• expiration date;
• CVV or CVC;
• 3D Secure authentication;
• payment-method token.

Core Forms’ payments documentation supports Stripe Checkout, Stripe Payment Element, PayPal, Razorpay, and Polar. Hosted checkout sends the visitor to the provider. Stripe’s inline Payment Element stays on the page, but Stripe.js owns the card fields so raw card data does not become an ordinary form submission.

A safer WordPress workflow

Create the authorization and payment as one stateful process:

1. The customer completes the service and authorization fields.
2. Core Forms validates the request and saves a pending_payment submission.
3. The provider checkout or Payment Element collects the payment method.
4. The provider sends a signed webhook.
5. Core Forms verifies the webhook and marks the submission paid.
6. Email, webhook, CRM, and fulfillment actions run after payment confirmation.

The WordPress payment form workflow explains why a browser redirect cannot prove payment. The provider’s signed webhook is the authority.

Never trust a price from the browser

A hidden field such as <input name="amount" value="500"> is not protected. A visitor can change it before submission.

Core Forms’ Stripe product picker sends only the selected product index. The server resolves the amount from saved form settings. For calculated quotes, use calculated fields for the visible estimate, then recheck the trusted amount on the server before creating the charge.

That rule also applies to:

• deposit percentages;
• quantity discounts;
• taxes;
• coupon limits;
• membership renewals;
• maximum authorized amounts.

The browser can describe the customer’s choice. It cannot be the authority for what the business charges.

What the authorization copy should say

The wording depends on the transaction and jurisdiction, so get legal review for recurring charges, delayed charges, cancellation fees, and high-value work.

At minimum, make these facts visible:

• merchant legal name and contact information;
• exact amount or calculation rule;
• whether the charge is one-time or recurring;
• timing of the charge;
• cancellation and refund terms;
• how the customer can revoke authorization;
• what evidence the customer will receive.

Do not hide payment terms inside a general privacy-policy checkbox. The customer should understand the charge before submitting.

Build it with Core Forms

Start with a payment-ready form from Templates. Add the authorization fields in the visual builder or code editor, then configure the provider under the Payment tab.

Use:

• conditional logic for one-time versus recurring terms;
• Email actions for the merchant record;
• Autoresponder actions for the customer’s copy;
• submissions for status and payment references;
• webhook signatures when sending confirmed data to another system.

Do not include [all:label] in a payment email until you have confirmed the form contains no raw card fields. Better yet, never create those fields.

FAQ

Can I store a credit card number in WordPress if it is encrypted?

Encryption does not remove PCI DSS obligations, backup exposure, access-control requirements, or the ban on storing card verification values after authorization. Use provider-owned card fields instead.

Can Core Forms collect card payments without storing card numbers?

Yes. It supports hosted checkout with Stripe, PayPal, Razorpay, and Polar, plus Stripe’s inline Payment Element. Raw card details stay with the provider.

Is a typed name a legal signature?

That depends on the agreement and jurisdiction. A typed acknowledgement can record consent, but legal enforceability and required evidence need qualified legal advice.

Should payment actions run as soon as the form submits?

No. For payment-required forms, Core Forms keeps the submission pending and runs success actions after the provider’s signed webhook confirms payment.

Can I email the completed authorization form?

Email only the non-card authorization details needed by the merchant and customer. Never email raw card numbers or CVV values.