Asking someone to "pay when you can" after a call ends is how a deposit quietly never arrives. Cypher P exists to close that moment while the caller is still on the line: your agent creates a secure payment request, a link appears on the caller's screen if they are on a web call and lands in their email if they gave one, and the caller pays in their own time, by card through Stripe where you have connected it, or by bank transfer, JazzCash or Easypaisa where they prefer that. No card number is ever read aloud or typed into a call, by the agent or by the caller.
Every payment, whether it started on a call or from a link you sent yourself, lands on a public page at a link like cypherlm.com/pay/<token>, where the caller sees exactly what they owe, what it is for, and every way they can pay. The same page works for a one-off request your agent created mid-call and for a reusable link you share for something you bill regularly, a deposit, a booking fee, or a service package.
This guide covers deciding when to take payment on a call, setting up your payment methods, creating one-off requests and reusable links, what a caller actually hears, confirming manual payments once the money lands, reconciling your payments list, and the compliance-minded habits worth keeping around money and calls. Scripts, a method comparison table, a setup checklist and a reconciliation checklist are included throughout. This guide does not quote prices for Cypher LM itself; see pricing for that.
01
When to take payment on a call
Not every call is the right moment to ask for money, but a surprising number are, and Cypher P is built for the ones that are. The clearest cases are a deposit to hold a booking, a fee due at the time of booking rather than at the appointment itself, and an outstanding balance a returning customer is calling about anyway. In each of these, the caller is already engaged and already expecting to pay something; the only question is whether you make that easy there and then, or leave it for a follow-up that may or may not happen.
A deposit tied to a booking is often the single highest-value moment to ask. Someone booking an appointment through your bookings skill has just committed to a time; asking for a deposit in the same breath, while they are still engaged in the conversation, converts far better than a separate email sent after the call asking for the same thing. A booking fee works the same way for services where the booking itself, not just the appointment, carries a cost.
An outstanding balance is a different shape of call: the customer is often calling about something else entirely, a question, a follow-up, a complaint, and a payment reminder in the middle of that conversation can land badly if it is not handled with care. The description on the payment request should name exactly what the balance is for, so the caller sees a clear, specific reason rather than a bare amount that reads as a surprise.
Why mid-call beats a follow-up email every time
A caller who has just agreed to pay, out loud, on a call is at their most willing moment to actually do it. The same request sent by email an hour later competes with everything else in their inbox and loses a meaningful share of the people who would otherwise have paid immediately.
Why the description matters as much as the amount
A payment request that says "Payment" tells the caller nothing. One that says "Consultation deposit" or "Balance for website package" gives them a reason to trust the request and pay it without calling back to ask what it was for.
When it is better not to ask on the call
A caller who is upset, disputing a charge, or clearly not ready to commit is not a good candidate for a payment request mid-conversation. Resolve the actual concern first; a payment link sent into that moment tends to make the caller feel pressured rather than helped.
A two-person physiotherapy clinic
A physiotherapy clinic takes a booking fee for first appointments and an outstanding balance for a course of sessions billed as a package. The agent asks for the booking fee the moment a new patient's consultation is confirmed, and for the remaining balance only when an existing patient calls specifically about billing.
A small web design studio
A two-person web design studio takes a deposit before starting a project and a final balance once the work is handed over. The agent requests the deposit the moment a new client agrees to the scope on a call, and sends the final balance as a reusable link once the studio marks the project complete, rather than asking for it by voice again.
There is also a quieter category worth planning for: a returning customer who calls with a question unrelated to money, and simply mentions, in passing, that they still owe you for something. Training your agent's knowledge base to recognise that moment, and to offer a payment link once the actual question has been answered, keeps the conversation in the right order rather than leading with a request for money before the caller has been helped.
02
Setting up how you get paid
Before any agent can send a payment link, your business needs at least one way to actually get paid, set up once under Payments › Settings. Cypher P supports card payments through your own Stripe account, plus bank transfer, JazzCash and Easypaisa, which are always available as manual methods regardless of whether Stripe is connected.
Connecting Stripe means pasting your own Stripe secret key, the one starting with sk_live_, or sk_test_ while you are trying it out, into the Stripe card in Settings. Cypher LM checks the key directly with Stripe before accepting it and stores it encrypted; card payments taken through it go straight to your own Stripe account, with Stripe's own fees applying as they would for any Stripe integration. Disconnecting Stripe at any point stops new card payments but leaves every payment already made exactly as it was.
Manual methods, bank transfer, JazzCash and Easypaisa, work differently: you fill in only the details you actually use, bank name, account title, account number, IBAN, JazzCash number, Easypaisa number, and the caller sees whichever of those you have filled in on the payment page, along with a reference code to include with their transfer. Because there is no live confirmation from a bank transfer the way there is from Stripe, these payments move to "paid" only once your team marks them so, after you have actually seen the money arrive.
A default currency, PKR or USD, is also set in Settings and applies to new payment requests and links unless a specific request overrides it. Finally, the same Settings area is where you choose which agents can take payments on calls at all, a per-agent switch separate from whether Stripe or manual methods are connected, so an agent only gets the payments skill, and its tools, once you have deliberately turned it on for that agent.
Why Stripe is connected per business, not centrally
Each business keeps its own Stripe account and its own relationship with Stripe, including its own payout schedule and its own fees. Nothing about how a business is paid runs through a shared account, which keeps every business's money entirely its own.
Why manual methods stay available even with Stripe connected
Not every customer has or wants to use a card, and bank transfer, JazzCash and Easypaisa remain common ways to pay in practice. Keeping them available alongside Stripe, rather than instead of it, means a caller who cannot or would rather not pay by card is still offered a real way to pay.
Why a payment method and the payments skill are two separate switches
Having Stripe or a manual method connected makes paying possible on the public pay page in general. Turning the payments skill on for a specific agent is a separate decision about which conversations are allowed to end in a payment request being created at all.
| Method | Needs set up | Caller sees | Confirmed by |
|---|---|---|---|
| Stripe (card) | Your own Stripe secret key | A secure checkout page | Automatically, the moment Stripe confirms the charge |
| Bank transfer | Bank name, account title, account number, IBAN | Account details plus a reference code | Your team, once the transfer arrives |
| JazzCash | JazzCash number | Account number plus a reference code | Your team, once the transfer arrives |
| Easypaisa | Easypaisa number | Account number plus a reference code | Your team, once the transfer arrives |
Payment setup checklist
- Default currency set to match how you actually quote prices
- Stripe connected, if you want card payments, and tested with a small amount first
- Bank transfer, JazzCash or Easypaisa details filled in for whichever you actually accept
- At least one agent switched on to take payments on calls
- A first real payment request sent and watched through to paid, to confirm the whole path works
A connected Stripe account also brings a detail worth knowing about before your first real customer hits it: Stripe's own test mode. Using a test key first lets your team walk through the entire path, request, checkout page, successful charge, receipt, refund, without any real money moving, which is the safest way to be confident the setup is right before switching to a live key.
03
Creating payment requests and reusable links
Cypher P gives you two related but distinct ways to ask for money: a one-off payment request, created on a call by your agent or by you directly from the dashboard, and a reusable payment link, set up once and shared anywhere you like, on your website, in an email signature, or over WhatsApp, for anyone to pay without you creating anything new each time.
A one-off request, created from New payment request in the dashboard, asks for an amount, a currency, a short description of what it is for, and, optionally, a customer name and email so the link can be emailed directly rather than only copied and sent by hand. It creates a secure, single-use link the customer pays through once; if no email is given, the request is still created and its link can be copied and shared any way you choose.
A reusable payment link, created from the Payment links tab, is built for something you bill the same way more than once: a fixed amount with a name and description, or an open amount link where the customer enters however much they are paying themselves, useful for variable balances or donations. Each link can be turned on or off without deleting it, and its page shows how many times it has been used, so a link for "Consultation fee" quietly tells you how often it is actually being paid through.
On a call, the same request is created through the agent's payment tool: it asks for the amount and what the payment is for, together with the caller's email if they want the link emailed, and then tells the caller the link is ready, on their screen for a web call, in their email as well if one was given, without ever reading the link aloud as a string of characters, and without ever asking for or repeating card details over the call itself.
Why one-off requests and reusable links solve different problems
A one-off request fits something specific to one customer and one moment, a deposit for the booking just made. A reusable link fits something repeatable across many customers over time, a standard consultation fee anyone can pay the same way. Using the wrong one for the job usually shows up later as a payments list that is harder to make sense of.
Why an open-amount link exists at all
Not everything you collect money for has a fixed price, a variable balance, a top-up, or a flexible contribution are all real cases where forcing a fixed amount would just mean creating a new link every time the number changes. An open-amount link lets the customer enter the right figure themselves on the same page.
What happens to a link's history if you turn it off
Turning a payment link off stops anyone new from paying through it; it does not touch or hide payments already made through it, which stay exactly where they are in your payments list, still attributed to that link.
Deciding between a fixed amount and an open amount on a link
A fixed-amount link is the right default for anything with a set price, a consultation fee, a standard package. An open-amount link suits a situation where the right number genuinely depends on the customer, a variable balance, a top-up to an existing account, or a contribution where you would rather not set a ceiling or a floor. When in doubt, a fixed amount is easier for a customer to trust at a glance, since they are not left wondering how much they are expected to enter.
Both kinds of link can be edited after they are created, a name, description or amount changed without needing to issue a new link and ask everyone who already has the old one to switch. That matters most for a link printed on something physical, like a receipt or a sign, where reissuing it every time a price changes would be impractical.
Payment request on a call
Put this guide to work
Build it in your own account
Start a 7-day free trial with every Cypher LM product included, or book a demo and we will walk you through it on a live call.
04
What the caller hears, and what never gets said
The single rule that shapes every payment conversation is simple: a card number is never read aloud, and it is never asked for, by the agent, to the caller, under any circumstance. Payment always happens on the secure page the link opens, away from the call itself, whether that is a card form through Stripe or a set of bank, JazzCash or Easypaisa details with a reference code to include.
On a web call, the payment card appears directly on the caller's screen the moment the agent creates the request, so there is often no need to say the link aloud at all; the agent simply points to it being there. On a phone call, where there is no screen to show anything on, the agent relies on the email instead, which is exactly why it asks for an email up front when a payment is coming, and will say plainly that the link has been sent there if an address was given.
Where a caller has no email on file and is on a plain phone call, the agent is honest about the gap rather than trying to read a link aloud: it explains that a team member will follow up with a way to pay, or asks for an email there and then so the link has somewhere to go. This is also the point at which the agent explains what paying actually involves, "you can pay by card, or by bank transfer, JazzCash or Easypaisa," so the caller knows their options before they have even opened the link.
Why the link itself is never read aloud
A payment link read character by character over a call is both unpleasant to listen to and genuinely easy to mistype on the other end. Showing it on screen or sending it by email removes that entire category of mistake.
Why asking for an email becomes natural once payment is mentioned
Once a caller has agreed to pay something, asking "what's the best email for the link" reads as a small, obviously useful step rather than an unrelated request for personal information, which is part of why it works well to ask for it in the same breath as confirming the amount.
What a caller should never be asked to say out loud
Full card numbers, expiry dates and security codes are never requested by an agent, in any form, on any call. If a caller offers to read a card number aloud anyway, the right response is to redirect them to the secure page rather than taking the number down.
What the caller sees if they open the link later, after the call
The link does not expire the moment the call ends. A caller who says they will pay "in a few minutes" and does so after hanging up still lands on the same secure page with the same amount and description, and the payment still appears in your dashboard exactly as if it had been paid while the call was still open.
What your agent should never do around payment
- Ask a caller to say a card number, expiry date or security code aloud
- Read a payment link aloud as a string of characters
- Guess at an amount instead of confirming it with the caller first
- Mark or imply a payment is complete before the page itself confirms it
- Continue past a caller who says they are not ready to pay, without offering to send the link for later instead
Caller on a phone call with no email on file
05
Confirming manual payments and reconciling your list
Stripe payments confirm themselves: the moment Stripe reports a successful charge, the payment moves to paid in your dashboard and a receipt can be emailed automatically if the customer gave an email. Bank transfer, JazzCash and Easypaisa payments need a human step, because none of those methods tells Cypher LM anything on their own; your team has to see the money land and then mark the payment as paid.
The customer's part of a manual payment is a simple one on the public pay page: once they have sent the transfer, they tap to say they have paid, which flags the payment with a "customer says paid" badge in your list, a useful signal, but not confirmation on its own. Your team's part comes after: once you have actually checked your bank, JazzCash or Easypaisa account and seen the matching amount arrive, you mark the payment as paid from the dashboard, optionally attaching a transaction ID for your own records, and the customer is sent a receipt if they gave an email.
Reconciling your payments list, matching what the dashboard shows as paid against what has actually landed in your accounts, is realistically a weekly habit rather than a daily one for most businesses, except around your busiest periods. The list can be filtered by status, so pending manual payments are easy to isolate from everything already settled, and each entry shows its source, booked on a call, from a payment link, or sent by you directly from the dashboard, which helps when you are trying to trace an amount back to where it actually came from.
A payment can also be cancelled before it is paid, which stops its link from working, and a Stripe payment can be refunded directly from the dashboard, sending the money back to the customer's card through Stripe; this cannot be undone, so it is worth being certain before confirming it. Manual payments, having no live connection to a bank, are not refunded the same way inside the dashboard and are instead handled the way your business would handle any manual refund, directly with the customer.
If you send formal invoices as part of how you bill customers, see creating and sending invoices on the Cypher LM blog for that separate workflow; it sits alongside, rather than inside, the payment requests and links covered in this guide.
Why manual payments need a human step at all
There is no bank, JazzCash or Easypaisa API in the loop telling Cypher LM a transfer has landed, so the only reliable confirmation is someone on your team actually seeing the money arrive and saying so. The "customer says paid" badge is a helpful nudge to go check, not a substitute for checking.
Why a transaction ID is worth attaching when you mark something paid
A reference from your bank or wallet app, noted against the payment at the moment you confirm it, saves real time later if a customer disputes having paid or if your own bookkeeping needs to match a dashboard entry back to a specific bank transaction.
Why source matters when you are reconciling
Knowing a payment came from a call, a link, or was entered by you directly tells you not just how much money arrived but which part of your operation produced it, which matters when you are deciding where a payments skill is actually earning its keep.
Confirming a manual payment reached you
Weekly reconciliation checklist
- Pending manual payments filtered and reviewed against your actual bank, JazzCash and Easypaisa activity
- Every matched transfer marked as paid, with a transaction ID noted
- "Customer says paid" entries checked, not assumed, before being marked paid
- Cancelled and expired requests reviewed for any that should be followed up instead of left closed
- Any refund double-checked for amount and customer before it is confirmed
06
Staying compliance-minded, and what to do next
Money moving over a phone call deserves a particular kind of care, and most of it comes down to a short list of habits rather than anything complicated. Never ask for or repeat a full card number, expiry date or security code on a call, in either direction; if a caller offers to read one aloud, redirect them to the secure payment page instead. Always let the payment page itself handle the actual transaction, whether that is a Stripe checkout or a set of manual transfer details, rather than trying to confirm or process anything by voice.
Be precise with descriptions on every request and link, "Consultation deposit," "Balance for order #142," rather than a bare "Payment," both because it is clearer for the customer paying and because it makes your own records easier to make sense of months later. Keep your payment settings current: a Stripe key that has stopped working, or bank details that have changed, should be updated as soon as you know about it, since a caller hitting a broken payment method mid-call is a far worse experience than a short delay while you fix it.
Treat refunds and cancellations as deliberate actions, not routine ones. A Stripe refund cannot be undone once confirmed, and a cancelled request simply stops its link from working rather than quietly resolving anything with the customer, so a cancellation is usually worth a quick message to them explaining what happens next. And keep the per-agent payments toggle reviewed the same way you would review any other skill: an agent that should not be asking for money on calls should have the skill off, not merely be trusted not to use it.
It is worth building this same discipline into whatever you write in your agent's knowledge base about payments. Spell out, in plain language, exactly what the agent is and is not allowed to do around money: which amounts it can ask for without checking with you first, how to describe what a payment is for, and the firm line that card details are never taken by voice. An agent that behaves well around payments almost always does so because its instructions were specific about money from the start, not because it inferred the right behaviour on its own.
To recap: decide deliberately which calls are the right moment to ask for payment, deposits, booking fees and clear outstanding balances are the strongest candidates; connect Stripe and whichever manual methods you actually accept before any agent needs to use them; create one-off requests for a single moment and reusable links for anything repeated; let your agents point callers to the secure page rather than ever handling card details by voice; confirm manual payments only once you have actually seen the money arrive; and reconcile your payments list on a regular rhythm rather than only when something looks wrong.
- Connect Stripe, if you want card payments, and fill in the manual methods you actually accept.
- Set your default currency and turn the payments skill on for the agents that should use it.
- Send a first real payment request, by card and by a manual method, and follow it through to paid.
- Build your reusable links for anything you bill the same way more than once.
- Set a weekly time to reconcile pending manual payments against your bank, JazzCash and Easypaisa activity.
If payment is coming up around a booking, read the Cypher S scheduling guide for how deposits line up with the booking conversation itself. And if you have not yet built the agent that will carry the payments skill, start with the guide to building your first voice agent; its knowledge base is where you will want your pricing and policies to live before any agent is asked to talk about payment at all.
