Payment during the call, by secure link

Take payment during the call without ever hearing a card number

The agent finds the invoice or deposit in your ERP or CRM, confirms who it is speaking to, then sends a Stripe payment link to the email or mobile number already on the customer record.

Canadian French + English • Configurable human handoff • Keep your number when supported by your carrier

At a glance

Defined by the workflow, not only the voice

Phone payment is where businesses quietly lose money. The customer calls ready to pay, nobody is free to take it, someone promises a callback, and the invoice goes back into the dunning cycle for another three weeks.

The usual answer — reading a card number aloud to a person on the phone — is the worst available option. The number is spoken across an office, it lands in a call recording, and it drags your business into a PCI DSS scope nobody deliberately took on.

VocalOps uses the only defensible approach: the agent never touches card data. It identifies the account, confirms the amount, then triggers a Stripe payment link to the email or mobile number already in your system. The customer pays on Stripe's hosted page, during the call or right after.

The link is never sent to an address or number dictated on the call. It goes to the contact details on the record, which removes the phone line's easiest role as a fraud channel.

As with every integration, the payment step is configured and validated with your team before launch: which system owns the balance, which amounts the agent may offer, and what it has to refuse.

Outcomes

What the agent does during the call

Find the right balance

Reads the customer record in your ERP or CRM: open invoice, required deposit, or the amount remaining on a work order.

Confirm who is calling

The agent asks the caller to confirm details rather than reading the record aloud, and stops if the match is doubtful.

Send a Stripe payment link

A single-use link tied to the right invoice, delivered by text or email to the contact details already on file.

Stay with the customer

The agent remains on the line, confirms the link arrived, and repeats the steps if the customer cannot find it.

Log the outcome

The link sent, the channel used, the amount, and the payment result are attached to the call and written back to your system per the validated integration.

Never handle the card

Card details are entered on Stripe's hosted page. They never touch the phone line, the recording, or our servers.

Buyer guidance

How to evaluate phone payments before you switch them on

A payment is the highest-consequence action a phone agent can trigger. The evaluation is less about the conversation than about what is read, what is written, what is refused, and what stays auditable afterwards.

Rule out the card read aloud first

Some vendors still offer to capture card digits during the call, with or without pausing the recording. That approach pulls your phone line, your telephony provider, and your recordings into PCI DSS scope, and one misconfigured recording pause is enough to store a card number there. A link to a hosted payment page removes the problem outright: the card never exists on the telephony side.

Ask which system owns the amount

Collecting against a stale balance creates an overpayment, a credit to issue, and one more call. Pin down where the amount comes from, how often it refreshes, what happens when two invoices are open, and how a payment already received through another channel is recognized. If the amount comes from a copy synced overnight, you will be collecting yesterday's balances.

Demand the detail of identity verification

Good practice is confirm, not disclose: the agent offers a partial detail from the record and the caller validates it. Check what happens with a blocked number, a call from a different phone, a namesake, a tenant instead of an owner, or an employee calling for their company. Ask how many attempts are allowed before transfer.

Lock down where the link can go

This is the most important anti-fraud control and the one most often missing from demos. The link must go to the contact details already on the record. A system that accepts "send it to this address instead" mid-call turns your service line into a diversion channel. If an email really needs updating, that belongs in a separate path with a person in it.

Get the refusal list in writing

A sound configuration has a written list: no discounts, no payment plans, no interest waivers, no refunds, no discussion of a dispute, no unplanned partial payment. Confirm the wording of each refusal, because that is where complaints start and where your business inherits promises it has to honour.

Follow the trail into accounting

Ask to see the whole path: link issued, payment received by Stripe, entry written to your billing system, reconciled to the right customer account. Specify what the team sees when the write fails after the customer has paid — the scenario that costs the most trust, and the one that must raise an alert rather than go silent.

Treat retention as a selection criterion

Recordings and transcripts of a payment call contain financial information. Pin down where they are hosted, who can access them, how long they are kept, and how they are deleted. In Quebec, Law 25 imposes minimization and transparency duties: a payment call kept indefinitely is a liability, not a convenience.

Measure time to cash, not call counts

The metric that moves is the delay between the call and money received, then the share of invoices settled during the call rather than in a dunning cycle. Set a few weeks of baseline before launch; without it you will have a favourable impression and nothing to show your finance lead.

Questions to get answered in writing

  • Which system owns the amount due, and how often is it read?
  • How is identity verified, and after how many attempts is the call transferred?
  • Can the link ever go anywhere but the contact details on the record?
  • Which requests does the agent refuse, and in what words?
  • What happens if the payment succeeds but the write to our system fails?
  • Does card data touch the phone line, the recording, or the transcript?
  • Where are payment-call recordings hosted, and for how long?
  • Which report lets us reconcile links sent against payments received?

Implementation

How a deployment works

  1. 1

    Scope

    Decide which system owns the balance, which payment types qualify, and which contact fields are used for delivery.

  2. 2

    Configure

    Write the rules: offerable amounts, deposits, refusals, the wording of identity confirmation, and transfer conditions.

  3. 3

    Validate

    Test a deposit, a late invoice, a disputed amount, and an undelivered link in both French and English before announcing the service.

  4. 4

    Improve

    Track paid-on-call rate, unpaid links, and transfers, then adjust the rules and the wording.

Scenarios

Where phone payment actually changes something

Deposit before dispatch

Plumbing, HVAC, electrical: a confirmed deposit before a truck rolls cuts cancellations and unpaid trips.

Accounts receivable

The customer calls about a late invoice. That is the moment to collect it, not to promise a callback.

Payment before pickup

Garages, repair shops, and services where the balance must be settled before the customer collects a vehicle or equipment.

Rent and recurring fees

Property management and subscriptions, where the caller wants to settle a late month without a portal password they have lost.

Balances after insurance

Clinics and professional services where the patient's share is known only once the claim is processed.

FAQ

Questions about phone payments

Can the agent take a card number over the phone?

No, by design. It sends a link to a payment page hosted by Stripe. No card data travels over the line, into the recording, or into the transcript.

Do we have to use Stripe?

The integration described here is built on Stripe. Another payment provider has to be assessed during scoping: feasibility depends on its API, its payment links, and how your billing system reconciles them.

How does the agent know what the customer owes?

It reads the record in whichever system you designate as authoritative — ERP, CRM, or billing software — under the permissions validated with you. If the balance cannot be found, it transfers instead of offering an amount.

How do you verify the caller's identity?

The agent asks the caller to confirm details rather than disclosing them, and transfers after an agreed number of attempts. The level of verification is set with you based on how sensitive the account is.

Can the customer ask for the link to be sent elsewhere?

No. The link goes to the email or number already on the record. Changing contact details follows a separate path, handled by a person.

Does this put us in PCI DSS scope?

The hosted-link approach exists precisely to reduce that scope, since the card is entered at Stripe. Your exact position has to be confirmed with your acquirer and your advisor; we do not issue that opinion on your behalf.

What if the customer does not pay during the call?

The link stays valid according to the rules you configure, and the call records that it was sent unpaid. Your team sees the list of unpaid links instead of discovering the case at the next dunning cycle.

Can the agent accept a partial payment or a plan?

Only if you have explicitly configured it. By default, partial payments, plans, and discounts are refused and transferred to a person.

Have us test one of your payment calls

Give us a real case — a deposit before dispatch, a late invoice, a balance after insurance — and validate the verification, the link delivery, and the refusals with your team.