Get Paid on Calls with Cypher P

This path is for any business that collects payment from customers, whether that is a deposit, a service fee, or a full invoice, and wants to stop losing time between the call where someone agrees to pay and the moment the money actually arrives. It covers Cypher P, the part of Cypher LM that requests and tracks payment, from the request itself through to the receipt.

In most businesses, payment is handled as a separate step after the call: someone has to remember to send an invoice, the customer has to find it later, and by the time it is paid, the original conversation is a distant memory. Each one of those gaps is a chance for the payment to be delayed or forgotten entirely, and each additional step between agreement and payment is an opportunity for the customer's attention to move somewhere else.

Cypher P closes that gap by letting your agent request payment while the customer is still on the call and still engaged. The moment they agree to pay, a secure payment link is generated and sent to them, so the step from "yes" to "paid" is as short as possible. A customer like Maria Lopez who agrees to a deposit while still on the phone is far more likely to complete that payment within minutes than if she is asked to wait for a separate email that may arrive after she has moved on to something else.

This also removes an awkward moment from the call itself: nobody has to read out or take down card numbers verbally, which is neither secure nor comfortable for either side of the conversation. The secure link handles that exchange on a dedicated page instead, while the call continues or wraps up normally.

The lessons that follow walk through how a payment request actually works, what options the caller sees, how you turn this capability on for an agent, and what you can see afterward in the Payments section of your dashboard.

As with scheduling, none of this requires your team to manually chase anyone. Once the feature is enabled, requesting and collecting payment becomes part of the call itself rather than a separate administrative task someone has to remember to complete later in the day.

This path also matters for businesses that have historically treated payment collection as an awkward afterthought, something squeezed in at the end of a call almost apologetically. Because Cypher P is designed around the payment link rather than reading out card numbers, requesting payment can feel like a normal, professional part of the conversation rather than an uncomfortable interruption to it.

By the end of this path, you will understand the full lifecycle of a Cypher P payment: how a request is made, what the caller sees and can choose between, how a reusable link differs from a one-off request, and how to turn the feature on and keep track of what has come in through your dashboard.

When it makes sense in the conversation, such as confirming a deposit or settling a balance, your agent can request payment directly. Rather than trying to take card details over the phone, the agent sends the caller a secure payment link, which keeps sensitive payment information out of the call itself and inside a dedicated, secure page built for that purpose.

The caller opens the link and sees the amount being requested along with a way to pay. If your business has Stripe connected, the caller can pay by card directly on that page, entering their details into a standard, secure checkout rather than reading them aloud to a person or an agent.

If Stripe is not connected, or the customer prefers another method, the link instead shows manual payment instructions, so a business that has not yet set up card processing, or a customer who simply prefers a different method, is never left without an option.

Manual payment options

• Bank transfer, with your account details
• JazzCash
• Easypaisa

Whichever method is used, the link includes a reference code tied to that specific payment request. This reference code is what connects a manual transfer back to the right call and the right amount, so you are not left guessing which incoming transfer corresponds to which request when you reconcile payments later, especially if several customers are paying through the same manual method around the same time.

The payment's status is shown live on the link itself, so the caller can see whether it is pending or complete, and the same status is visible on your side in the Payments dashboard section, covered in the final lesson of this path. This means both sides of the transaction are looking at the same up-to-date information rather than one party waiting to hear from the other.

A customer like James Carter who agrees to pay a deposit over the phone might not finish the payment the instant the call ends; he may want to double check the amount or confirm with someone else first. Because the link stays live and the status updates whenever he does complete it, your team does not need to call him back repeatedly to check, and can instead simply glance at the Payments tab to see whether the deposit has come in.

This same flexibility is what makes mid-call payment requests practical across very different kinds of businesses. A quick service fee and a larger deposit both move through the identical request-and-link process, with only the amount and the chosen payment method differing between them.

Not every payment request has to originate from a live call. Cypher P also lets you create reusable payment links ahead of time, which is useful for a fixed fee you charge regularly, such as a standard consultation rate or a recurring service charge. Instead of asking your agent to generate a one-off request each time, you share the same link wherever it is useful: in an email, on an invoice, or on your website.

A reusable link behaves the same way a mid-call request does once someone opens it. They see the amount, they can pay by card if Stripe is connected, or they can follow manual instructions for bank transfer, JazzCash, or Easypaisa, each with its own reference code so individual payments stay distinguishable even when many people use the same link for the same standard fee.

Once a payment completes, whether through a card charge or a manual method you have marked as paid, a receipt is generated. This gives the customer a clear record of what they paid and when, and gives your business a paper trail without anyone having to draft a receipt by hand each time a payment comes in.

Manual payments need one extra step on your side: since a bank transfer or a JazzCash or Easypaisa payment does not confirm itself automatically the way a Stripe card charge does, you confirm receipt yourself by marking the payment as paid once you have verified it arrived using the reference code. This keeps your records accurate without requiring a direct integration into every bank or mobile payment provider.

If a payment needs to be reversed, whether the customer changed their mind or a charge was made in error, Cypher P also supports issuing a refund. This keeps the full lifecycle of a payment, from request through to refund, inside the same system rather than split across your payment processor and separate internal records that someone has to keep in sync by hand.

Keeping receipts and refunds inside Cypher P also means that when a customer calls back asking about a past payment, your team can pull up the full record, including the reference code and current status, instead of digging through a separate accounting system to answer a simple question.

Reusable links are also a convenient way to standardize pricing across a team. Rather than each staff member quoting a fee verbally and hoping it matches what was quoted last time, everyone can point a caller to the same link, which always reflects the current, correct amount for that service.

For a business that sells a small number of fixed-price offerings, setting up a reusable link for each one early on means payment collection is essentially solved from day one, with only the occasional mid-call request needed for anything outside those standard amounts.

Cypher P is not active by default on every agent. To let a specific agent request payment during calls, you turn on the "Take payments" toggle in that agent's settings, found alongside the other "What this agent can do" toggles in the Agents section of your dashboard. This means you can be deliberate about which agents handle payment and which do not, rather than enabling it platform-wide for every agent regardless of whether it needs the feature.

Before payments can actually process by card, your business connects its Stripe account in Settings, under Integrations. If you prefer not to use Stripe, or want to offer manual methods as a baseline, you can still provide bank transfer, JazzCash, or Easypaisa details, which will be shown to callers as their payment options instead, so card processing is a choice rather than a requirement to use Cypher P at all.

Every payment request, completed payment, and reusable link you have created lives in the Payments section of your dashboard, organized into Overview, Payments, Links, and Settings. Overview gives you a snapshot of activity, Payments lists individual transactions and their status, Links is where your reusable links are managed, and Settings is where your Stripe connection and manual payout instructions are configured.

Because every payment carries its reference code and status, reconciling what has come in against what was requested is a matter of checking the Payments tab rather than cross-referencing call notes with your bank statement line by line at the end of the month.

For a business just getting started with Cypher P, a sensible approach is to turn on the toggle for a single agent first, confirm that a test payment link behaves as expected, and then extend it to other agents once you are comfortable with how requests, confirmations, and receipts flow together.

From here, a natural next step is the Cypher LM Workflows path, which covers how payment receipts and other confirmations are sent out automatically through your connected Google account, tying payments into the same automation system that handles bookings and recaps.

It is also worth checking the Payments tab periodically even when nothing seems to need your attention. A quiet review of recent activity is often how a business catches a manual payment that was never marked as paid, or notices that a particular reusable link has stopped generating activity and might need to be shared somewhere new.

Finally, remember that enabling "Take payments" is an agent-level decision, not an account-wide one. A business running several agents for different purposes, such as one for general support and one for sales, can choose to give payment capability only to the agent where it is actually relevant, keeping the feature focused rather than available everywhere by default.