Card authorization forms and PCI: what advisors can and cannot do

Almost every trip an advisor books eventually needs a client's card number to sit on a supplier portal or a phone call with a hotel or DMC. That single, routine need creates a real compliance obligation, because a card number, expiry date and CVV together are regulated data under the Payment Card Industry Data Security Standard (PCI DSS), whether or not the person handling them thinks of themselves as a payments business.

Most advisors are not trying to be careless with card data. They simply have not been told, clearly, what is and is not acceptable. The gap between what feels convenient and what is compliant is exactly where problems happen.

What you should never do with a card number

• Never accept a card number by email, even "just this once". Email is not encrypted end to end, sits in inboxes indefinitely, and is routinely the source of card data breaches for small businesses.
• Never accept one by text message, for the same reason, plus the fact that most phones back messages up to the cloud with no controls over who can later access that backup.
• Never write a card number down on paper, a sticky note, or in a personal notes app. Any physical or unmanaged digital record is a liability the moment it exists.
• Never store a card number in a spreadsheet, CRM note field, or document that is not a PCI-compliant vault, even temporarily, even if you intend to delete it right after.

The common thread: any channel that was not built to handle card data securely should never be asked to. That includes channels that feel private, like a direct message or a personal phone call where you write the number down to key in later.

What a compliant process actually looks like

A card authorization form is the standard, compliant way to collect what you need. Done properly, the client enters their own card details directly into a secure, PCI-compliant form, never dictating the number to you over the phone or typing it into an email, and the form captures, separately from the card data itself, the specific things the authorization actually covers: the amount or amount range being authorised, what it is for (a specific booking, a deposit, a balance payment), the merchant or supplier who will process the charge, and the client's signature or explicit consent to that specific use.

This distinction matters: the authorization document itself, the terms, the amount, the signature, is not sensitive card data and can live in your normal records. The card number, expiry and CVV need to live only in the secure vault the form feeds into, never copied out of it into anything else.

Tokenisation and vaulting, in plain terms

Tokenisation replaces a real card number with a random reference, a token, that is useless to anyone who does not control the vault that issued it. When a payment processor tokenises a card, the merchant (in this case, the advisor) generally cannot reverse the token back into the actual card number. That is by design: it protects the client and it protects you from being the point of failure if your systems are ever compromised.

The complication for travel advisors specifically is that a lot of supplier booking still happens on portals or over the phone that want the real card number, not a token: a travel-specific gap that general payment processors were not built to solve. A few approaches exist. Some platforms let the advisor view the full card number and CVV for a limited window after authorization: a published example is a five-minute secure reveal session, available for a limited period such as 30 days after the client authorises it. This approach balances the practical need to key a number into a supplier portal against the risk of that number sitting around indefinitely. Others avoid exposing the real number at all by issuing a virtual card through the payment processor, funded for the specific booking amount, which the advisor keys into the supplier instead of the client's actual card. Dedicated vaulting providers with reveal capability are a further option, though they carry their own monthly cost, with published pricing for this category generally starting somewhere around $750 to $1,000 a month, a cost that only makes sense once card handling is a high enough volume to justify it.

What PCI compliance means for a small advisory business

Full PCI DSS compliance is a real undertaking that most solo advisors and small agencies are not equipped to take on directly: it involves security controls, audits and attestations that make sense for a payments business, not an advisor who happens to need a card number a few dozen times a month. The practical path almost everyone takes is to use a processor or platform that is already PCI DSS attested, commonly Level 1, the strictest tier, and to never let card data touch anything outside that processor's systems. Done this way, the compliance burden sits with the processor, and your obligation is narrower: use their compliant form, never re-key or store the data yourself, and purge anything you are allowed to hold (the CVV in particular) as soon as it has served its purpose.

The bottom line

If a card number ever passes through your own hands, whether typed by you, read to you, or stored by you outside a compliant vault, something in the process is wrong, regardless of how well intentioned it was. The fix is not more caution with an insecure channel. It is routing card collection through a form built for it, every time, with no exceptions for a client who finds it inconvenient.

WaypointsX collects card authorizations through a compliant, tokenised form built into the client portal, with the authorization terms and signature stored on the trip and the card data itself never touching your inbox or your own records. See how it works on the payments page.