Agent-Assisted Payments: Complete Best Practices

What is an agent-assisted payment?

An agent-assisted payment is a card payment taken by phone where a contact centre agent stays on the line throughout the call, but the customer enters their card details directly on their own keypad. DTMF masking keeps the digits away from the agent, the call recording, and the wider contact centre, so card data never reaches your systems.

In practice, an agent-assisted payment is the ordinary phone payment most contact centres still run today — a customer calls in, an agent picks up, they sort out an order or a renewal or a query, and at the end the customer needs to pay. The twist that makes it "assisted" rather than "self-service" is that the agent stays on the line throughout. They help, they reassure, they answer questions, they confirm the transaction cleared. What they don't do — if it's been set up properly — is touch the card data. The mechanics of that — and why call recording doesn't break once you strip the digits out — are covered in our step-by-step on taking a card payment over the phone.

That last sentence is the whole game. Get it right and your contact centre keeps the warmth of a live human conversation while dropping almost entirely out of PCI DSS scope. We've written a practical sister-guide on how to take payments over the phone and a softer-angle piece on balancing security and customer trust on card payments. Get it wrong and you're still trading customer card numbers across an audio channel, into a call recording, onto an agent's screen, and through a stack of systems you probably haven't fully mapped.

We've been helping businesses run agent-assisted payments since 2014 — and the business case is usually a mix of compliance savings and better customer experience, which we unpack in the benefits of secure phone payments and compliance — for insurance call centres, retail customer service teams, travel specialists, housing associations, gyms, and more. (Some of our subscription-led customers are now looking at variable recurring payments as a future direction for card-on-file charges.) We've seen the good version and the bad version, and we've learned exactly where each one earns or loses its money. This guide covers all of it: what agent-assisted payments actually are, how they compare to IVR and self-service, how they work step by step, what the compliance picture looks like, what our customers have actually measured after switching, and the mistakes that ruin the whole thing if you're not careful.

What agent-assisted payments actually are

Agent-assisted payments sit in the middle of three options. At one end you've got fully self-service: the customer calls an automated line, navigates a menu, enters their details into an IVR, and never speaks to a human. At the other end you've got the old-school approach where the customer reads their card number aloud to an agent who types it into a payment form. Agent-assisted sits between the two. The agent stays on the call throughout, but the card details bypass them entirely.

The practical difference matters. In a self-service IVR, the customer has to navigate menus and hope they don't make a mistake, because there's nobody to ask. If they're uncertain about which card to use, or whether their address needs to match the billing address, or what to do when the first attempt declines, they're on their own — and a lot of them just hang up. In pure agent-handled payments, the human connection is there but so is the whole PCI DSS headache, because the card data has touched your agent, your headset, your recording, your notes, and your screen. Agent-assisted keeps the connection and drops the headache.

The way we describe it to customers: the agent helps the customer through the payment, but the agent never sees or hears the card itself. The agent knows a payment's happening, knows when it's complete, knows whether it authorised — but the digits travel on a different path to the agent's ears. That path goes directly from the customer's keypad to a PCI DSS Level 1 payment environment, and then out to your acquirer. Your contact centre stays on the edge of the transaction, not inside it.

We should be precise about what this isn't. Agent-assisted payments aren't the same as a "pause-and-resume" call recording trick, where the agent manually pauses the recorder while the customer reads out their card. That approach still puts the card number in the agent's ears and hands, and the audit trail falls over the first time an agent forgets to hit pause. Agent-assisted payments also aren't the same as sending a customer a link mid-call and hanging up — that's a payment link flow, which is great for some situations but is a different product. Agent-assisted specifically means the agent and the customer stay connected while a secure capture runs in the background.

The technology that makes this work has a few different names depending on who you ask — DTMF masking, DTMF suppression, channel separation, secure capture. They're not quite the same thing, and we'll cover the differences further down. The point for now is that agent-assisted payments are a use case, not a technology. The technology just has to get one job right: stop the card data reaching the agent.

Why businesses choose agent-assisted over the alternatives

If self-service IVR is cheaper and hands-off, why would any contact centre pick agent-assisted? The honest answer is that some contact centres shouldn't — if your transactions are simple, repetitive, and low-touch, pure IVR might suit you fine. But for most contact centres we work with, agent-assisted wins on four specific things: empathy during awkward moments, complex orders that can't be automated, customer service quality, and reduced abandonment.

Empathy first. Payment is often the bit of the call where things get emotional. Somebody's renewing a travel insurance policy for a sick parent. Somebody's paying the deposit on a holiday lodge that took them six months to save up for. Somebody's a property owner ringing about a service charge they don't really understand. In all of these cases, the payment isn't just a transaction — it's the moment where the customer most needs reassurance that they're being looked after. A disembodied IVR voice saying "please enter your card number now" isn't going to cut it. A human saying "take your time, I'll stay with you, just tap the numbers in when you're ready" absolutely will.

Then there are complex orders. Retail is the clearest example. A customer calling Total Tiles to buy kitchen tiles usually needs to talk through sizes, quantities, stock availability, delivery windows, and what's going to happen if the colour's slightly off when the box opens. That's not something you can funnel through a menu tree. The agent needs to be there the whole way, and the payment is just one moment inside a longer conversation. Agent-assisted fits that shape naturally. Pure IVR doesn't.

Customer service quality is the third one. Even when the transaction itself is simple, some businesses have deliberately built their brand around being reachable by a real person. That's a deliberate market choice, and it's a good one — some customers will pay a premium to deal with a human. Asking those customers to route themselves through an IVR for payment undermines the whole positioning. Agent-assisted lets the brand keep its promise.

And fourth, abandonment. The numbers on this are stark. Customers who are handed off to a self-service payment IVR abandon at meaningfully higher rates than customers who pay while still connected to a live agent. Part of that is friction — navigating a menu is slower and more fiddly than tapping numbers into a keypad you can already see. Part of it is psychology: the moment a customer feels like they've been passed to "the machine", they start second-guessing whether to continue. Keeping the agent on the line keeps the commitment intact.

Put those four together and you get a strong argument for agent-assisted in any contact centre where the calls are consultative, the orders are non-trivial, or the brand trades on customer service. Which is most of them.

How agent-assisted payments actually work, step by step

Here's the sequence from both sides of the call, with no hand-waving. A customer calls in to a contact centre using our platform. The agent answers normally, works through the customer's request — a new order, a policy change, a booking, whatever — and eventually reaches the payment step. At this point the agent clicks a button in their terminal or CRM that kicks off a secure payment session.

From the agent's point of view, the first thing that happens is a neutral confirmation: the terminal shows "awaiting card entry" and a progress area where they'll be able to see, in real time, how many digits the customer has entered. The audio to and from the customer stays open — the agent can still hear the customer breathing, coughing, muttering "hang on, where's my wallet". What the agent can't hear is the DTMF tones themselves. Those are intercepted before they get to the headset.

From the customer's point of view, they hear a short prompt — either played by our platform or spoken live by the agent depending on how the flow's configured — asking them to tap in their long card number followed by expiry and the CVV. The customer presses the keys on their phone keypad in the normal way. That part's the same as calling an automated line. What's different is that the conversation hasn't stopped. If they press a wrong digit, they can say "hang on, I fluffed that, can we start again?" and the agent can answer. If they can't find their card, the agent can reassure them and wait. It's a live call, not a menu.

Behind the scenes, each key press generates a DTMF tone. Our platform intercepts that tone at the network layer — not on the agent's device, for reasons we'll come back to — and decodes it into its digit value. The raw digit is held in encrypted memory inside our PCI DSS Level 1 environment. The audio that reaches the agent's headset is a flat replacement tone, a neutral sound that gives no indication of which key was pressed. The call recording, if there is one, captures only the agent's and customer's voices plus this replacement tone. It never captures any decodable card data.

When the customer has entered their full card number, expiry, and CVV, our platform hands the captured digits to your payment processor. The processor attempts the authorisation. If it succeeds, the agent's terminal lights up with "payment authorised" plus a transaction reference. The agent can read the reference out to the customer, confirm what's next, and move on. If the authorisation fails, the agent sees "declined" and can ask the customer to try a different card. The whole payment step usually takes 20 to 30 seconds, and the agent is present throughout.

A few details that matter for engineers and auditors. First, the card data doesn't touch the agent's workstation at any point. That's not a policy claim, it's a technical property — the masking happens upstream of the agent's device, so the agent's computer is literally on a different data path. Second, the platform is stateless with respect to card data; we don't store digits once the transaction clears. Third, the replacement tone the agent hears is designed to coexist cleanly with voice codecs and call recording software, so your QA team doesn't get alarms about dropped audio or codec errors. Fourth, the agent's terminal can be integrated into an existing CRM — 3CX, Aircall, Genesys, a homebuilt screen, whatever — so there's no "new tool" friction for staff. It lives where they already work.

One more thing. The agent is never asked to type card data. That's a deliberate design choice and it's the single biggest reason agent-assisted payments work better than the old "pause the recording and type the number in" approach. If the technology makes it impossible for the agent to enter a card number, the agent can't fall back to the old method on a bad day. The temptation is removed, and so is the audit risk.

The three technical methods enabling agent-assisted payments

Agent-assisted payments as a use case are enabled by three different technical approaches. You'll hear all three pitched to you if you're shopping around, and they're not interchangeable. Here's how they differ.

DTMF masking

DTMF masking is the most common approach and the one we've described above. The customer and agent stay audibly connected throughout. The DTMF tones generated by the keypad are intercepted at the network layer, decoded into digits, and sent directly to the payment processor. The agent hears a flat replacement tone where the digits would have been. The conversation continues. Our full explainer on this is in the DTMF masking pillar.

DTMF masking's strength is that it preserves the conversation. The customer can ask questions during entry, the agent can reassure them, the rapport doesn't break. Its weakness is that it requires the voice path to stay connected, which means the masking system has to handle the audio stream in real time. That's fine at the network layer — we do it every day — but it's why we don't recommend doing it on the agent's workstation.

Channel separation

Channel separation takes a harder line. During card entry, the audio path between the customer and the agent is disconnected entirely. The customer hears a recorded prompt asking for their card details. The agent hears hold music and a progress indicator. The card data goes straight from the customer's keypad to the payment processor. When the payment completes, the two are reconnected and the conversation picks up where it left off.

Channel separation is the strongest answer if you're worried about social engineering during payment, because the agent physically can't ask the customer to read their card aloud — the audio path isn't there. It also produces clean call recordings with no gaps, because hold music plays throughout. The trade-off is that the customer can't ask questions during entry. For experienced callers that's fine. For nervous ones it can feel colder than DTMF masking. We offer both for exactly that reason. Details on channel separation here.

Conference-pay IVR

The third approach is to conference the customer into a separate IVR during payment. The agent stays on the call but the customer is temporarily routed into a secure IVR system to enter their card. When the IVR confirms payment, the customer is brought back to the agent. It works, and the card data stays out of your systems, but customers generally find the handover clunky. Some abandon the transaction at the moment they're passed to "the machine". It's also more complex to integrate because you now have two voice platforms to coordinate.

Quick comparison

Our honest take: DTMF masking wins when the human connection matters most. Channel separation wins when audit-proof security matters most. Conference-pay IVR wins when you've already got a compatible IVR estate and you're optimising for minimal integration work. Most of our customers use DTMF masking by default and layer channel separation onto the highest-value or most security-sensitive call types.

Compliance and security: what agent-assisted means for PCI DSS

The moment you remove card data from the agent's environment, your PCI DSS picture changes shape. This is the scope reduction story every phone payment vendor is selling, and it's worth unpacking properly because the details matter more than the headline number.

Without any protection in place, a contact centre handling phone card payments sits inside the full PCI DSS cardholder data environment. Agents hear the numbers, so the audio channel is in scope. Recordings capture the tones, so the recording platform is in scope. Agents type the numbers into a form, so the workstation, the network, the CRM, and anything downstream is in scope. Your self-assessment questionnaire is SAQ D — 329 controls covering network security, access management, encryption, vulnerability scans, key management, logging, monitoring, and more. It's the biggest tier PCI produces, and it's designed for environments that store, process, or transmit card data across substantial infrastructure.

With agent-assisted payments done properly — DTMF masking or channel separation running through a PCI DSS Level 1 provider — your self-assessment typically drops to SAQ A. SAQ A is 22 controls. You're attesting that you've outsourced all card handling to a certified third party (us, in this case), that your own environment never touches card data, and that the handful of remaining controls around that relationship are in place. That's roughly a 93% reduction in requirement count, and the remaining controls are mostly about documenting the relationship rather than running infrastructure.

The cost side follows the control count. Contact centres we've worked with typically report 75% reductions in ongoing PCI spend — that's staff time on compliance, quarterly ASV scans, annual penetration tests, QSA fees, remediation, and training, combined. That number shows up repeatedly in the cases we'll come to in a moment. If anything it understates the benefit, because it doesn't count the strategic freedom of no longer having phone payments as a board-level audit risk.

PCI DSS 4.0 — which became mandatory in March 2025 — tightens the scoping rules. You now have to actively demonstrate that systems in your environment are out of scope, rather than assuming they are. That makes agent-assisted payments more valuable, not less, because outsourcing card handling to a certified provider gives you a clean story to tell the QSA. You can point at the network diagram, point at our Attestation of Compliance, and show that the card data never enters your environment. For the full picture on contact centre PCI obligations we've got the PCI 4.0 call centre pillar.

One point worth drawing out. Agent-assisted doesn't just reduce scope — it reduces blast radius. If your only protection is "we train agents not to write card numbers down", a single bad day with a single agent puts you in breach territory. If your protection is "the card data never reaches the agent in the first place", there's no single point where a human failing creates a compliance incident. That's the difference between a control that depends on perfect execution and a control that's baked into the technology. Auditors know the difference. They'll rate the two accordingly.

Real business outcomes: what customers get

Compliance is what drives the initial conversation. The outcomes customers actually talk about after they've deployed are different — handle times, orders per day, hours of admin recovered, staff working from home. Here's what the numbers look like across a few real deployments.

Warby Parker: 35% reduction in call handling time

Eyewear retailer Warby Parker brought us in to solve PCI compliance on their phone order line. The side effect was that average call handling time dropped by 35% once they'd switched. Customer service reps weren't cycling through the old pause-read-type-confirm loop any more — the customer entered their own details via keypad while the rep stayed on the line. Customer satisfaction scores on the payment experience went up 28%. Payment errors dropped 42%, which cut the number of follow-up calls. Their VP of Customer Experience put it like this: "Paytia's solution has transformed our telephone ordering process. We've dramatically improved efficiency while ensuring the highest levels of payment security. Our team now spends less time processing payments and more time delivering the exceptional customer experience that defines our brand."

Total Tiles: 80% jump in daily orders

When COVID pushed Total Tiles to remote working, their phone order process broke. Staff couldn't use the old lock-down-the-office method of protecting card data. Within a week of switching to us, daily order throughput went from 25-30 to 45-50. That's an 80% lift. It wasn't the payment technology itself that moved the number — it was the fact that the old workflow had been the bottleneck on their whole order process. Once the friction disappeared, the team handled a much bigger volume without adding headcount. They told us afterwards: "We highly recommend Paytia to any business wanting to enable distributed and remote working whilst removing the risk and uncertainty of a potential data breach, fraud and PCI fines."

Insure and Go: 75% PCI scope reduction across a hybrid workforce

Insure and Go run a travel insurance call centre on Digi-desk by Citrus. The challenge was that agents were capturing live card details during calls for new policies, modifications, and emergency claim payments, and the company wanted to eliminate that exposure while also supporting hybrid working. We deployed a common capture service across all their agent locations. The result: 75% PCI scope reduction, 40% agent efficiency improvement, and identical payment experience whether the agent was in the office or at home. Their team said it plainly: "The common capture service means our customers get the same secure payment experience whether our agent is in the office or working from home. Complete location transparency with total security."

All Clear Travel: flexible licensing, 45% off-peak savings

Sister operation All Clear Travel got the same 75% scope reduction and added a layer of cost flexibility. Using our flex licensing model, they scale agent seats up and down instantly based on active usage. During off-peak travel periods they're paying 45% less in payment processing costs because they don't need the same number of seats under the compliance umbrella. During peak periods — think school holidays, summer booking waves — they spin additional agents up without licensing friction. They summed it up: "The flex licensing transformed our cost structure. We can scale our Digi-desk agents up or down instantly without worrying about fixed payment processing costs."

Enjoy Fitness: 15 hours per week back in the business

Enjoy Fitness is a gym chain. Before us, staff spent roughly 15 hours a week taking card details over the phone, chasing failed payments, and manually reconciling member receipts. After switching to Paytia, that dropped close to zero. 92% of surveyed members preferred the new payment system to the old phone-based approach. "We were spending many hours every day taking card payments, but now with the implementation of Paytia, payment links can be easily generated, sent by any method to our members, and then we have a notification of when payment has been made. It's that easy."

Pinnacle Group: secure phone payments for property service charges

Pinnacle Group manage residential property across the UK — around 30,000 homes across more than 100 locations. Their phone line handles service charges from apartment owners who prefer to talk to a person rather than pay online. Alison Wade, their Head of Income and Performance, needed a solution that worked with home-based staff and didn't require complex integration. Paytia removed the business from 95% of its PCI DSS obligations, worked seamlessly with their existing RingCentral telephony, and scaled from a single agent licence upwards. In her words: "I wanted something that was as simple to set up and use as a virtual terminal or a point-of-sale card reader — but also had the flexibility to adapt as our usage and functional needs grow. I'm delighted to say that Paytia has achieved precisely that."

The pattern across all five cases is the same. Scope shrinks, handle time drops, staff time comes back, and customer experience improves. That's what agent-assisted payments look like when they're working.

Agent training for the new process

One of the questions we get asked every discovery call is "how long is this going to take to train my team on?" The honest answer is short: 20 to 30 minutes per agent, and most of that is showing them the terminal rather than teaching them anything new about payments. The payment flow itself is simpler than what they were doing before, not more complicated.

Here's what changes for your staff. First, the agent no longer asks the customer to read out their card number. Instead, at the payment step, they click a button in their terminal and say something like "I'll pop you through to our secure card entry now — you'll hear a prompt, and you can tap your card number in on your phone keypad. I'll stay right here with you." That's the biggest behavioural change, and it becomes natural within a couple of calls. Second, the agent watches a progress indicator rather than typing anything. Third, the agent reads the transaction reference from the terminal when the payment clears. That's it.

What needs to be covered in training, beyond the mechanics, is the edge cases. What happens if the customer can't use their keypad — some older phones, some accessibility needs, some hands-free setups don't transmit DTMF cleanly? The answer is a fallback to a payment link or web chat payment, both of which we support out of the box. What happens if the first card declines? The agent asks the customer to try a different card, the platform starts a fresh capture, nothing to relearn. What happens if the customer asks the agent to type the card details for them? The agent explains that our system is designed so they can't — it's a security control, not a limitation — and offers the keypad entry or a link as alternatives.

We'd also cover refunds. The refund flow is separate from capture, and it's the moment where agents sometimes get tripped up because the refund interface looks different. Walking through a live refund during training takes five minutes and prevents a week of support tickets later.

The last thing worth covering is the "why". Agents who understand why the process works the way it does — that the design stops them ever being accused of card fraud, that it protects their job as much as it protects the customer, that it means the recording can be listened to without worrying about a leak — follow the process willingly. Agents who are just told "this is the new rule" get creative on bad days. The training deck takes an extra five minutes to explain the reasoning and saves you months of drift later on.

Integration with your existing telephony

Most contact centres we talk to are worried about integration before they're worried about anything else, because they've been burned by enterprise software projects before. The good news is that agent-assisted payments don't require a platform migration. We're built to plug into whatever telephony you're already using.

On the hosted side, we integrate directly with 3CX, Aircall, RingCentral, ContactOne, Amazon Connect, Talkdesk, and most SIP-based platforms. For on-premise PBX — Avaya, Cisco, Mitel, NEC — we integrate at the SIP trunk level so we don't need to touch your core telephony. For cloud contact centre suites like Genesys, we work alongside their native integrations rather than replacing them. The short version: if it's a modern phone system, we probably connect to it, and if it's an unusual one, we'll tell you honestly on the discovery call whether it's going to be straightforward or not.

We don't install anything on agent workstations. The Paytia terminal is a browser-based interface that works on whatever the agent's already using — Windows, macOS, Chromebook, thin client, doesn't matter. The agent's softphone stays exactly as it was. The only visible change for the agent is the new button to start a secure payment, and that button lives inside whichever CRM or ticketing system they already work in.

From the infrastructure side, we run a pair of production regions — lhr1 in London, iad1 in Washington — with failover across them. Payments are routed to the nearest healthy region. If one goes down, traffic fails over automatically. We don't promise zero downtime because nobody should, but we do design for single-region failure without a customer-visible impact.

Typical deployment timelines for agent-assisted are one day to one week for simple setups, two to four weeks for multi-site or multi-country. We've never had one take longer than six weeks, and most of the work on long ones is around procurement and change management rather than technical integration. We work with your operations lead for an hour at kickoff to understand the call flow, provision the platform, run a parallel test for a day or two, and then flip traffic over. For the full how-to on taking a phone payment end to end, including the non-agent-assisted variants, we've got the phone payments pillar.

Common mistakes to avoid

We see the same handful of mistakes across contact centres that roll out agent-assisted payments badly. Here's what they are, and how to avoid them.

The first and biggest is letting agents keep reading card numbers aloud anyway. You'd be surprised how often this happens. The technology's been installed, the terminal's there, the masking works — and then an agent "helps out" a confused customer by saying "just read me the numbers, I'll do it for you". At that moment, the whole compliance boundary collapses. The fix is threefold: make sure the terminal doesn't accept manual card entry from the agent (ours doesn't), train the agent on what to say instead, and include a culture message that processes aren't for speed, they're for protection. We've covered the DTMF side of this in detail in the DTMF masking pillar.

The second is forgetting about refunds. Contact centres focus on capture during rollout and discover during their first week live that the refund interface hasn't been walked through with anyone. Agents fall back to logging into the payment gateway directly to issue refunds, which either defeats the scope reduction (because now they're seeing card numbers again) or produces failed refund tickets. The fix: cover refunds in initial training, set up the refund flow through your Paytia terminal from day one, and document who has permission to issue refunds.

The third is ignoring screen-recording risk. If you run screen-recording software for agent monitoring, training, or dispute resolution, that software sees whatever the agent sees. Agent-assisted payments don't show card numbers on the agent's screen anyway — so in theory the screen recording is fine — but some contact centres also have their payment terminal on-screen, and some gateways display the full card number briefly during confirmation. Audit your screen recording reach before rollout. Either disable screen capture during payment or make sure your terminal never renders card data.

The fourth is relying on pause-and-resume as a backup. Don't. Pause-and-resume is a failed pattern and it's gradually being phased out across the industry. Keeping it as a "just in case" option means some percentage of your payments end up going through the old insecure route, which puts you back in full scope for those recordings. Pick agent-assisted or channel separation and commit. If the tech fails, fall back to sending a payment link — not to reading card numbers over the phone.

The fifth is assuming one control covers everything. Agent-assisted payments handle the phone channel. They don't handle email, chat, SMS, web forms, mail-order cards, or walk-in payments. Each of those channels needs its own appropriate control. We offer products for most of them, but they're separate decisions. Treating a single technology as a silver bullet is how contact centres end up with quiet compliance gaps in the channels nobody thought to audit.

Frequently asked questions

Is agent-assisted payment secure?

Yes, when it's implemented on a PCI DSS Level 1 platform. The card data never touches your agents or your environment — it's captured directly from the customer's keypad by our certified infrastructure and sent to your payment processor. Your agents can still hear the customer and help them through the call, but they don't hear or see the card itself. For auditors, this is a cleaner story than any process that depends on the agent doing the right thing every time.

Do I need multi-factor authentication for agent-assisted payments?

Yes, for the agents logging into the Paytia terminal. PCI DSS 4.0 requires MFA for all access to the cardholder data environment, and that includes the agent interface even though the agent isn't seeing raw card data. We support standard MFA options — TOTP, SMS as a fallback, and SSO integration with your existing identity provider. We'd always encourage SSO because it makes offboarding cleaner.

What is agent assist technology, exactly?

"Agent assist" as a broader term covers any technology that helps a human agent do their job better — from real-time call transcription to sentiment analysis to suggested responses. Agent-assisted payments are a specific subset: technology that lets the agent stay on the call while card data is captured safely. The two share a name because they share a philosophy — keep the human in the loop, remove the friction they don't need to own.

Does it work on mobile phones and landlines?

Yes to both. DTMF tones are a fundamental part of the phone network and have been since the 1960s. Mobile phones, landlines, VoIP phones — they all generate DTMF when the keypad is pressed. Our masking works on all of them. The only edge case is some older hands-free setups and some accessibility devices that don't transmit DTMF cleanly, in which case we fall back to a payment link.

Can the agent hear the keypresses at all?

No. The agent hears a flat replacement tone where the keypress tones would have been. Every digit sounds identical. There's no decodable audio information in what the agent hears, and the same is true for anything recording that audio — so call recordings are clean too. The customer's voice is unaffected; they can still speak to the agent throughout.

What happens when the card declines?

The agent sees "declined" in their terminal, with a reason code if the processor provides one. They can ask the customer to try a different card, and our platform starts a fresh capture session. No card data from the declined attempt is retained, and nothing about the card number is visible to the agent at any point.

Is agent-assisted suitable for MOTO payments?

Yes. MOTO — mail order / telephone order — is the category agent-assisted payments are specifically built for. Any MOTO setup that currently relies on the agent hearing and typing card details is a candidate for replacement with agent-assisted.

Can I use agent-assisted for recurring payments?

Yes. We tokenise the card on first capture, return a token to your system, and let you charge the token for future payments without re-capturing the card. The customer only needs to do the keypad entry once.

How does agent-assisted compare to sending a payment link?

Agent-assisted is for situations where you want the agent present throughout the payment — typically consultative sales, customer support calls, or first-time customers who need hand-holding. Payment links are for situations where the customer will complete the payment later, on their own time, or where they'd rather use their phone's web browser than the keypad. Most of our customers use both: agent-assisted as the default, payment links for fallback and async scenarios.

Will it work with my CRM?

Probably. We integrate into Zoho, Salesforce, HubSpot, Microsoft Dynamics, Zendesk, Freshdesk, and several sector-specific systems (claims management, booking platforms, property management). Integration is usually an embedded terminal or an API-triggered session start. If you've got something unusual, tell us on the discovery call and we'll check.

Getting started

If you're running phone payments through agents today and you've been putting off the compliance conversation, you're not alone — it's the single most common reason contact centres start talking to us. The fix is smaller than people expect. A discovery call to understand your setup, one to six weeks of implementation depending on how complex the integration is, 20-30 minutes of training per agent, and then you're live. Scope drops, handle time drops, and the audit conversation gets dramatically easier.

We don't do hard sales and we don't chase. If it's a good fit for your contact centre, we'll tell you. If it isn't, we'll tell you that too. Book a product tour to see the agent experience end to end, or get in touch if you'd rather start with a conversation. Either way, you'll get a straight answer.