Crest guide

Payment links for invoices: what they are and how to use them

Last reviewed: 11 July 2026

A transaction-specific payment link and a payment address or handle can look the same. Both can be ordinary URLs, and both can appear as a link, a button, or a QR code. The important difference is the payment payload behind the URL: the recipient, amount, currency, reference, options, and constraints that the provider applies when the payer opens it.

The link does not replace the invoice. Your invoice still needs the correct seller and client details, description, dates, total, currency, tax treatment, payment terms, and any other fields required for the transaction. The provider page handles only the payment flow that the provider makes available for your account, market, and client.

This article is general information. It does not determine whether a provider is available or suitable for your business, whether a particular payment is protected, or what legal, tax, accounting, refund, dispute, or record-keeping rules apply. Check the provider's current local documentation and pricing before sending a link.

Payment link types

For this guide, there are two practical types. This is a useful invoice model, not a formal industry taxonomy.

Practical typeWhat the payload identifiesMain invoice trade-off
Transaction-specific payment linkA particular invoice, order, product, service, deposit, or other payment requestIt can fix what must be paid and reduce payer-entry errors, but it gives the payer less flexibility.
Payment address or handleThe person or business receiving moneyIt is reusable and flexible, but the payer may need to enter the amount or reference and can enter them incorrectly.

Both can be ordinary URLs. The practical difference is the payload, not the format.

Four terms to keep separate

  • Payment link: A URL that opens a payment flow. In the transaction-specific sense used here, it refers to particular goods, services, or an invoice request.
  • Payment address or handle: A reusable recipient identifier. Products such as PayPal.Me and Wisetag expose the handle as a shareable URL, although a handle may also work inside the provider app.
  • Payment payload: The payment details and constraints carried by or resolved from the URL, including recipient, amount, currency, reference, description, expiry, available methods, editability, and use count. Payment payload is the explanatory term used in this guide, not a universal provider product name.
  • Presentation: How the payer encounters the URL: a hyperlink, a button, or a QR code that encodes it.

Same URL, different payload

Both practical types can be ordinary URLs. That shared form is the source of much of the confusion: looking at a URL, button, or QR code does not tell you whether the amount and reference are fixed or left to the payer.

A plain paypal.me/YourName URL behaves like a payment address: it identifies the recipient and lets the payer enter an amount. PayPal also documents adding an amount to the same base URL, such as paypal.me/YourName/25. The address has become more specific, but it still looks almost the same. In the other direction, a provider may call an open-amount, reusable page a Payment Link even though its payload behaves much like a payment address.

The useful question is therefore not only "Is this a link or a handle?" Ask what the payload fixes: recipient, amount, currency, invoice reference, expiry, available methods, and whether the payer can edit any of them.

Choose how much flexibility to give the payer

For a full-balance invoice, the simplest transaction-specific link fixes the total due and currency and carries the invoice reference where the provider supports one. The payer does not have to retype the amount. That reduces underpayment, overpayment, wrong-currency, and reference errors and makes the provider record easier to match to the invoice.

The same constraint removes flexibility. The payer cannot choose a partial or adjusted amount unless you deliberately configure a different request. Deposits, instalments, credits, disputed balances, and agreed partial payments should each use a link that matches the amount currently requested or a clearly explained flexible route.

A payment address or handle keeps the recipient stable while leaving the amount, reference, or both to the payer or to instructions on the invoice. That is useful when you want one reusable destination or accept variable and partial payments. If you do not want the payer to choose the amount, use a transaction-specific link whose payload fixes it.

How the URL reaches the payer

The same URL can be presented as a visible or labelled link in email or a messenger, as a button on a website or digital invoice, or as a QR code for face-to-face payment and desktop-to-mobile handoff. Changing the presentation does not change the payload.

Label the action according to what the destination actually does. A button that says Pay this invoice should open a flow aligned with that invoice. When the destination leaves the amount or reference open, keep the expected amount, currency, and reference visible beside the link, button, or QR code.

A payment link can be encoded as a QR code, but not every payment QR contains a URL. Some payment schemes encode structured payment data directly. QR is therefore a presentation or data carrier, not a third payment-link type.

What the client sees

Most hosted payment links open a provider-controlled page, not a page inside your invoicing tool. Depending on the provider variant and local setup, the client may see your business or profile name, a description, amount, currency, enabled payment methods, and a confirmation step. A profile handle may instead open a recipient profile and ask the client to enter an amount.

The experience can change by merchant account, payer location, currency, browser, device, eligibility, and provider configuration. A method visible to you in a dashboard is not necessarily available to every payer. Guest access may exist for one market or flow but not another. Check the exact link in a signed-out browser before relying on it.

The provider page also does not prove that its amount matches your invoice. Compare the amount and currency yourself, retain the invoice reference in your records, and use the provider's own transaction record when reviewing what happened.

How to create payment links with common providers

The examples below show different payload configurations rather than additional top-level types. They are bounded to the named variants and the official pages reviewed on 11 July 2026. Interfaces and eligibility can change. If your dashboard differs, use the provider's current localized help centre rather than forcing these steps onto another product or account type.

Stripe Payment Links

In Stripe Dashboard, open Payment Links, choose New, select or add a product or use the customer-chosen-price option where available, configure the page, and create the link. Stripe documents the current flow in Create a payment link; check the Payment Links product page for current local pricing and availability.

Stripe Payment Links are hosted checkout links. The reviewed documentation supports fixed product or subscription pricing and customer-chosen amounts, and says the same link can be shared with multiple customers. Additional controls can bound use, but do not call an ordinary reusable Payment Link invoice-specific unless you have created and recorded it for that invoice. Available methods depend on the merchant, payer, currency, browser, and device.

PayPal Business Payment Links

For PayPal's US Business Payment Links flow, sign in to a Business account, add the product or service details and pricing, build the page, then share the generated URL or QR code. See PayPal Business Payment Links and the US business fees page.

This is a reusable hosted checkout product, distinct from PayPal.Me and PayPal's mobile request-link flow. The seller can use an exact price or allow a customer-entered price depending on configuration. Merchant availability, guest access, methods, and pricing vary, so follow the local PayPal page for the account that will receive the payment.

PayPal.Me

Visit PayPal.Me, sign in or create an account, choose the available handle, and share the resulting profile link. The reviewed US help says an amount and currency can be appended to the URL. See the PayPal.Me frequently asked questions and PayPal's localized business pricing.

PayPal.Me is a reusable payment profile link, not an invoice-specific request. A payer may need a PayPal account during the flow, and local availability and funding routes vary. If you use it on an invoice, keep the invoice amount, currency, and reference visible outside the profile link.

PayPal request links

PayPal's reviewed US mobile-app help describes opening Send/Request, choosing the link flow, entering the amount, optional note, and currency, selecting Request, creating the link, and sharing it. See How to create and use PayPal links and the US business fees page.

This is a fixed-amount request link for one payment, distinct from PayPal Business Payment Links and PayPal.Me. The reviewed US source says it can be canceled before payment and expires after 10 days if it is not paid or canceled. The recipient uses a PayPal account on the web or in the app.

Revolut Personal payment request links

The reviewed UK Personal help flow is Payments, New, Link, Request money, set the amount, then share. See Revolut's requesting money help and local Standard fees.

This is a fixed request flow. Do not carry assumptions from Revolut.Me, Pro, or Business into it. Availability, non-Revolut payer routes, methods, limits, commercial suitability, and expiry vary or are not settled by the reviewed source, so verify them in the local help centre.

Revolut.Me

The reviewed Italy-English help describes opening Payments, creating a payment link, choosing the request-money route, and sharing the generic Revolut.Me link. See Revolut.Me help and local Standard fees.

Revolut.Me is a generic recipient link with an amount entered by the sender. The reviewed source supports multiple completed top-ups subject to limits, but does not document expiry or enable/disable controls. It is not automatically an invoice-specific or commercial checkout link; verify local payer routes, limits, and commercial-use suitability before placing this variant on a business invoice.

Revolut Pro Payment Links

Revolut's reviewed Belgium-English Pro help supports sharing a Payment Link through email, text, an invoice, a QR code, social media, or another channel, with the customer opening a provider-hosted checkout. Use Revolut Pro Payment Links help for the current product details and localized pricing.

This is a Pro hosted checkout variant, not Personal or Business. The reviewed source supports reusable links or a usage limit, but does not document the creation path or amount model. Eligibility, expiry, and payer methods can vary across localized documentation, so use the local Pro page for the receiving account.

Revolut Business Payment Links

For the reviewed Business flow, open Merchant, choose Get paid, then Payment link, add the page details and amount, optionally set a payment-count limit, create the link, and share it. See Revolut Business Payment Links help and Business accept-payments pricing.

This Merchant payment page uses a seller-entered amount; the reviewed source does not say whether the payer can edit it. It accepts payments until an optional payment-count limit is reached, while time expiry is not documented. The reviewed help and pricing pages use different locales, so recheck seller eligibility, payer access and methods, and same-locale pricing. Do not confuse this receiving link with a payout link under Transfers.

Wise Business Payment Links

Wise Business documents starting from Home or a currency balance and choosing Request, or opening Payments and choosing a single-use or reusable link. Enter the amount, currency, and description, choose from the methods enabled for the route, create the link, and share it. See Getting paid by Wise Business Payment Link and UK receive-money pricing.

Single-use and reusable Wise Business links have different lifecycles: the reviewed source says a single-use link accepts one payment and is valid for 30 calendar days, while a reusable link accepts multiple payments and does not expire until closed. Local eligibility and enabled payment methods remain route-dependent, so do not generalize them.

Wisetag

In Wise, open Payments, Payment Tools, and Wisetag, enable discoverability, then copy or share the link or QR code. See What is a Wisetag? and UK receive-money pricing.

Wisetag is a discoverable profile handle for another Wise customer, and the reviewed source does not document amount entry, use count, or expiry. It is distinct from Wise Business Payment Links and is not an invoice-specific hosted checkout. Keep the invoice amount, currency, and reference alongside it.

Venmo Business Profile and QR

In the reviewed US flow, switch to the Business Profile, choose Charge, QR Code, then Venmo Me; optionally set an amount, and share or print the result. See QR codes for Venmo Business Profiles and Business Profile transaction pricing.

Treat this as a US app, business-profile, and QR flow rather than a general web hosted-checkout link. The reviewed source supports an optional preset amount that the payer can edit, but does not explicitly state the non-preset amount behavior. One preset QR can be active in the app at a time; time expiry is not documented. The payer uses the Venmo app and account. Do not infer a general external URL lifecycle from the QR flow.

Square Payment Links

In the reviewed US Square Dashboard, open Payments and orders, Payment links, choose Create link, select the link type, add the title, amount or frequency, configure the available options, save, and share. See Get started with Square Payment Links and the US Payment Links product page.

Square supports seller-set or buyer-entered amounts depending on link type. The reviewed source supports links that are reusable for multiple customers and can be deactivated or deleted, but does not establish a time expiry. A link sent from Square Point of Sale does not require a special Square app; ordinary checkout account requirements are not stated. A “one-time payment” setting describes charge frequency; it does not by itself prove that the URL accepts only one use.

SumUp Payment Links

The reviewed UK flow is Profile, Payment Links, Create payment link; choose a fixed or open amount, add the description, choose one-off or reusable, create the link, then copy it or show its QR code. See Send Payment Links with SumUp and the UK Payment Links product page.

This is a provider-hosted web flow. The official pages support fixed or open amount and one-off or reusable variants, but not a general time-expiry claim. Account eligibility, methods, and pricing are market-specific, so use the local SumUp pages rather than treating the UK flow as universal.

Where to put a payment link on an invoice

Put the link in a clearly labelled payment section near the total, currency, due date, and payment terms. Name the provider and tell the client what the link does—for example, “Pay this invoice with [provider]”—without implying that the invoice tool processes the payment.

Keep the visible invoice number or payment reference close to the link. If the provider allows a description or note, use the same reference there. For an open-amount or profile link, repeat the exact amount and currency on the invoice and ask the client to check them before submitting.

Use one primary route when possible. If you also show bank transfer details or another link, label each route separately so the client does not pay twice. Long raw URLs may wrap poorly in PDFs, so include a short descriptive label while retaining enough destination information for the client to inspect it. For the rest of the document, use the invoice requirements guide and freelancer invoice template.

Before you send the invoice

Check the invoice and link together:

  • Open the exact URL in a signed-out browser and, where relevant, on a phone.
  • Confirm the destination hostname belongs to the provider you intended to use.
  • Confirm the recipient identity or business name shown by the provider.
  • Compare the amount and currency with the invoice; check whether the payer can edit them.
  • Record whether the link is request-specific, reusable, usage-limited, or expiring.
  • Add the invoice number or another unambiguous reference where the provider allows it.
  • Confirm what the payer must use: account, app, guest flow, or another route.
  • Check the provider's current localized pricing and business eligibility.
  • Keep a copy of the invoice and the provider transaction record for your normal records.

Do not send a dashboard preview URL, a payout link, or a link copied from an unexpected message. If the provider offers a test or preview state, make sure the final client URL is the live receiving route intended for this invoice.

Safety and phishing

A familiar logo is not enough. Inspect the destination hostname before sending, and encourage the client to do the same. Avoid URL shorteners when they hide the provider domain. Do not publish an intended-recipient request link on a public page unless the provider designed that variant for public reuse.

If a payment request is unexpected, the safer response is to open the provider independently, sign in through the known app or site, and inspect the request there. Do not enter credentials or payment information after following a link whose sender, hostname, or purpose you cannot confirm.

A hosted link does not by itself establish that the underlying invoice is legitimate, that services were delivered, that funds settled, or that a payment qualifies for a refund, dispute process, or buyer or seller protection. Those questions depend on the transaction and the provider's current terms. Keep your own invoice, correspondence, delivery evidence, and provider records.

Using the link in payment reminders

When an invoice is still due, resend the invoice and the same request-specific link where appropriate. Check that the link remains active before every reminder, especially if it can expire, close after one payment, or reach a usage limit. If you replace it, update the invoice or clearly tell the client which link supersedes the old one.

Keep the reminder factual: identify the invoice, original due date, amount, currency, and current payment route. Do not create urgency by making unsupported claims about provider deadlines or settlement. See the payment reminder email guide for a practical sequence and templates.

Use your existing payment link on a Crest invoice

Add your provider's payment link to a Crest invoice. Crest presents the external URL in the PDF and live invoice and keeps payment status manual. Crest does not process, verify, or reconcile the payment.

Create an invoice

Frequently asked questions

Are payment links safe?

They can be a normal way to reach a provider-hosted payment flow, but the format alone does not establish that a request is legitimate. Check the sender, invoice, destination hostname, amount, currency, and provider account. For an unexpected request, open the provider independently rather than relying on the message link.

Does a payment link prove that an invoice was paid?

No. The URL is a route into a payment flow. Review the provider's transaction record and your receiving account, then update the invoice status using your normal process. A client opening a link or reporting payment is not the same as your confirmation that funds arrived.

Is a payment address or handle also a URL?

Often, including the products discussed here. PayPal.Me and Wisetag expose a stable recipient handle through a shareable URL, and the handle may also work inside the provider app. That is why a payment address and a transaction-specific payment link can look and be shared in exactly the same way. The payload behind the URL is what differs.

What is a payment payload?

In this guide, it means the payment details and constraints carried by or resolved from the URL: recipient, amount, currency, reference, description, expiry, available methods, editability, and use count. An opaque URL may contain only a token while the provider stores those details on its server.

Should an invoice payment link let the payer change the amount?

Usually not when the full invoice balance is due. Fixing the total and currency reduces entry errors and ambiguity. Allow an editable or partial amount only when that flexibility is intentional, and make the amount currently requested clear on the invoice.

Can one payment link be reused?

Sometimes. Reuse is variant-specific. Stripe and PayPal Business describe reusable hosted links; Wise Business and SumUp expose distinct lifecycle choices; some request links accept one payment; profile links are generally stable identities. Check use count separately from amount and expiry.

Is a QR code a payment link?

Not necessarily. A QR code is a transport format. It may encode a payment-link URL, a profile handle, or structured payment data. Describe the destination or data it carries rather than treating “QR” as a separate payment method.

Can a payment link replace the required invoice fields?

No. The invoice and payment route do different jobs. Keep the seller and client details, invoice number, dates, description, amount, currency, tax treatment, due date, and other required information on the invoice. The payment link simply gives the client a route to a provider flow.

Should I put more than one payment route on an invoice?

Only when it helps the client and you can label the alternatives clearly. State that the client should choose one route, and keep the provider name, amount, currency, and reference visible. Multiple poorly distinguished routes increase the chance of confusion or duplicate payment.

Sources and update policy

The provider claims in this guide were reviewed against official product, help, and localized pricing pages on 11 July 2026. Crest maintains an internal evidence ledger and review contract for this guide.

Provider interfaces, availability, pricing, payer methods, expiry, limits, refunds, disputes, protection, and generated URL patterns can change. Recheck the exact official and localized provider pages before publication and before relying on a high-volatility claim. The full provider ledger should be reviewed at least every 90 days; high-volatility claims should be rechecked within 30 days of publication or omitted.

Official references: