Yes. A customer can read you a card number, or authorise a direct debit verbally, or pay a link you send while you're still on the call. The compliance weight falls on the first of those, because accepting a spoken card number pulls your people, your phones and the systems behind them into PCI DSS scope.
The short version
- Taking a card number by phone is a normal, permitted way to accept payment, sometimes called a mail order or telephone order transaction.
- "Accepting spoken account data over the telephone puts personnel, the technology used, and the infrastructure to which that technology is connected into scope of PCI DSS", according to the PCI Security Standards Council.
- Writing the number on a pad counts as storage, and so does capturing it on an answering machine.
- Security codes must not survive authorisation, in any form, including a call recording.
- Strong customer authentication is triggered by an electronic payment transaction, and no UK regulator page we could fetch settles how a phone-read card number is treated, so ask your acquirer.
- You can take a direct debit instruction over the phone, if your provider is set up for paperless mandates.
The three ways a phone payment can work
Your customer rings to settle an invoice, and you've got three routes with very different amounts of compliance work behind them. They read you a card number and you key it into a virtual terminal. They give you a verbal direct debit instruction, permitted by Bacs through paperless direct debit, "for example over the telephone, Internet, telephone keypad, face-to-face or by interactive TV". Or you send a payment link during the call and they pay it themselves while you stay on the line.
What a spoken card number does to your PCI scope
If you take card details, PCI DSS applies to you, and the phone route has a scope problem people underestimate. The PCI Security Standards Council's guidance on telephone payments states that "Accepting spoken account data over the telephone puts personnel, the technology used, and the infrastructure to which that technology is connected into scope of PCI DSS".
Two everyday habits widen that scope. On a simple phone setup, the guidance says that "should the entity use an answering machine to capture customer account data or the person answering the call writes down the account data, then the collection of account data in the scenario would be considered 'storage,' and the entity's processes and environment would be considered in scope for PCI DSS". So the pad by the phone is not a workaround: it turns a transient conversation into stored account data, along with everything around it.
Where card details do reach paper: "If account data is ever written or printed on paper, ensure it is securely stored, then shredded when no longer needed."
One caveat. That document is an information supplement, version 3.0, dated November 2018, and a supplement is guidance and not the standard itself. Your acquirer or a qualified assessor decides which questionnaire and which requirements apply to you.
Recording the call, and the security code
Call recording is where phone payments most often go wrong, because a recording keeps the one piece of data that isn't allowed to survive.
The Council's FAQ on audio recordings, dated June 2025, says that under PCI DSS Requirement 3.3.1 the "storage of sensitive authentication data (SAD), including card validation codes and values, after authorization" is prohibited even when encrypted, and that this reaches digital audio recordings. Its expectations, in order: make every effort to prevent the data being recorded; enable any technology you have that suppresses audio while the code is read out; and where sensitive data does get recorded, delete it securely as soon as authorisation completes. Where immediate deletion isn't feasible, you're into compensating controls with a risk assessment behind them.
The FAQ also notes that PCI DSS doesn't override local laws on retaining audio, so if your professional body requires you to keep recordings, you'll need to reconcile that obligation with this one.
Two technical answers exist, and they're not equivalent:
| Approach | What the guidance says it does |
|---|---|
| DTMF masking, where the customer keys the number into their handset and the tones are flattened | Can take "not only the telephony environment, but also the agent environment and CRM system out of scope" |
| Pause and resume, where recording stops while the number is read out | Does "not reduce PCI DSS applicability to the agent, the agent desktop environment, or any other systems in the telephone environment" |
Pause and resume solves the recording problem and leaves the scope problem where it was, so it helps to know which one you're buying.
Strong customer authentication, and an honest gap
Strong customer authentication is the reason an online card payment sends you into your banking app. Regulation 100 of the Payment Services Regulations 2017 requires a provider to apply it where a payment service user "accesses its payment account online", "initiates an electronic payment transaction", or "carries out any action through a remote channel which may imply a risk of payment fraud or other abuses", subject to exemptions in technical standards.
The FCA's page on strong customer authentication repeats those three triggers and doesn't address mail order or telephone order transactions either way. We couldn't settle from any UK regulator page whether a card number read to you over the phone counts as an electronic payment transaction the payer initiated, and that classification decides whether authentication is required.
So the useful step is a practical one. Your acquirer configures how these transactions are submitted and will tell you how it treats them and where fraud liability lands without an authentication step. Ask before you start taking numbers by phone, not after your first disputed payment.
Taking a direct debit instruction by phone
A verbal mandate is a genuine option, with conditions. Bacs limits paperless direct debit to organisations using the AUDDIS service "who can satisfy additional criteria", puts the verification job on you ("It is the organisation's responsibility to verify the customer and validate their details, for example: identity, account details, customer address"), and requires that "You must then send confirmation to the customer within three working days of their verbal or internet instruction".
For a recurring fee that often works out better than taking a card number, since you set the collection up once instead of handling account data on every call. Our guides to mandates and to collecting without your own Service User Number cover what your provider needs in place.
The version that avoids most of this
The quietest option is to stay on the call and send a payment link, so your customer pays by card, wallet or bank while you're talking. They authenticate in their own app, you watch the payment land, and no card number is spoken, keyed by you or written anywhere.
Our reading, and it's reasoning and not a quoted rule: the scope question doesn't disappear, it moves to your provider, whose environment handles the card data instead of yours. Your own obligations still depend on how your setup is assessed.
Adfin's payment links carry card, Apple Pay, Google Pay, open banking and bank transfer, which is enough to finish a call that started with "how do I pay this?". Whoever you use, the test is whether your customer can pay during the conversation.
Common questions
Is it legal to take card payments over the phone in the UK? Yes. Telephone card payments are an ordinary way to accept money. What applies to you is the card industry's data security standard and your acquirer's own conditions, and no prohibition.
Can I write down a customer's card details during a call? You can, but it changes your position. PCI guidance treats writing account data down, or capturing it on an answering machine, as storage, which brings your processes and environment into scope, and any paper has to be secured and then shredded.
Can we record calls where customers give card details? Only with the security code kept out of the recording. PCI DSS Requirement 3.3.1 prohibits storing sensitive authentication data after authorisation, encrypted or not, and the Council applies that to digital audio, so suppress the audio during entry or delete it securely once authorisation completes.
Does strong customer authentication apply to phone payments? Regulation 100 triggers authentication on an electronic payment transaction, on online account access, and on remote actions implying fraud risk. Whether a card number read out by phone falls inside that isn't settled by any UK regulator page we could fetch, so confirm the treatment and the liability position with your acquirer.
Can a customer set up a direct debit over the phone? Yes, where your provider offers paperless direct debit. Bacs allows sign-up by telephone, requires the organisation to verify the customer's identity and account details, and requires written confirmation to the customer within three working days.
What's the simplest way to take an invoice payment during a call? Send a payment link while you're on the line and let your customer pay it themselves. They authenticate in their own banking app or wallet, and no card number is read aloud, keyed by you or written down.
Sources
- legislation.gov.uk — Payment Services Regulations 2017, regulation 100 (accurate as of August 2026)
- Bacs — Paperless Direct Debit (accurate as of August 2026)
- FCA — strong customer authentication (accurate as of August 2026)
- PCI Security Standards Council — Protecting Telephone-Based Payment Card Data (accurate as of August 2026)
- PCI Security Standards Council — FAQ 1210 on storing security codes (accurate as of August 2026)
This article is general information about PCI DSS scope and the UK payment services rules, and it isn't legal, compliance or security advice. PCI DSS obligations depend on how your business is assessed and which questionnaire applies, the telephone payments guidance quoted here is an information supplement from 2018 and not the standard itself, and the authentication treatment of telephone card payments could not be confirmed from a UK regulator source, so take both questions to your acquirer or a qualified assessor. Last updated August 2026.
