What Is Pay by Link and How Merchants Use It
Learn what pay by link is, how merchants use it for invoices and agent-assisted sales, and what security and UX trade-offs to weigh.
A customer has just agreed to buy. The conversation happened on WhatsApp, over the phone, or in a support chat. The offer is clear, the intent is warm, and then the merchant has to decide how to collect the money without damaging the moment.
That pause is where revenue leaks. Typing card details into a chat feels unsafe, moving the buyer to a generic checkout can break the relationship, and sending an invoice often creates another task for someone who already said yes. Pay by link exists to close that gap: create a secure payment URL, send it through the channel where the conversation happened, and let the customer complete payment on a hosted page.
The useful question isn't only “what is pay by link?” It's whether the payment link fits the sale, how the business should secure it, and whether the payment method captured today can support recurring revenue tomorrow.
Table of Contents
- The Moment After the Customer Says Yes
- What Pay by Link Actually Means
- Where Pay by Link Earns Its Place
- Pay by Link Versus a Public Checkout Page
- Security, Trust, and the PCI Question
- How Merchants Implement Pay by Link
- How Pay by Link Fits Inside the FloPay Stack
- A Short Decision Filter Before You Ship a Link
The Moment After the Customer Says Yes
A sales representative closes a high-end personal coaching client over WhatsApp. The customer agrees to the monthly plan and asks how to pay.
The representative has several poor options. They can ask the customer to read a full card number aloud, send an invoice that may sit in an inbox, or direct the customer to a public checkout page that feels disconnected from the personal conversation. Each option adds a decision at exactly the point where the customer has already made one.
A payment link gives the representative a cleaner move. They select the correct plan, generate a customer-specific URL, and send a short message explaining what the customer is buying, the price, and what happens after payment. The buyer taps the link, reaches a hosted checkout page, authenticates if the bank requires it, and completes the transaction without exposing raw card details to the representative or the merchant's chat system.
Commercial rule: The best payment flow is often the one that preserves the buying context instead of forcing a warm buyer into a colder funnel.
This is why pay by link is more than a remote-payment convenience. It's a revenue capture tool for warm conversations. The merchant can collect payment while intent is visible, rather than hoping the customer returns to a storefront or remembers to settle an invoice.
The format also supports operational visibility. Modern payment-link products can track a link from creation through completion, including status, payment date, amount, order reference, and payment method, as described in Verifone's payment-link documentation. The link should therefore be treated as part of a payment workflow, not as a disposable message.
What Pay by Link Actually Means
Pay by link is a payment flow in which a merchant generates a secure URL connected to a payment request, then sends that URL to a customer through email, SMS, WhatsApp, a support conversation, or another channel. The customer opens the link and pays on a provider-hosted checkout page.
The URL can carry useful context, such as the amount, currency, customer reference, order information, payment method options, and whether the link can be used once or multiple times. The merchant doesn't need to build a separate checkout page for every sales channel. The provider handles the payment form, authentication, encryption, and transaction processing.
The lifecycle in practical terms
- Create the request. The merchant system or payment platform creates a link with the correct commercial details.
- Add context. The request can include an order reference, customer information, description, or recurring-payment intent.
- Send the URL. A sales agent, billing team, or automated workflow delivers it through the channel the customer already uses.
- Open hosted checkout. The buyer reviews the request and enters or selects a payment method on the hosted page.
- Authenticate and authorize. The issuing bank may request additional authentication, such as a bank-app approval or other verification.
- Confirm and reconcile. The payment provider reports the final status, while the merchant receives the information needed to fulfill the order or update accounts receivable.
A payment link is not a storefront. It doesn't need product discovery, persistent cart state, or broad navigation. It's a thin commerce surface attached to a specific buying moment.
A PDF invoice is different. It can describe an amount due, but it isn't necessarily a live authorization flow with link-level status tracking. A public checkout page is different again. It serves open discovery and self-serve browsing, while a payment link assumes that the buyer and merchant already understand the transaction.
For merchants, the distinction matters because the value comes from the data attached to the URL and the workflow around it, not from the URL alone.
The hosted flow is also compatible with tokenization. In a provider implementation such as Cybersource's pay-by-link overview, the customer's payment details can be tokenized for future use, subject to consent and applicable scheme rules. That turns a one-time collection event into a possible foundation for renewals and follow-on charges.
A visual walkthrough can make the sequence easier to understand:
Watch a visual walkthrough of the pay by link sequence
Where Pay by Link Earns Its Place
Pay by link works best when the customer already has a reason to pay and the merchant needs to remove the final obstacle. It isn't a universal replacement for checkout. It's a targeted way to reduce the distance between agreement and capture.
| Use Case | Friction Removed | Primary Metric Moved |
|---|---|---|
| Invoice and B2B billing | Replaces a separate payment instruction with a direct payment path | Collection speed and outstanding receivables |
| Agent-assisted sales | Avoids reading card details aloud or moving to a terminal | Completion from qualified conversations |
| Renewals and recovery | Gives the customer a contextual payment action instead of a generic portal | Renewal completion and recovered revenue |
Invoice and B2B billing
A finance team can attach a payment link to an invoice email or send it after a billing conversation. The customer doesn't have to search for bank details, log into an unfamiliar portal, or ask the accounts-payable team to interpret a static document. The link gives the recipient a direct route to authorize the payment.
This is particularly useful when the invoice is clear but the payment process is slow. The link doesn't solve every procurement requirement, but it can shorten the path for customers who are already authorized to pay.
Agent-assisted and field sales
Contact-center agents, account managers, and field sellers often own the trust that drives the sale. They shouldn't need to handle raw card numbers to finish it. A hosted payment page lets the agent remain in the conversation while the customer completes the sensitive step independently.
That model also suits support-led commerce. A customer who contacts support about an upgrade, replacement, or add-on can receive a payment request in the same interaction instead of being pushed into a separate acquisition funnel.
Renewals and recovery
A renewal message with a clear payment action is more useful than a vague reminder to visit an account portal. The same principle applies to payment recovery. A customer whose payment failed may respond better to a specific, branded link tied to the outstanding plan than to a generic “update your billing details” instruction.
Pay by link is usually the wrong tool for cold acquisition, high-volume self-serve discovery, or complex baskets that need persistent cart state. Those jobs belong to a public checkout or storefront. Use a link when the transaction is already understood.
Pay by Link Versus a Public Checkout Page
The decision isn't “which payment method is better?” The decision is where the sale happens.
A public checkout page is designed for buyers who may still be browsing. They can arrive from search, advertising, email, or a product page, compare options, build a basket, and decide whether to continue. That reach matters for acquisition.
A payment link is designed for a buyer who has already crossed most of that distance. The merchant can send it from the CRM, an invoice workflow, a sales conversation, or a support interaction. The link keeps the customer in the context where the commercial decision was made.
| Criterion | Pay by Link | Public Checkout Page |
|---|---|---|
| Speed to payment | Direct route from an existing conversation or invoice | Requires navigation through a broader buying journey |
| Buyer context | Usually tied to a specific customer, offer, or order | Built for open discovery and self-serve selection |
| Branding | Can use a branded hosted page when configured correctly | Usually offers broader control across the entire site |
| Fraud exposure | A private URL can limit exposure, but it can still be forwarded or impersonated | Public surfaces are exposed to automated testing and unwanted traffic |
| Operational fit | Strong for invoices, agents, renewals, and curated offers | Strong for acquisition, browsing, carts, and product comparison |
| Main trade-off | Less suitable for discovery and complex cart journeys | More steps between intent and payment |
Speed is the obvious advantage, but control of the customer moment is more important. A coaching business that sells through personal conversations shouldn't force every prospect into a mass-market storefront. A B2B account manager shouldn't lose the thread of a negotiation because the buyer has to find the correct checkout page.
Branding also affects trust. The page should look like the business the customer believes they're paying, with a clear description and next step after payment. A generic page can create hesitation, particularly when the link arrives through a personal message.
Run the metrics separately. Public checkout conversion reflects discovery, product selection, cart behavior, and payment. Pay-by-link completion reflects the quality of the preceding conversation, the clarity of the offer, delivery timing, and trust in the message. Combining the two hides the decision you need to make.
Security, Trust, and the PCI Question
A payment link isn't automatically trustworthy because it uses HTTPS. It's still a payment URL, and payment URLs can become phishing targets.
A recipient can forward a link, take a screenshot, or receive a convincing imitation from someone impersonating the merchant. If a link is long-lived, reusable, or detached from the original customer and amount, the business has created a transaction-initiation risk rather than a controlled payment request. Adyen's customer guidance makes the consumer-side point clearly: unexpected links should be treated cautiously, the sender should be verified, and payment should happen only on a secure page.
Controls that should be standard
- Use a short expiry. A payment request should remain active only for the time needed to complete the transaction.
- Bind the request to the transaction. Lock the amount, currency, order reference, and intended customer where the platform supports it.
- Prefer single-use links. Reusable links can suit standard recurring charges, but they need a clear business reason and tighter monitoring.
- Protect the sending channel. An attacker who compromises email, SMS, or a staff account can misuse a legitimate workflow.
- Make the sender obvious. The message should identify the merchant, purchase, amount, and post-payment outcome.
- Keep an audit trail. Record who created the link, where it was sent, when it was opened, and whether payment completed.
Hosted payment pages can reduce the merchant's PCI DSS exposure because the provider handles card capture, encryption, and tokenization. They don't eliminate the merchant's responsibilities. Staff mustn't handle raw card data, and the business still needs appropriate controls around its systems, users, messages, and payment operations.
Security principle: Treat a payment link like cash. Give it a clear owner, a limited shelf life, and a traceable path to the person who should use it.
Card-on-file design deserves the same care. A processor-neutral card-on-file layer can help a merchant plan for future routing without bringing raw card details into its own systems, but token portability depends on the providers, consent model, and technical architecture involved.
How Merchants Implement Pay by Link
Most merchants can choose among three practical implementation patterns. The right choice depends on how quickly the business needs to collect payment, how much control the product team needs, and whether the link is the beginning of a recurring billing flow.
Hosted payment page
The provider creates the secure page and returns a unique URL. This is the fastest path to launch and the lowest engineering burden. A sales or operations team can often create links from a dashboard, while an API can connect issuance to an invoice or customer record.
The trade-off is control. The merchant depends on the provider's page capabilities, branding options, payment methods, webhooks, and reporting model. Review those limits before committing the link flow to a critical revenue process.
SDK or headless checkout
An SDK lets the merchant place payment capture inside its own web or app experience. A link might open a branded payment sheet or a custom page while the provider still handles tokenization and sensitive payment operations.
This approach offers stronger control over the customer experience, but it requires engineering ownership. Teams must manage session creation, error states, authentication handoffs, event handling, and reconciliation. It's appropriate when payment is part of a broader product journey rather than a simple request sent by an agent.
API-issued links
The merchant's CRM, billing system, or agent console requests a payment link from an API, receives the URL, and sends it through email, SMS, WhatsApp, or chat. This pattern is powerful because it connects the payment event to the system where the customer relationship already lives.
Use hosted checkout links when the priority is a fast, controlled launch. Start with a sandbox transaction, then test the full path through live payment, webhook confirmation, refund handling, and reconciliation before expanding the flow.
A sensible rollout has stages:
- First, prove the path. Create a link, pay with test scenarios, confirm status updates, and check the merchant record.
- Then, connect operations. Make sure fulfillment, invoice status, customer notifications, and reconciliation respond to the final payment state.
- Next, vault eligible methods. Capture consent and tokenize payment methods for future use where the customer relationship requires it.
- Finally, extend the use case. Apply the same foundation to renewals, retries, payment recovery, and relevant upsells.
The mistake is treating pay by link as a one-off campaign feature. The link is often the front door of a recurring billing architecture.
How Pay by Link Fits Inside the FloPay Stack
The link is the visible part of the transaction. The more valuable asset is what happens to the payment method after the customer pays.
In a FloPay flow, the customer opens a hosted payment page and enters card details away from the merchant's operational systems. The provider tokenizes the payment method, and the resulting credential can be stored in a secure, processor-neutral vault for permitted future transactions. The merchant doesn't receive or manage the full card number, known as the PAN.
That architecture matters for subscriptions. A customer may approve the first payment but later encounter a bank decline, an expired card, a transaction-not-allowed response, or an authentication requirement during a rebill. If the saved payment method exists only inside one gateway, the merchant has limited room to route the retry elsewhere.
A vault-backed approach separates the customer's saved payment method from the gateway used for a particular transaction. FloPay can then support payment orchestration across connected processors, payment methods, and routing rules. It doesn't guarantee approval, and token portability depends on provider support and applicable controls, but it gives the merchant a stronger basis for fallback and recovery.
The commercial distinction: The payment link captures today's payment. The vault can support tomorrow's renewal, retry, and provider decision.
Processor concentration risk becomes concrete. Keeping Stripe, Adyen, or another processor in the stack isn't the problem. Making one provider the only place where checkout logic, transaction history, and saved payment methods exist creates gateway dependency and a potential single point of failure.
A merchant preparing for multi-provider readiness should ask:
- Can the business trace the payment independently of one gateway dashboard?
- Can a saved payment method support permitted transactions through another connected processor?
- Can renewal failures trigger structured recovery rather than repeated blind retries?
- Can a future agent-assisted or machine-to-machine payment flow use controlled, tokenized credentials?
FloPay's vault is positioned as part of that orchestration layer. The objective is practical, payment resilience today and a foundation for delegated agent payment flows tomorrow.
A Short Decision Filter Before You Ship a Link
A payment link earns its place when it solves a specific capture problem. Don't launch one because it sounds modern or because a processor makes the feature available.
Use five filters.
The customer expects the request
The strongest context is a warm conversation, an approved invoice, a renewal discussion, or a support interaction with a clear offer. If the recipient doesn't recognize the transaction, the link will look like a phishing attempt. For cold acquisition, use a public product and checkout journey instead.
The domain supports trust
Use a defensible branded destination and make the message identity obvious. The customer should know who sent the request, what it covers, and where payment leads after completion. A payment page that looks unrelated to the conversation introduces avoidable doubt.
The link has a controlled lifetime
Set an expiry that matches the commercial situation. Use single-use or customer-bound behavior for individual transactions. A reusable URL may be appropriate for a standard payment request, but it shouldn't become a public shortcut to an account or product without governance.
The business decides whether to vault
If the customer is buying a subscription, renewal, or service with likely follow-on charges, decide before launch how consent, tokenization, and future merchant-initiated transactions will work. If the payment method will never be reused, don't create unnecessary operational complexity.
The event can be measured
Log the link creation, delivery channel, opening, payment result, and related customer or order reference. Without that trail, the team can't separate a weak offer from a delivery problem, a trust issue, or a payment decline.
Go or no-go test: If the buyer is warm, the amount is clear, the link is controlled, and the payment outcome is traceable, run the pilot.
Start with one invoice or agent-assisted flow end to end. Confirm the customer experience, payment status, reconciliation, refunds, and failure handling before applying the pattern to renewals. Then measure the journey separately from public checkout, because the two flows serve different buying conditions.
The market has moved beyond treating pay by link as a minor gateway feature. Industry estimates now treat hosted, mobile-oriented payment collection as a tracked payments category, according to MarketIntelo's pay-by-link market estimate.
The recommendation is straightforward. Use pay by link to capture warm intent, secure the delivery and expiry rules, and connect the first successful payment to a vault and orchestration strategy instead of leaving recurring revenue trapped in one gateway.
FloPay supports hosted payment links, secure payment data vaulting, and payment orchestration across connected providers, so merchants can capture warm demand today while building a more portable recurring-payment foundation. Visit FloPay to review the platform, read the documentation, or discuss a practical pilot for invoices, agent-assisted sales, or renewals.