Telephone Payment Security Buyer's Guide

Don't shortlist on the website — shortlist on the AoC

Every payment security vendor's homepage will tell you they're PCI compliant. That word does a lot of work. What you actually need before anyone gets near your shortlist is a current Attestation of Compliance issued by a Qualified Security Assessor at PCI DSS Level 1. Not a self-assessment, not a marketing PDF, not "compliant components" — a QSA-signed AoC, dated within the last twelve months, naming the exact service you'll be buying. Ask for it on the first call. If a vendor stalls, redirects to a security page, or offers a self-attestation, that's the answer.

Test the demo with a real card

The single most useful thing you can do in a vendor evaluation is take a live test payment yourself. Bring your own card. Get a real agent on a real call (not a sales engineer running a sandbox). Ask three things while you're on the line:

• Can the agent see any digits of the card number on screen as you key them in?
• What happens to the call recording during the card-entry window — is it paused, masked, or running clean?
• If the customer keys an extra digit by mistake, what does the agent's screen actually show?

You'll learn more in five minutes than from a forty-page response document. Secure phone payments done well feel boring on the agent side — the agent stays on the line, talks the customer through it, and never sees or hears card data. If the demo feels like a magic trick, ask why.

Procurement red flags

A short list of things that should kill a vendor on the spot. "Self-attested" PCI compliance — see above. No live DTMF demo and only a recorded video — they're hiding latency, audio glitches, or both. A pause-and-resume product positioned as descoping — it's not, and the QSA on your audit will tell you the same thing. Card data that briefly hits the agent's PC "only for routing" — that's still cardholder data on an agent endpoint. A long sales conversation about how their network is "PCI-grade" without any AoC to back it up.

Things you actually want in a contract

A named QSA on the supplier's audit. A clear scope diagram showing where card data flows, in plain English. A breach notification clause that obligates the vendor to tell you within hours, not days. Penetration test summaries from the last twelve months. SLA language tied to the masked window — agent-side dead air during card entry should be measured and reported.

How the Paytia platform stacks up against the checklist

We're a Level 1 PCI DSS service provider with a current QSA-issued AoC, and we'll send it before the first technical call. Our DTMF masking flattens tones at the carrier before they reach the agent, the recording, or any application — so agents stay on the line, recordings stay continuous, and the agent endpoint never enters scope. We don't sell pause-and-resume; we don't think it descopes anything meaningful. If you want to see exactly what happens during a live masked window, take five minutes with us — how Paytia works walks through the architecture from carrier to gateway. The buyer's guide above is vendor-neutral; this paragraph isn't, and we wanted to be straight about that.

For the full feature set behind these recommendations, see our PCI DSS v4 solution.

Before the shortlist: know which SAQ you're on

Everything above assumes you know what you're buying against. PCI DSS isn't a checklist — what you complete is a Self-Assessment Questionnaire, and which one applies depends on where card data goes. Agents hearing, seeing or keying card numbers puts you on SAQ D. Card data that never reaches your systems puts you on SAQ A, which is a fraction of the work.

Every supplier will say they help with compliance. The question that separates them is whether they remove you from scope or just help you document it. Our free Comply app tells you which SAQ you're actually on before you talk to anyone.

Six more questions worth asking

Does it connect to the acquirer we already use? Changing acquirer as a side-effect of a payments project is an expensive accident. We work with Stripe, PayPal and Braintree, Adyen, Elavon, Lloyds Cardnet, NatWest Tyl, ACI Worldwide, BridgerPay and Acquired.com among others, so most people keep the rates they already negotiated.

What happens when the customer mistypes? Ask about completion rates on real traffic, not demo traffic. A solution that quietly drops failed payments costs more than its licence fee.

What does our carrier need to support? Some approaches need your telephony provider to pass DTMF cleanly or handle SIP trunking a particular way. This is the most common reason a project stalls, and it surfaces during implementation unless you go looking. Bring the telephony team into the evaluation.

Which channels does it cover? Phone is where this starts and rarely where it ends. Payment links, SMS, web chat and QR tend to arrive within a year. A phone-only purchase usually means a second procurement.

How does reconciliation work? Finance needs transactions to match the acquirer's settlement file without spreadsheet work. Dullest question on the list, and the one that determines whether the thing is cheap to own.

How are we charged? Per-agent licensing charges you for growing and for seasonal peaks; per-transaction tracks actual use. Neither is automatically better, but if headcount swings, per-agent will hurt. See choosing your charging model.

Where to go next

If you're still comparing approaches rather than suppliers, our contact centre payments guide sets out the four architectures and what each does to your scope.