Most voice AI projects stop at answering questions, qualifying a lead, or putting a call through to the right person. This one moves money. A US technology company asked us to automate the billing calls its staff were handling by hand, and the agent we built for them has now processed $117,339.19 across 693 transactions.
The interesting part is not the number. It is that the agent completes a card payment without ever being told a card number.
Overview
Every month, customers phoned in to pay an outstanding balance. A staff member picked up, verified who was calling, looked up the account, read out the balance, asked which card to use, keyed the transaction, and sent a confirmation. The same sequence, several thousand times a year, none of it requiring judgement.
Their Head of Operations had already tried Upwork and Fiverr looking for someone to build the automation, and had not found anyone who could take it on. They came to us looking for an agency that could design and deploy the whole system rather than a freelancer who could wire up a demo.
The requirement was specific: authenticate the caller, reach live account data, take the payment securely, and handle everything that goes wrong on a billing call. That last part, as it turns out, is most of what happens on a billing line.
The Challenge
When the project began in early 2026, Retell AI had no native support for collecting raw card details inside a PCI-compliant payment flow.
That rules out the obvious design. If the agent asks a caller to read out a sixteen-digit card number, those digits land in the voice platform, the call recording, the transcript, and every system downstream of them. Each one of those becomes a place where cardholder data now lives, and each one has to be secured, audited and justified. For a payment volume this size, that is not a trade worth making.
So we did not solve the problem of collecting card details securely. We removed the need to collect them.
We went through the documentation for the company's payment processor API and found that it already exposed everything a payment call needs:
- Locate and authenticate a customer account
- Retrieve the current account balance
- Retrieve the tokenized payment methods already stored on that account
- Identify each stored card or ACH account by its last four digits only
- Submit a full or partial payment against a selected method
- Return confirmation that the payment succeeded or failed
Read that list again and notice what is missing. At no point does the caller need to supply a card number, because the card is already there. It was tokenized by the processor the first time the customer used it, and it sits inside the processor's PCI-compliant environment. The agent never handles the card. It handles a reference to the card.
That single decision is what makes the rest of the system defensible. The voice agent never requests, receives, transcribes or stores a full payment credential, so there is no cardholder data in the recording, none in the transcript, and none in our stack.
The Solution
Here is a real call, start to finish, with no human involved at any point. It runs two minutes.
A complete automated billing call: authentication, balance, payment method selection, and a $464.33 payment confirmed
0:00 / –:––
Listen for the moment around the one-minute mark. The agent says "payment method 1 is a credit card ending in 8679" and waits for a yes. That is the entire card-handling interaction. The caller identifies a card they already own by four digits they already know, and the charge happens inside the processor.
The confirmation email goes out automatically before the call ends, which removes the last manual step that was still sitting with the billing team.
More Than a Simple Payment Agent
Processing successful payments was the smallest part of this build.
Real billing calls go wrong in a lot of ordinary ways, and an agent that only knows how to take a payment is useless the moment one of them happens. Roughly two thirds of the calls on this line end in something other than a completed payment, so the exception paths are not edge cases. They are the main body of work.
Most of these never reach a person. When the balance is a dollar or less, the agent says there is nothing to pay and closes the call rather than processing a token transaction. When a customer has not registered for the online billing center, the system emails them the registration instructions automatically. A missing payment method, a failed one, an account the agent cannot find: each of those ends on the call with its own recorded outcome rather than in a queue.
Two situations still need a person: a caller who cannot authenticate, and a caller who was never trying to pay a bill in the first place. Those are transferred or escalated according to the company's own rules, and they are the only dispositions on the board with the word transfer in the name. Everything else, including the calls where someone hung up before anything happened, is assigned a disposition and closed out. That last part matters more than it sounds.
The Results
At the time of reporting:
| Measure | Result |
|---|---|
| Payments successfully processed | $117,339.19 |
| Successful payment transactions | 693 |
| Billing calls handled | 2,026 |
| Billing calls still needing human staff | Roughly 20% |
Because every call carries a disposition, the company can see the whole line in one view rather than reconstructing it from a payment report and a call log that do not agree with each other.
The two tall bars are payments made (693) and callers who were not trying to pay a bill at all (569). The remaining 764 calls spread across ten other dispositions, each one named. Nobody has to listen to a recording to find out how a call ended.
The Outcome
The common view of a voice agent is a better phone menu: it answers the same forty questions, books an appointment, and hands off anything unusual. That view is out of date.
Given a secure API and conversational logic that has been designed rather than prompted into existence, a voice agent can complete a financial workflow end to end: authentication, live account lookup, a payment decision, the transaction itself, and the receipt. This one has moved more than $117,000 and taken roughly 80% of a billing line off a team's plate.
The staff who used to process those payments are not doing less work. They are doing the work that needed a person in the first place.
A Note on Retell AI and PCI-Compliant Payments
To be clear about what this case study is and is not: at the time we built this system, Retell AI did not offer native PCI-compliant collection of raw card details during a call. Our approach works around that by charging only tokenized payment methods the processor already holds, which is a genuine constraint on what the agent can do. It cannot take a payment from a new card over the phone.
Retell has since acknowledged the gap, and there is an open thread on native PCI-compliant payment processing in their community.
Retell ships new features at a pace we have stopped trying to keep up with (more than FedEx, as we like to say), so we expect this to land. Native support would widen the range of payment scenarios a voice agent can handle, including the first-time card that our current design has to route to a human.
Until then, the tokenized approach is the one we would build again. It is not a workaround so much as the version where sensitive data simply never enters the conversation.
Want Something Like This Built
If there is a repetitive, rules-driven phone workflow sitting on your team (payments, scheduling, verification, intake), the question worth asking is not whether a voice agent could answer the call. It is whether it could finish the job.