Once you have moved past static QR codes, the choice is usually between a payment link and a dynamic QR. They solve the same reconciliation problem in the same way. What separates them is distribution — whether the customer is in front of you or at the other end of a message.
What they have in common
Both are generated per transaction, and both carry the amount and a reference you control. That single property is what makes automatic reconciliation possible, and it is the main reason to use either in preference to a static code.
- The customer cannot enter the wrong amount, because they do not enter one.
- The reference returns with the payment, so matching is a lookup rather than an inference.
- Both can expire, which prevents an old request being paid months later against a closed invoice.
- Both can be cancelled, which a printed code cannot.
- Both produce a status you can query, rather than a credit you have to recognise.
Where they differ
| Payment link | Dynamic QR | |
|---|---|---|
| Reaches the customer by | Message, email, chat | Being shown on a screen in person |
| Customer is | Remote | Present |
| Works on desktop | Yes | Only if they scan with a phone |
| Can be forwarded | Yes — useful and occasionally a risk | Not easily |
| Natural for | Invoices, remote collection, follow-ups | Counters, deliveries, field collection |
| Needs at the point of sale | Nothing | A screen |
| Chasing an unpaid request | Resend the same link | Not applicable — the moment has passed |
Choosing by situation
The question is not which is better but where the customer is standing when you ask for money.
Use a payment link when
- You are invoicing and the customer will pay later, from wherever they are.
- Collection happens over chat or email, where a tappable link fits the medium.
- You want to chase: a link can be resent, and each reminder carries the same reference.
- The payer may not be the person you are talking to — finance often pays what sales negotiated.
- You need a record of when the request was sent and opened, which a link gives you and a code does not.
Use a dynamic QR when
- The customer is physically present and holding a phone.
- You are delivering, where the amount is known at the door and the customer is standing there.
- You want no typing and no app switching on your side either.
- The transaction completes now, not later.
- There is a queue, and the few seconds a link would take to send and open actually matter.
Use both when
Many providers let one underlying request be rendered as both. That is often the best arrangement: show the code to the customer in front of you, send the link to the one who is not, and reconcile a single record either way.
The operational details that decide how well either works
- Set a sensible expiryLong enough that a reasonable customer can pay, short enough that stale requests do not get settled against closed invoices. For invoices, align it with your payment terms.
- Make the reference meaningful to youIt comes back with the payment, so encode what you will want to match on — the invoice number rather than a random string.
- Handle partial and duplicate paymentsBoth happen. Decide in advance whether a short payment closes the request, and what to do when the same link is paid twice.
- Decide what cancellation meansIf an invoice is credited, the outstanding link should stop working. Wire cancellation to your billing events rather than leaving it manual.
- Confirm server-sideUse a signed webhook, and sweep anything still outstanding with a status poll. Do not rely on the customer landing back on a success page.
Partial payments: pick a policy and hold it
A customer paying 40,000 against a 50,000 request is common in B2B and it is not an error. What is an error is having no policy, so the behaviour depends on which code path happened to run.
- Either the request stays open for the balance, or it closes and the shortfall becomes a new receivable. Both are defensible; drifting between them is not.
- Whatever you choose, the customer should see it — a request that silently closed short will be queried.
- Make sure your ledger can represent a part-settled request, or the reconciliation you built this for will break on the first one.
Chasing without annoying
The chasing advantage of links is real and easily overused. A reminder that carries the same reference and the same link is helpful; four reminders in a week from an automated sequence that does not know the invoice was queried is not.
Tie the reminder schedule to the payment terms and stop it on any human contact about that invoice. The system should know when a conversation is already happening.
What to measure
Both methods produce a request with a status, which means collection stops being a mystery and starts being a funnel you can read. The useful figures are not the ones most dashboards show first.
| Measure | Tells you | Act when |
|---|---|---|
| Opened but not paid | The request arrived and something stopped them | The share rises — usually a checkout or amount problem |
| Time from send to payment | How your terms actually perform | It drifts well past your stated terms |
| Expired unpaid | Requests that quietly died | Any material volume — these are recoverable revenue |
| Paid after a reminder | Whether chasing works | It is near zero, meaning reminders are noise |
| Partial settlements | Disputes or deductions you are not seeing | The rate climbs for one customer |
The first row is the most actionable and the least watched. A request that was opened and not paid is a customer who intended to pay and did not, which is a fixable problem rather than a collections one.
Fitting collection into how you already invoice
A payment request is only useful if it reaches the person who pays, at the moment they are deciding to pay. That is an invoicing question more than a payments one, and it is where most collection improvements actually come from.
- Generate the request with the invoiceNot afterwards as a separate step. A request created at invoicing time carries the invoice number naturally and cannot be forgotten.
- Put it on the document itselfThe details that get used are the ones on the thing being paid. A link in a covering email is read by a different person than the invoice PDF that reaches accounts payable.
- Send to the payer, not only the buyerIn most businesses these are different people. A request that reaches only the person who ordered waits until they forward it.
- Reference the same identifier everywhereThe invoice number on the document, in the request, and in the reconciliation. Three identifiers for one transaction is how matching breaks.
- Stop chasing on contactIf someone has replied about an invoice, the automated reminders should pause. Nothing erodes a relationship faster than a sequence that keeps nagging through a conversation.
Frequently asked questions
Can one request be both a link and a QR?
Commonly yes — the same underlying request can be rendered as a scannable code and as a shareable URL. That is often the best setup, because it covers the present and the remote customer without creating two records.
What expiry should a payment link have?
Match it to the commercial context. For an invoice, align with your payment terms; for a point-of-sale request, minutes. The aim is to prevent a stale request being paid against something already closed.
What happens if a customer pays a link twice?
Decide the behaviour before it happens: either the request becomes unpayable once settled, or you detect the second payment and refund it. The failure to avoid is silently accepting both and reconciling neither.
How should a partial payment be handled?
Pick a policy and apply it consistently — either the request stays open for the balance or it closes and the shortfall becomes a new receivable. Both work; what breaks reconciliation is drifting between them.
Are payment links safe to forward?
Forwarding is usually a feature, since the person who owes the money is often not the person who pays it. Keep the link free of sensitive detail beyond the amount and reference, and expire it, so a forwarded request cannot be misused later.
Should an outstanding link be cancelled when an invoice is credited?
Yes, and automatically. Wire cancellation to your billing events rather than leaving it manual, or you will eventually collect against something that was written off.
