Third-party card authorization
How do we take a third-party card authorization when someone pays for another traveler, with the cardholder signing on their own device and the record kept for disputes?
Send the authorization to the cardholder, not to the traveler. When a payer is not the traveler (a parent, a company, a friend), Callvu prefills the authorization from the booking (the traveler, the booking reference, the amount and the currency, what is being paid), sends the cardholder their own link, verifies the cardholder's identity (a one-time code to their contact, an identity document where the policy requires), captures the authorization's content (the cardholder's consent to the charge for the named traveler, the amount or the range, the dates, the cancellation terms acknowledged) with the cardholder's signature on their own device, takes the card on the processor's hosted fields so the operator never holds it, chases an unsigned authorization before the payment deadline, routes a mismatch or a flagged payer to the payments desk in the Decision Desk, and writes the signed authorization and the payment to the booking system, the system of record, for any later dispute.
In scopeSimpleCallvu moves: chase and verify, write back
Last updated November 7, 2026.
The problem today
The chargeback arrived eight months later, and the only evidence was an agent's note that 'mum said it was fine'.
Someone else's card pays for a lot of travel: a parent for a student, a company for an employee, a partner for a trip. The agent takes the card number from the traveler, or from the cardholder by phone, and notes the consent. When the cardholder disputes the charge, the card network asks for compelling evidence that the cardholder authorized it, and a note is not it. The operator loses the dispute and the money.
A third-party authorization is a document the card networks recognize when it carries the cardholder's identity, the specific charge, the traveler, the terms and the cardholder's signature, captured from the cardholder rather than the traveler. The card data itself belongs on the processor's hosted fields, never on a form. The record must be retrievable against the booking for the dispute window.
An authorization the cardholder signed on their own phone wins the dispute; a form the traveler faxed does not.
How it runs
From the requestto the system of record.
A booking is to be paid by a card whose holder is not the traveler. Callvu opens the authorization from the booking.
- Cardholder
- Verifies identity, reads and signs the authorization and enters the card on their own device.
- Traveler
- Names the payer and provides their contact; sees the booking's status.
- Payments desk
- Decides mismatches and flagged payers in the Decision Desk.
- Callvu
- Prefills, sends the cardholder's link, verifies, captures the signature and the card, chases, routes and writes.
Prefill and send
The traveler, the booking reference, the amount or the range (where a balance will follow), the currency, the items and the cancellation terms are prefilled; the cardholder's name and contact are entered, and the cardholder receives their own link by text or email.
Chase and verify the cardholder
The cardholder verifies identity with a one-time code to the contact given (and an identity document where the policy or the amount requires it); the authorization is presented with the specific content (the charge for the named traveler, the amount or the range and the dates, the terms acknowledged, the right to cancel the authorization for future charges); the cardholder signs on their own device, and the card is entered on the processor's hosted fields with the authentication challenge; an unsigned authorization is chased before the payment deadline.
Decide
A signed authorization with a verified cardholder and a passed authentication proceeds by rule; a mismatch (the cardholder's name differs from the card's, the billing address fails, the payer is flagged by the fraud rules, the amount exceeds the authorization) goes to the payments desk in the Decision Desk with the record and only the allowed outcomes (accept, request another verification, require another payment method, or decline).
Write back
The signed authorization with the cardholder's identity evidence, the authentication result and the payment are written to the booking system, the system of record, against the booking and retained for the dispute window, the receipt goes to the cardholder, and a later charge within the authorization's range references it.
Where it ends: The cardholder, not the traveler, authorized the specific charge on their own device with identity verified and the card on hosted fields, and the booking system holds the signed record the dispute will need. The Decision Trace shows the verification and any decision; the Audit Trace shows the link, the signature, the authentication and the write 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.
The handoff
Between the front doorand the back office.
The front door
The cardholder's own link by text or email; the traveler names the payer in the booking or on a call.
The back office
The payments desk decides only mismatches and flags; disputes are answered from the stored record.
The Decision Desk
- A cardholder name or billing mismatch, a flagged payer or an amount beyond the authorization goes to the payments desk in the Decision Desk with the record and only accept, re-verify, require another method, or decline.
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
Reviewers can be inside or outside the company. An outside reviewer needs no account: they open the case from a link sent by email or text and decide in the Decision Desk, never by replying to an email.
CAP-08 · 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.
Who signs the authorization?
The cardholder, on their own device from their own link, after verifying their identity; the traveler cannot sign for them.
Is the card number on the form?
No. The form carries the consent, the charge and the terms; the card is entered on the processor's hosted fields and tokenized.
What happens on a chargeback?
The signed authorization with the identity evidence and the authentication result is retrieved from the booking record and submitted as compelling evidence through the dispute evidence process.
Related 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.