What is a payment link?

The short answer

Payment links let a business present a hosted checkout without building a complete ecommerce site or collecting payment details through an email, text message, or general contact form. Stripe's current API reference defines a payment link as a shareable URL leading to a hosted payment page. Square documents that its links can be shared directly or posted where customers can access them, while PayPal describes shareable pay links and QR codes that can be used without a website.

Those examples explain the general pattern, not a universal feature list. One provider may support a reusable link for a product or open amount, while another workflow may create a link for a particular request. Review what the chosen product actually displays and records before relying on the label alone.

How a payment link works

1. An authorized user creates the link. Staff choose the supported link type and enter the customer-facing information required by the provider.
2. The provider hosts the checkout. The generated URL leads to a page operated by the payment provider rather than a general message or ordinary website form.
3. The business shares the destination. Depending on the workflow, the link may be copied into an established email or text conversation, placed behind a button, or presented as a QR code.
4. The customer reviews the page. The customer should be able to recognize the business and understand what the request covers before choosing an available payment option.
5. The provider processes the submitted checkout. The hosted page handles the customer interaction according to the provider's current settings and supported methods.
6. The business verifies the result. Staff check the authenticated dashboard or approved reporting workflow for the transaction outcome instead of trusting a screenshot or reply message.

For channel-specific guidance, see whether payment links can be sent by email or payment links can be sent by text message.

Payment link, invoice page, or virtual terminal?

These terms can overlap across product interfaces, so compare the actual customer view, staff permissions, records, and reporting. Read more about hosted invoice payment pages and how a virtual terminal works.

Where businesses commonly use payment links

A business may share a link during a remote customer conversation, attach it to an established digital sales workflow, place it behind a website button, or present a provider-generated QR code. Square currently documents sharing by copied link, QR code, buy button, email campaign, social media, and text in supported workflows. PayPal documents a shareable link, button, and QR code. Availability varies, so businesses should confirm the channel and link type supported by their own account.

The message surrounding the link should explain what the customer is being asked to pay for and give the customer a known way to verify the request. Avoid link shorteners or vague messages that hide the provider domain or make the request difficult to recognize. A link posted publicly should be intentionally configured for that audience; a customer-specific request should be shared only through an appropriate customer channel.

What to verify before sharing a link

• Does the hosted page clearly identify the business and describe the payment request?
• Is the amount fixed, customer-entered, or connected to a specific item or record?
• Is the link intended for one customer, one completed checkout, or repeated use?
• Which customer fields and payment choices actually appear on phone and desktop?
• Can authorized staff deactivate the link or limit its use when the provider supports those controls?
• Where do staff confirm successful, failed, refunded, or otherwise changed payment outcomes?
• What receipt or confirmation does the customer receive?
• Who is allowed to create, edit, share, and deactivate links?

Square documents creation, sharing, deactivation, and link-level reporting within its supported products. Stripe documents hosted checkout sessions and tracking for its Payment Links. These details are useful evaluation examples, but they should not be assumed for every provider. Businesses evaluating link lifecycle can also review whether a payment link can be reused and how payment-link availability can change.

Keep the customer message privacy-safe

Use the hosted checkout for the payment details it is designed to collect. Do not ask customers to send card numbers, passwords, bank credentials, complete account numbers, or secret API keys through email, text, social messages, or a general contact form. The FTC advises businesses to understand what sensitive information they hold, keep only what they need, limit access, and protect retained data.

Give customers a separate, known contact method for questioning an unexpected request. Train staff to confirm payment status through the authenticated provider account and to treat screenshots, forwarded emails, and customer replies as unverified. Review user access periodically so employees can reach only the functions needed for their work.

A practical evaluation path

Begin with a provider-supported preview or an approved test that contains no real payment credentials. Open the page on a phone and desktop, check the business identity and description, and note every field and payment choice shown. Then document how staff create the link, how the customer recognizes it, where the business verifies the result, and how the link is disabled when it should no longer be used.

If the business needs detailed invoice context, compare a hosted invoice workflow. If staff need to enter an authorized payment while speaking with a customer, evaluate a virtual-terminal workflow. If a straightforward customer-facing checkout matches the use case, a payment link may be the clearest pattern. The virtual terminals, invoicing and payment links FAQ hub connects these related options.