QR Codes for Donations: Trust Is the Hard Part, Not the Code

Every QR code asks for a small act of faith: point your camera at an unreadable square and trust whatever opens. A donation code asks for that and then asks for money. It is the highest-friction request in the whole format, and the two places it fails are both outside the square — before the scan, where the person decides whether you are legitimate, and after it, where they decide whether paying is worth the effort.

Almost every guide to this covers colours and placement. Those matter, and they are covered in QR code design that still scans. This is about the two harder halves.

The trust problem comes first

A QR code is opaque by design. You cannot read it, so you cannot know where it goes until you are already there. That property is exactly what makes codes useful and exactly what makes them a favoured vector for fraud — and asking for a payment is the case where the public is most alert to it, and most right to be. A code stuck on a collection tin, a poster in a station or a plaque in a church is also the easiest thing in the world for someone else to cover with a sticker.

So a donation code has to earn trust from what is printed around it. Four things do most of that work:

• Print the destination URL in plain text under the code. This is the single most effective thing on the list. It lets a cautious person see where they are going before committing, lets someone with a dead battery type it later, and — critically — it means a sticker placed over your code is detectable, because the printed address and the scanned one no longer agree.
• Use your own domain. A code resolving to a domain a person recognises as yours is a completely different proposition from one landing on a shortener nobody can evaluate. If the destination has to sit on a third-party platform, say so in print next to the code rather than letting it be a surprise after the scan.
• Name the organisation next to the code, along with a registration or charity number where you have one. A number that can be looked up is a verifiable claim; a logo is not.
• Say what the money does, specifically. "Supports our work" is worth roughly nothing. A concrete sentence about what a donation pays for is both more persuasive and more checkable.

The general mechanics of how a scan can be abused — and what a person can do to check one before tapping — are in are QR codes safe, and how to spot a malicious one. It is worth reading from the donor's side, because that is the position you are asking them to be in.

The page has to take a payment in one tap

This is where most donation codes actually die, and it is entirely fixable. Picture the moment: the person is standing — at the back of a hall, in a foyer, on a pavement, at a stall. They are holding a phone and probably something else. And your page opens with a form asking for card number, expiry, security code, name, billing address and postcode.

Nobody types sixteen digits standing up out of goodwill. The intention was real and the interface consumed it.

• Wallet payment has to be the first option, not a fallback. The phone already holds the card, and a wallet payment is a thumbprint or a glance rather than a data-entry task. If a donation page supports only manual card entry, that is the thing to fix before anything else on this page.
• No account creation. Not before the payment, not as a required step after it. If you want the person on a mailing list, ask once the money has gone through, and let no be an answer.
• Offer two or three suggested amounts and default to one. An empty amount field makes the donor decide what is appropriate, which is an awkward question they did not want to be asked. Suggestions are a kindness; keep a free-entry option for anyone who wants it.
• Ask for nothing you do not need. Every optional field is another reason to abandon. Gift-aid style declarations and address capture, where they genuinely matter, belong after the payment has succeeded.
• Do not open a PDF or a document. The destination must be a page built for a phone. The wider point is in where should a QR code point.

Signal, again — and here it costs more

Donation codes get placed in exactly the buildings that block radio: stone churches, halls, basements, marquees, station underpasses, the inside of a large venue. The code decodes fine, because that happens on the phone. The payment page then does not load, and the donation does not happen.

Two practical mitigations. First, go and scan your own code where it will actually be, on mobile data, before committing to print — the same fifteen-minute check that catches most event failures. Second, if signal at the location is genuinely bad, do not make the code the only route: a short printed address someone can visit later, or a text-to-give instruction, both survive a dead spot. A code that only works outside the building should not be the sole option inside it.

Printed collateral outlives the campaign

Donation codes end up on things with long lives — plaques, signage, collection boxes, banners reused every year, printed appeals that sit in a drawer. The appeal behind them does not last nearly as long. A static code encodes its URL permanently, so when this year's appeal page retires, every one of those printed codes points at nothing.

That is a bad failure for anyone and a worse one here, because a dead link on a donation ask reads as a defunct organisation. A dynamic code keeps the artwork and changes the destination: this year's appeal becomes next year's, or the general giving page between campaigns. The dependency it introduces — the redirect has to keep resolving — is discussed honestly in static vs dynamic QR codes, and it is worth weighing seriously for something cast into a plaque.

Whichever you choose, decide now what the code does between appeals. "Nothing" is a decision too, and it is the wrong one.

Be careful what you claim the numbers mean

Scan counts tell you a code was scanned. They do not tell you a donation was made, and the gap between those two numbers on a donation code is likely to be large, because the payment step is where the drop-off is. Treat scans as a comparison between placements — the foyer poster against the order of service — and take the actual giving figure from wherever the money is processed. How to track QR code scans sets out the boundary. Reporting scans as donations to a board or a funder is the kind of number that is very hard to walk back.

The short version

• Print the URL under the code — trust, accessibility, and it makes a sticker attack visible.
• Use your own domain, name the organisation, and give a number that can be looked up.
• Say what the money does in one specific sentence.
• Wallet payment first. Nobody types a card number standing up.
• No account, no unnecessary fields, and suggested amounts with one default.
• Scan it where it will live, on mobile data, before printing.
• Use a dynamic code on anything long-lived, and decide where it points between appeals.
• Scans are not donations. Never report them as such.

If you are setting one up, the donation template starts from this shape, and the design studio covers the constraints the printed code has to respect.