Why This One Piece of Paper Matters So Much
Every day, businesses charge credit cards that aren't physically in front of them. A contractor bills a deposit over the phone. A med spa keeps a card on file for no-show fees. A caterer runs the final balance the morning of an event. In every one of those situations, if the cardholder later disputes the charge, one question decides it: can you prove the customer authorized it?
A credit card authorization form is how you answer yes. It's a signed document in which the cardholder gives you explicit permission to charge their card โ either once, for a specific amount, or on an ongoing basis under defined terms. It's not legally required to accept a payment, but without one, a card-not-present chargeback often comes down to your word against the cardholder's. With one, you have signed evidence to submit.
This guide covers when you need one, what a compliant form must include, two complete templates you can copy today (a one time credit card authorization form and an authorization to keep credit card on file), and โ the part most businesses get wrong โ how to handle completed forms without violating PCI rules.
When a Business Needs a Credit Card Authorization Form
You need one any time you charge a card without the cardholder present to tap, dip, or sign at the point of sale. The most common situations:
- Phone and mail orders (MOTO). If you key in cards taken over the phone through a virtual terminal, the transaction is card-not-present and carries higher dispute risk. A signed authorization form is your strongest documentation.
- Card-on-file arrangements. Law firms, medical offices, salons, auto shops, and B2B suppliers often keep a customer's card to charge as work is completed or orders ship. An authorization to keep credit card on file spells out what you're allowed to charge and when.
- Recurring billing and subscriptions. Memberships, retainers, maintenance plans, and installment schedules all involve charging the same card repeatedly. Card network rules for recurring transactions generally expect the cardholder's consent to the amount, frequency, and cancellation terms โ our recurring billing guide covers the operational side in depth.
- Hotel, rental, and event holds. Deposits, incidentals, damage waivers, and no-show or cancellation fees. If you might charge the card days or weeks after the customer signed up, you want their signature on the terms that allow it.
- Third-party payers. A parent paying for a student, a company paying for an employee's travel. The person paying isn't the person receiving the service, so a signed authorization from the actual cardholder is essential.
If you take remote payments today with nothing but a phone call and a keyed transaction, you're carrying dispute risk you don't have to. Businesses that accept payments without a machine should treat the authorization form as standard equipment.
What a Compliant Authorization Form Must Include
A form that will actually help you in a dispute needs these elements:
- Cardholder's name exactly as it appears on the card, plus the billing address and ZIP code tied to the card (used for address verification).
- Card details. Card type, card number, and expiration date. Never include a field for the CVV/security code โ more on why below.
- The business's legal name and the descriptor that will appear on the cardholder's statement, so the charge is recognizable and the customer can't claim they didn't know who billed them.
- The amount โ or the recurrence terms. For a one-time charge: the exact dollar amount and what it pays for. For recurring or card-on-file: the amount or how it will be calculated, the frequency, the start date, and the end date or the words describing when it stops.
- Cancellation terms. How the cardholder revokes the authorization, and how much notice they must give. This matters most for recurring billing, where a clear cancellation path is both a network expectation and your best defense against "I tried to cancel" disputes.
- Signature and date. A physical or e-signature. Undated or unsigned forms are close to worthless in a dispute.
One structural tip: keep the card number and expiration date in a clearly marked section of the form (or on a detachable strip). You'll see why when we get to storage.
Template 1: One-Time Payment Authorization
Below is a generic, original one time credit card authorization form you can adapt. Replace the bracketed items with your business's details, and have your attorney review the final wording before you put it in front of customers โ authorization language can intersect with state consumer-protection and e-signature laws, and a template is a starting point, not legal advice.
[Business Legal Name] โ One-Time Credit Card Payment Authorization
- Cardholder name (as it appears on the card): ______________________
- Billing address: ______________________
- City / State / ZIP: ______________________
- Phone: ______________________ Email: ______________________
- Card type (Visa / Mastercard / Discover / American Express): ______________________
- Card number: ______________________
- Expiration date: ______________________
- Amount to be charged: $______________________
- Description of goods or services: ______________________
- Date the charge will be processed (on or after): ______________________
Authorization language: I, the undersigned cardholder, authorize [Business Legal Name] to charge the card listed above for the single amount stated, for the goods or services described. I confirm that I am the authorized cardholder and that the billing information provided is accurate. I understand this charge will appear on my statement as [Statement Descriptor]. This authorization applies to this transaction only and does not permit any additional charges.
- Cardholder signature: ______________________
- Date: ______________________
Template 2: Recurring / Card-on-File Authorization
Use this version for subscriptions, retainers, payment plans, and keep-on-file arrangements. Same rule applies: adapt it to your business and have your attorney review it.
[Business Legal Name] โ Recurring Payment / Card-on-File Authorization
- Cardholder name (as it appears on the card): ______________________
- Billing address: ______________________
- City / State / ZIP: ______________________
- Phone: ______________________ Email: ______________________
- Card type: ______________________
- Card number: ______________________
- Expiration date: ______________________
- Amount per charge: $__________ (or describe how the amount is determined, e.g., "the balance due on each monthly invoice, not to exceed $__________")
- Billing frequency (weekly / monthly / quarterly / per invoice / per completed service): ______________________
- First charge date: ______________________
- End date (or "until canceled in writing"): ______________________
Authorization language: I, the undersigned cardholder, authorize [Business Legal Name] to keep my card information securely on file and to charge the card listed above according to the amount and schedule described. If a charge is declined, I authorize [Business Legal Name] to retry the charge and agree to provide updated card information. I understand these charges will appear on my statement as [Statement Descriptor]. This authorization remains in effect until the end date above or until I cancel it by providing written notice to [contact email or address] at least [number] days before the next scheduled charge. Cancellation does not relieve me of amounts already owed.
- Cardholder signature: ______________________
- Date: ______________________
In practice, most businesses pair this form with their processor's stored-card vault: the customer signs once, the card is tokenized in the gateway, and the paper (or PDF) never needs to hold the card number long-term. Processors like Payment USA set merchants up with gateways that include tokenization and a built-in card vault, so recurring charges run against a secure token instead of a number sitting in a filing cabinet.
PCI Rules: How to Handle the Completed Form
This is where authorization forms go wrong. The form itself is fine โ what you do with it afterward determines whether you've created a compliance problem. The PCI Security Standards Council's published data-storage guidance is clear on the boundaries:
| Data element | Can you store it? | Conditions |
| Cardholder name | Yes | Must be protected |
| Card number (PAN) | Yes | Must be protected and rendered unreadable where stored |
| Expiration date | Yes | Must be protected |
| CVV / security code | No โ never | Prohibited after authorization, even encrypted |
| PIN | No โ never | Prohibited after authorization |
The practical rules that follow:
- Never put a CVV field on the form. The card verification code is "sensitive authentication data" and must not be retained after the transaction is authorized โ even encrypted, and even if the customer says it's fine. The PCI SSC's FAQ on card-on-file and recurring transactions states directly that a customer's approval to store the code has no validity under PCI DSS. If you need the CVV for the first transaction, take it verbally at the time of the charge and never write it down.
- Don't store the card number unless you truly need to. PCI DSS Requirement 3 only applies to data you store โ the Council's own guidance points out that merchants who store no cardholder data eliminate the biggest target. If your gateway vaults the card as a token, the form doesn't need to keep the number: redact or destroy the card-number section once the card is entered into the vault, and retain the signed terms.
- If you do keep forms with full card numbers, lock them down. Completed paper forms are stored cardholder data. Keep them in a locked, access-controlled location, limit who can access them, keep only what you have a business need for, and destroy them (cross-cut shred) when that need ends. Never store scans of them on unprotected laptops, shared drives, or in email โ PCI guidance specifically warns against sending card numbers through unencrypted email or chat.
- Mask the number anywhere it's displayed. Under the Council's storage guidance, the first six and last four digits are the maximum that may be displayed to people without a specific need to see the full number.
- Know your SAQ implications. How you accept and store card data determines which PCI Self-Assessment Questionnaire applies to you, and storing card numbers on paper or in files generally expands what you must attest to. The specifics depend on your setup, so confirm your SAQ type with your processor or acquirer rather than guessing โ see our PCI compliance guide for small businesses for the basics.
Common Mistakes to Avoid
- Collecting CVV on the form. The single most common violation. Delete the field.
- Vague amounts on recurring authorizations. "I authorize charges as needed" invites disputes. State the amount, the cap, or the calculation method.
- No cancellation terms. If the customer can't tell how to stop the billing, expect chargebacks instead of cancellation requests.
- Emailing completed forms. Customers will email you a filled-in PDF if you let them. Give them a secure upload option, a gateway payment link, or take the details by phone directly into your virtual terminal instead.
- Keeping forms forever. Set a retention period tied to your dispute window and business need, then shred.
- Treating the form as a substitute for good processing. A signed form helps you fight disputes; a processor with proper MOTO support, address verification, and a tokenized vault helps you prevent them. Do both.
An authorization form costs you nothing but a signature, and it can be the difference between winning and losing a chargeback. If you take card-not-present payments regularly, it's also worth knowing what they cost you โ keyed and MOTO rates are where processors hide their worst markups. Send us a recent statement for a free statement review and we'll show you exactly what you're paying and where it can come down.
Sources
- PCI Security Standards Council, "PCI Data Storage Do's and Don'ts" โ https://listings.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf (observed September 2026)
- PCI Security Standards Council FAQ, "Can card verification codes/values be stored for card-on-file or recurring transactions?" โ https://blog.pcisecuritystandards.org/faq-can-cvc-be-stored-for-card-on-file-or-recurring-transactions (observed September 2026)
- PCI Security Standards Council FAQ, "Are merchants allowed to request card-verification codes/values from cardholders?" โ https://www.pcisecuritystandards.org/faqs/are-merchants-allowed-to-request-card-verification-codes-values-from-cardholders/ (observed September 2026)
Frequently Asked Questions
Is a credit card authorization form legally required?
No. You can legally charge a card without one. But for card-not-present transactions โ phone orders, card-on-file, recurring billing โ a signed authorization form is your primary evidence if the cardholder disputes the charge. Without it, chargebacks often come down to your word against theirs.
Can I ask for the CVV security code on an authorization form?
No. The CVV is sensitive authentication data under PCI DSS and must never be stored after authorization, even encrypted, and even with the customer's permission. If you need it for the initial transaction, take it verbally while running the charge and never write it down. Your form should not have a CVV field at all.
How long should I keep completed authorization forms?
Keep the signed authorization terms for as long as the billing relationship lasts plus your dispute window โ many businesses use 18 to 24 months after the final charge. If the form contains the full card number, either redact the number once the card is vaulted with your gateway or store the form in a locked, access-controlled location and shred it when the retention period ends.
Do I still need a signed form if my gateway stores the card as a token?
Yes โ they solve different problems. Tokenization protects the card data; the signed form proves the customer agreed to the charges. The best setup is both: the customer signs the authorization terms, the card goes straight into the gateway's secure vault, and no full card number lives on paper or in your files.
About Payment USAโs Founder
Published by Payment USA, a merchant services provider. Our guides and comparisons reflect that commercial perspective.

Chase James
CEO, Payment USA
Chase James is the founder and CEO of Payment USA, a merchant services company built on transparency and fair pricing. With over 15 years in the payments industry, Chase has helped thousands of businesses uncover hidden processing fees and switch to honest, interchange-plus pricing.
Contact Chase โ