Expert guide
Collect during the call: a Stripe payment link, with no card number spoken
How the agent finds the invoice, verifies identity, and sends the link
The full flow of a phone payment with no card read aloud: reading the balance from the ERP or CRM, verifying identity, sending a Stripe link to the contact details on file, writing back the result.
The best moment to collect is already on the line
A customer calling about their invoice is a customer ready to pay. It is the rarest and most perishable intent in an accounts-receivable cycle: it lasts as long as the call.
In most small and mid-size businesses, that intent meets an organization not set up to receive it. Whoever answers has no access to the billing module, or no authority to take a payment, or is reluctant — reasonably — to handle a card number. Someone promises a callback, and the invoice goes back for a full cycle.
So the point of paying during the call is not to automate an administrative task. It is to remove the delay between the decision to pay and money received.
Why a card read aloud is the wrong answer
The instinctive solution is to have the caller read out their card digits. It is still offered, sometimes with a recording pause, and it creates three problems nobody scopes at the moment they adopt it.
- The number is spoken aloud, in an office, often in front of other people.
- It enters the call recording and the transcript, and therefore your retention, your backups, and your exports.
- It pulls the phone line, the telephony provider, and the recording tool into PCI DSS scope, with the duties that follow.
- One misconfigured recording pause cancels the whole protection, and nobody notices before an audit.
The link approach: the card never exists on the telephony side
The defensible alternative is simple: the agent never touches card data. It identifies the account, confirms the amount, then triggers a link to a payment page hosted by Stripe. The customer enters their card at Stripe, on their own phone, during the call or right after.
That shift changes the nature of the risk. There is no card data to protect on the line, in the recording, or in the transcript, because there never was any. What travels over the phone is an invoice number and an amount.
The rest of this article describes the flow as it is configured for a VocalOps customer, including the places where it has to stop.
Step 1 — find the right amount in the right system
The agent does not ask the customer how much they owe. It reads the record in whichever system you designate as authoritative: ERP, CRM, or billing software, under the permissions validated during scoping.
This step decides the quality of everything after it. Collecting against a stale balance produces an overpayment, a credit to issue, and one more call — the exact opposite of the intended gain.
- Which system owns the balance, and how often is it read?
- What happens when two invoices are open for the same customer?
- How is a payment already received through another channel recognized?
- What does the agent do if the balance cannot be found or the system does not answer?
Step 2 — verify identity by confirming, never by disclosing
The principle is confirmation: the agent offers a partial detail from the record and the caller validates it. It does not read out the address, the full amount, or the history before it has a match.
The inbound number is a first signal, never proof. A customer may call from another phone, a tenant may call for an owner, an employee may call for their company. Each of those cases deserves a written rule rather than improvisation.
The level of verification is chosen according to how sensitive the account is, and the transfer rule after an agreed number of attempts is part of the configuration, not an exception to it.
Step 3 — send the link where the record says, and nowhere else
This is the most important rule in the whole flow, and the one most often missing from demos. The payment link goes to the email or mobile number already on the record. Never to details dictated during the call.
A system that accepts "send it to this address instead" turns a service line into a diversion channel: it is enough to call posing as a customer to receive a link tied to their invoice. If contact details genuinely need updating, that follows a separate path, with a person, and not in the same call as the payment.
The agent stays on the line while the link arrives. It confirms receipt, repeats where to look, and logs the case if the customer cannot find it.
Step 4 — write back the result, and know what to do when the write fails
A payment received by Stripe has to land in your billing system, reconciled to the right customer account. This is the invisible part of the flow, and the most expensive one to neglect.
The scenario to scope explicitly is the one where the customer has paid but the write fails. It must raise an alert a person can see, with the amount, the customer, and the payment identifier — never a silence discovered at the next dunning run, after the customer has already been charged.
- Link issued, with the target invoice and the delivery channel.
- Payment received at Stripe, with its identifier.
- Write to the billing system, or a failure raised to a person.
- Result attached to the call, so the next person does not have to listen back.
What the agent has to refuse
A payment is the highest-consequence action a phone agent can trigger. The refusal list is therefore not an embarrassing limitation: it is the part of the configuration that protects your business.
- No card number, security code, or expiry date; the agent interrupts a caller who starts reciting them.
- No discount, payment plan, interest waiver, or unplanned partial payment.
- No refund or payment reversal.
- No discussion of a disputed amount: transfer.
- No link sent to contact details supplied during the call.
What to measure, and what this will not fix
The useful metric is the delay between the call and money received, then the share of invoices settled during the call rather than in a dunning cycle. Take a few weeks of baseline before launch, or you will have nothing but a favourable impression.
This flow does not recover a debt whose amount the customer disputes, does not replace a credit policy, and does not settle a contested balance. It removes the delay between the intent to pay and the collection, which is considerable on its own — but it should be described that way.
Finally, recordings and transcripts of a payment call contain financial information. Where they live, how long they are kept, and how they are deleted are decisions to make before the first call, not after an audit. In Quebec, Law 25 imposes minimization and transparency duties that apply directly to those recordings.