Can it take payments?

PCI DSS is the card industry's security standard, and it applies to anyone who stores, processes or transmits card data. A recorded call containing a card number is card data.

That is why serious contact centers go to considerable lengths, pausing recordings around payment or using tone-capture so digits never reach the agent or the recording.

A phone assistant that hears a card number and writes it into a transcript has created exactly the artifact the standard exists to prevent.

The card data goes to your payment provider, who is already certified for it, instead of through your phone system.

The customer gets a receipt and a record without anyone reading digits over a noisy line, which also removes a recognition error that costs a failed transaction.

It works after the call ends, so a caller who does not have their card to hand is not stuck. That single detail converts better than pressing them on the phone.

And it is far easier to explain to whoever audits you. A link from a certified provider is a much shorter conversation than a call recording policy.

Say you run a driving school and you take a $50 deposit to hold a lesson. A parent calls at 8pm, and the assistant books Saturday at 11 for her son. Your brief tells it to explain the next step: "We hold the slot with a $50 deposit. You'll get a secure payment link from us by text, and the booking is confirmed once that's paid."

Next morning your office sends the link from the payment tool you already use, and she pays on her phone in under a minute. Her card number went straight to your payment provider's hosted page. It never touched the call, the transcript or your staff.

Suppose she'd started reading her card out anyway. Your brief should cover that with an interruption written in your own words: "Please don't read your card number on this call. We'll send a secure link." Write that line on day one, because some callers will try.

The quiet risk is the transferred call. If a caller is handed to your office manager and she takes a card number over the phone while recording is still running, the audio now holds card data even though the assistant never asked for it. Decide whether staff take cards by phone at all. If they do, find out how recording behaves after a transfer.

Search your existing transcripts once for long digit strings. A run of 15 or 16 digits is almost certainly a card number that a caller volunteered. If you find any, ask about deleting those calls, audio included.

Talk to your payment provider about scope. Hosted payment links and hosted checkout pages usually keep a small merchant in the lightest PCI self-assessment category, because card data never reaches your own systems. Confirm that with the provider instead of taking it from us, since we make no PCI claim of any kind.

If most of your revenue depends on taking cards by voice, such as phone orders at a restaurant, you need a purpose-built payment line, and we're not that.

GreetKeeper does not capture card details on a call and makes no PCI claim. That is the honest position rather than a limitation we are hiding.

Where you need payment, the workable pattern is a link your team sends from your existing provider, prompted by the call summary. We don't claim the assistant texts callers, and that includes payment links.

If a caller starts reading a card number anyway, that is a reason to look carefully at your recording configuration, since the audio and transcript would otherwise capture it.