How to Use QR Codes for Payment Links

Three payment surfaces, three different conversion stories

Match the link to the payment context. An invoice should open the actual bill or a supported payment page showing the merchant, amount, currency, and reference. Include an ordinary payment link in digital correspondence so someone reading on the same phone need not scan their screen. Measure confirmed payments through the billing system rather than forecasting an invoice conversion rate.

A receipt QR needs a clear purpose: a tip, a separate purchase, or a remaining balance. Label that purpose and make the amount visible before confirmation. Check that the receipt printer preserves the code edges and margin. A scan count is not evidence that money was received.

A counter sign can offer a supported checkout link while staff remain available to help. State the merchant and explain what the visitor should check before paying. Do not use an unverified payment screenshot as confirmation; check the actual provider record. This guide does not contain an observed counter-sign conversion experiment.

Trust signals that matter on first paint

The most overlooked failure mode in payment QR campaigns is the moment between scan and decision. The customer scans, the browser opens, and for two or three seconds they are looking at a destination page they have never seen before, wondering whether someone slapped a sticker over the legitimate code. If your payment page shows the merchant name, the exact amount, and the invoice or order reference number above the fold on first paint, that moment of hesitation collapses. If it shows a generic “Pay” header with no merchant identity, a chunk of customers bail.

Show the recognised merchant, amount, currency, and order reference before payment. If your provider supports reference or email parameters, use only its documented fields and avoid sensitive data in public URLs. Stripe documents supported parameters in its Payment Links reference. A prefilled reference identifies an order; it does not authorize changing the amount or accessing another customer record.

Deep linking to wallet apps

For wallet-specific payment, use the current link or QR issued by the provider. Do not construct undocumented app schemes or assume they work across every operating system. Test the supported path on a phone with the wallet installed and one without it. Preserve an alternative accepted payment method when the required application is unavailable.

A URL QR opening a checkout page is different from a structured bank payment QR. Use the bank or payment-provider issued code for schemes such as UPI or Pix, and confirm compatibility with the intended banking app. The EMVCo QR overview describes payment QR specifications; it does not make this generic URL generator a certified banking integration.

If customers need several payment methods, use a checkout page supported by your payment provider and label the choices clearly. Test an installed wallet and a phone without that wallet. A choice page adds an action, but this guide has no measured conversion cost for that action.

Recurring billing versus one-off

For one-off payments like a contractor’s invoice, a hotel folio, or a doctor’s bill, the QR should land on a fully prefilled payment page with the amount locked. Editable amount fields invite typos and reduce trust; locked amounts close cleanly. Use the URL to PNG generator to produce a high-resolution code suitable for invoice headers and a URL to SVG version for letterhead templates that need to scale cleanly to A3.

For recurring billing, the QR should not initiate a payment directly. It should land on a customer portal where the user sees their subscription status, can update the card on file, and can pay any outstanding balance. Stripe’s customer portal at https://billing.stripe.com/p/login/[id] is a clean primitive for this. Pre-authenticated portal links delivered by email work well, and the QR variant is mostly useful in mailed dunning notices for failed cards.

The counterfeit-sticker attack

Public-facing payment QRs on parking meters, restaurant table tents, and storefront windows are a known attack surface. Scammers print a QR sticker linking to a phishing wallet or a lookalike payment page and physically overlay it on top of the legitimate one. Several US cities reported parking-meter overlay attacks in 2022 and 2023, and the SEC issued advisories about similar attacks on cryptocurrency-linked codes. The are QR codes safe overview covers the broader threat model.

Two defenses help. Make the legitimate code physically resistant to overlay through laminate, embossing, or printing directly into a fixed surface. Engraved metal counter signs are common in higher-end restaurants for this reason. Train customers to verify the destination domain on first paint as well. A storefront sign that says “Always check that the URL starts with https://pay.yourbusiness.com” gives customers a check they can apply themselves. The retail packaging playbook covers a related but distinct sticker integrity question.

Prefilled invoice references kill typos

Manual entry of invoice numbers is the most common drop-off point in mid-market B2B payment flows. A controller staring at a long alphanumeric reference will often paste it wrong, get a “not found” error, and either give up or call accounting. Encoding the invoice number directly into the QR-linked URL eliminates the typo path entirely.

Use the invoice link generated by the billing system rather than constructing a URL from a guessed identifier. A reference in a URL is not authentication and should not grant access to another customer invoice. Verify the amount, merchant, currency, and final payment status through the billing system. A completed payment cannot be attributed to a particular physical QR scan merely because an invoice reference was prefilled.

After payment: confirmation that travels

The post-payment screen is doing more work than most teams give it credit for. It tells the customer the payment landed, which is the single most anxiety-reducing message you can send a non-technical user paying through a QR. Show the amount, the merchant, the date, and a confirmation reference. Offer “Email me a receipt” as an explicit action. If the payment was for a service that has a next step like delivery, reservation, or follow-up call, state it plainly. For event and registration use cases, the event check-in playbook covers the handoff from payment to credentials, and the QR code use cases overview ties payment flows back into the broader landscape of offline-to-digital touchpoints. Restaurant operators should pair this with the tableside payment playbook, which covers split-the-check workflows and server-handoff design that don’t fit a generic invoice-payment pattern.

Sources

• Stripe — supported Payment Links
• EMVCo — payment QR specifications