Payments by phone on a secure screen

How do we take a payment during a call so the customer enters the card on a secure screen that the agent never sees, and the payment posts to the booking?

Send the customer a screen instead of asking for the card. During the call, Callvu prefills the payment from the booking (the traveler, the amount due, the currency, the booking reference, the items being paid), sends the customer a link by text or email to a secure payment screen, lets the agent see the screen's progress but never the card data, captures the card details and the cardholder's authentication on the processor's hosted fields, applies the card network's and the processor's rules (the authentication challenge, the billing address check, the surcharge rules where they apply), confirms the authorization to the agent in real time, and writes the payment to the booking system with the receipt sent, so the call recording and the agent desktop stay out of PCI scope.

In scopeSimpleCallvu moves: prefill, write back

Talk to an expert Try it in the sandbox

Last updated November 7, 2026.

The problem today

The customer read the card number aloud, the recording captured it, and the whole contact center was in PCI scope.

Today, without Callvu

Travel is paid for over the phone constantly: a balance on a cruise, a change fee, a hotel deposit, an upgrade. The agent asks for the card, types it into the booking tool, and the recording keeps every digit. Pause-and-resume on the recorder helps until an agent forgets. Every desktop, every recording and every agent is in scope for the card data standard, and the audit is long.

The card data standard contemplates the alternative: the customer enters the card on a hosted page or hosted fields the merchant's systems never touch, the agent sees only the progress and the result, and the recording never hears a number. The amount, the reference and the items still come from the booking, and the payment still posts to it. What changes is who types.

A payment the customer enters is a payment the contact center is not liable for.

How it runs

From the requestto the system of record.

A customer agrees to pay during a call, or an agent reaches the point in a change where a payment is due. Callvu opens the payment from the booking.

Customer: Opens the link on their phone, enters the card and completes the authentication, and receives the receipt.
Agent: Prefills the amount, sends the link, sees the progress and the result, never the card.
Payment processor: Hosts the fields, authorizes the card and returns the result and the token.
Callvu: Prefills, sends the link, shows progress, applies the rules, confirms and writes.

Prefill the payment
The traveler, the booking reference, the items being paid, the amount due and the currency are prefilled from the booking; the agent confirms the amount with the customer and the payment screen is created with it, so the customer never types an amount.
Send the screen
The customer receives a link by text or email (or the screen opens in the app they are already in); the agent's desktop shows that the link was opened, the fields are being completed and the authentication is in progress, and nothing else; the customer enters the card on the processor's hosted fields, with the billing address and the authentication challenge where the issuer requires it.
Apply the rules and confirm
The card network's and the processor's rules run on the processor's side (the authentication, the address check, the surcharge rules by card type and country where they apply, the currency); a decline or a failed authentication is shown to the agent with the reason code so the customer can try again or use another card, without the card data; the authorization is confirmed to the agent in real time.
Write back
The payment with the authorization code, the token for any later refund, the amount, the items and the time is written to the booking system, the receipt goes to the customer, and the call notes record that the payment was taken on a secure screen; the recording holds no card data.

Where it ends: The payment was taken while the customer was on the call, entered by the customer on a hosted screen, confirmed to the agent live, and posted to the booking system, with the recording and the desktop out of scope for the card data standard. The Decision Trace shows the prefill and the rules applied; the Audit Trace shows the link, the customer's steps and the authorization with time.

Runtime enforcement

What is enforcedwhile the work runs.

The regulations preloaded in Callvu Studio and the bank's own policies, applied as steps that run, not lines in a binder. A step that breaks a rule does not run, so a completed run was compliant.

Regulations

PCI DSS: The Payment Card Industry Data Security Standard applies to every system, person and recording that stores, processes or transmits cardholder data; a customer entering the card on hosted fields served by a validated processor, with the merchant's systems never touching the primary account number, removes the agent desktop, the telephony and the call recording from scope and lets the merchant attest under a reduced questionnaire; call recordings must never retain the card verification code.
Card network authentication and surcharge rules (the networks' operating regulations, the European strong customer authentication requirement under PSD2 where it applies): Card-not-present payments carry the issuer's authentication challenge where required, the address verification, and the surcharge rules by card type and jurisdiction; a payment taken on hosted fields passes the authentication to the customer's device, which a phone payment with an agent typing cannot.
Receipt and record keeping (the card networks' receipt requirements and the FTC Act on billing accuracy): The customer receives a receipt with the merchant, the amount, the date and the last four digits only, and the booking record keeps the authorization and the token for refunds and disputes, never the card number.

Company policies

The agent never asks for, hears or types a card number; the customer enters it on the secure screen.
The amount comes from the booking and is confirmed before the screen is sent.
A decline is shown to the agent as a reason code, never as card data.
The booking system is the system of record for the payment, holding the token and the authorization.

Controls

Prefill of amount and reference from the booking.
Hosted fields served by the processor.
Agent progress view without card data.
Authentication and network rules on the processor side.
Real-time confirmation.
Booking system write with token, receipt and call note.

Clocks and deadlines

Link validity: The payment link expires after the policy's period and the call's end, and the agent can resend.
Authorization: Confirmed in real time during the call; the booking's hold is released or extended from it.

Documents and checks

The prefilled payment with the booking reference
The customer's completion (no card data)
The authorization result and the token
The booking system record and the receipt

In the Decision Trace

The amount and its source.
The rules applied and the result.

In the Audit Trace

The link sent and opened with time.
The authorization with time.
The write and the receipt.

The handoff

Between the front doorand the back office.

The front door

A call, with the customer on their phone; the same screen works from the app or an AI assistant.

The back office

Agents see progress and results; finance sees payments posted to bookings with tokens; the auditor sees no card data anywhere.

The Decision Desk

A payment above the agent's authority, a repeated decline or a mismatch between the payer and the traveler goes to the payments desk in the Decision Desk with the result codes and only the allowed outcomes.

Proof

In scope.Proof at scale, not one process at a time.

The kind of process Callvu runs in production for customers in this industry. Ask for a reference on this exact process. The results below are the industry's published proof; each claim code links to its record on agents.callvu.com.

More than 1,000 processes are live across Callvu customers.

Across Callvu customers

A process can be started by the customer's server, a webhook from any system, a phone menu that texts the caller a link (Visual IVR), the Callvu AI chat, an outside AI agent over MCP, a campaign spreadsheet, a public link or an inbound email.

CAP-01 · Self-asserted · verified 2026-11-02

Every run produces a Decision Trace (why each AI action was allowed) and every workflow execution an Audit Trace (the chronological governance record).

ENF-03 · Self-asserted · verified 2026-11-02

Questions

What buyers ask next,answered plainly.

What does the agent see?

That the link was opened, that the fields are being completed, the authentication status and the result with a reason code on a decline; never the card number.

Does this take the contact center out of PCI scope?

The agent desktop, the telephony and the recording no longer handle card data when the customer enters it on the processor's hosted fields, which is the scope reduction the standard contemplates.

What if the customer is not able to use a link?

The screen can open in the app or the website they are already in; the fallback is an interactive voice capture that keeps the digits out of the agent's hearing, under the same rules.

Related processes

Tour and cruise payment plans Final balance collection before departure Third-party card authorization Payment recovery on failed payments Try it in the sandbox All travel and ecommerce processes

Bring this process, or the one that costs you most.

We build it against your policies and your systems, train your team and stay with you through launch. You are live in weeks.