QR Codes for Church Giving: Tithing on the Envelope, the Card, and the Screen

Here is what actually matters before you generate a single code: EZQR is the QR layer, not the payment layer. The code stores a short web address that sends the phone to your church's giving page, and that is the entire job. We do not charge the card, hold the money, set the gift amount, or issue the receipt. Your giving platform does all of that. There is no per-transaction fee from us and no cut of the offering, because the offering never passes through EZQR at all.

That division is deliberate, and it protects you. Your giving platform already handles the regulated, money-touching work — PCI compliance, the card charge, the donor record, the 501(c)(3) receipt. Keeping the QR separate means you can change giving platforms later without reprinting a single envelope, because the QR points to a URL you control and you simply re-aim it at the new platform. Most vendors won't tell you this, because bundling the QR into the giving platform is how they keep your printed collateral hostage to their contract.

The receipt mechanics — what the IRS requires on the acknowledgment, what the donor's giving statement has to say, how restricted gifts get tracked — all live with the platform, and the donations playbook covers them in full. We will not re-derive that here. For church giving, your job with the QR is narrower: point it at the right page, label it so people trust it, and track which placement works.

Use exactly one static code for your permanent general-fund giving page, and a separate dynamic code for every fund that has an end date. The general-fund page — usually something like yourchurch.org/give — is the URL that genuinely will not change in 10 years, so a static code is correct. It never expires, it costs nothing to keep, and it survives even if you cancel your QR subscription entirely, because a static code is just the URL encoded directly into the pattern. Print it on the offering envelope box that gets reordered for a decade and it keeps working.

Everything with a finish line is a dynamic code. The capital campaign that runs 18 months and retires. The building fund that closes when the roof is paid. The missions appeal tied to one trip. The Christmas Eve or Easter seasonal push. Each of those gets its own dynamic code that you can re-point when the destination URL changes and retire when the campaign ends, all without reprinting the card or the banner. A dynamic code keeps the printed pattern fixed while you change the page behind it, which is the whole reason a campaign banner from last year does not become a dead link this year.

The contrarian part: do not make your general-fund code dynamic just because dynamic codes have analytics. A static general-fund code that survives a lapsed subscription is worth more to a church than the city-level scan data, because a church budget pause during a pastoral transition is exactly when a dynamic-code vendor quietly deactivates your codes. Which vendors keep codes alive after cancellation, and which silently kill them, is the whole subject of the permanent QR code guide; for a church that reorders offering envelopes on a 10-year cycle, that policy outranks every feature. For most churches the answer is one static code plus 3 or 4 dynamic ones, and the general-fund URL code is the one that has to outlive everything else.

Four placements carry almost all the giving lift, and each one catches a different person at a different moment. Put a code in all four, and give each placement its own code so you can read which one converts.

The offering envelope. Print the general-fund static code on the envelope itself, next to the line where people used to write a check amount. The person who still likes the envelope ritual but stopped carrying cash scans instead of leaving it blank. This is the placement that recovers the giver you thought you lost.

The pew or connect card. The card already in the seat-back or handed out at welcome is the highest-intent surface you have, because the person filling it out is already deciding to commit something. A code routing to giving sits naturally beside the prayer-request and first-time-visitor checkboxes. Connect cards and giving belong on the same surface — the sermons and connect-card playbook covers how to lay that card out so the giving code does not crowd the response section.

The bulletin. The weekly bulletin or program reaches the person who takes it home, and a code on the back page catches the gift that gets decided on the drive home or Sunday night. This is also where seasonal-appeal dynamic codes belong, swapped in for the season.

The projection screen. A code on the screen during the offering, held for at least 30 seconds, reaches the largest single audience at the exact moment giving is announced. Size it large — a code meant to be scanned from row 20 needs to be far bigger than one on a card in someone's hand. This is the placement with the most reach and, usually, the lowest scan-through, because not everyone has their phone out mid-service.

The real security threat to a church giving QR is not a hacker; it is a sticker. A fraudster prints a QR linking to their own payment page, peels off the backing, and sticks it directly over your legitimate code on the offering box in the lobby or the sign by the door. Visitors scan the top sticker, land on a page that looks vaguely like giving, and send money to a stranger. The FTC has issued public alerts on exactly this pattern, and donation and parking-meter codes are the most-targeted surfaces because the money transfers instantly and the victim never knows.

The defenses are unglamorous and they work. Use a custom domain so the giving URL reads give.yourchurch.org, not a generic shortener a fraudster's code could also use — a member who glances at the URL bar should see your church's name. Label the code in print: "Give to [Your Church Name]" directly under it, so a swapped sticker that lands somewhere else is an obvious mismatch. Confirm the page loads over HTTPS with the lock icon and no browser warning. And here is the physical control most churches skip: walk your lobby, your offering boxes, and your outdoor signage once a month and physically check that the printed code is the original, not a sticker layered on top. A laminated code on a rigid sign is harder to cover cleanly than a paper one.

The broader trust-design rules — why a branded landing page beats a bare payment-processor checkout, what gives a member confidence in the two seconds before they decide your page is real — apply directly here, and a donation QR code built on your own domain carries those signals by default. The nonprofits page covers the same anti-fraud posture for registered orgs more broadly. For a church, the one-sentence version: your code should look unmistakably like yours, on a surface a sticker cannot quietly cover.

There is a second, quieter failure mode worth naming. A member scans a legitimate code, the giving page loads, and then it asks for an account login before it will take the gift. That is not fraud, but it kills the same gift, because the person who scanned during the offering does not have time to recover a forgotten password mid-service. Check your giving platform's flow on a fresh phone with no saved login and confirm a first-time or guest gift takes under 30 seconds. If the platform forces an account, that friction belongs on the platform's settings, not on the QR — but you are the one who finds it, because you are the one holding the phone in the pew.

EZQR links and tracks; the platform processes the gift and issues the receipt. The QR is platform-agnostic, so the code points to whichever giving page your church already runs, and the table below covers the ones most churches use. Pick the platform on its own merits — the QR works the same regardless.

Give each placement its own dynamic code and the dashboard tells you which giving spot earns scans, so you stop guessing. The envelope code, the connect-card code, the bulletin code, and the screen code each report their own scan count, the date and time, and the city. Run them for a quarter and the pattern is usually clear: one or two placements carry most of the activity and one is dead weight. We have seen the connect card and the screen split the lead in most congregations, with the envelope quietly recovering the older giver, but your congregation is its own data set and that is the point of tracking it.

What the dashboard shows you is scans, not gifts. EZQR counts the code's activity; it never sees the donor, the amount, or the name, because the gift happens entirely on the giving platform after the scan. So a placement with high scans and low giving means people are reaching the page and not finishing — usually a sign the giving page itself is slow, asks for too much, or makes the person hunt for the fund. The fix is on the platform side, not the QR. Real-time scan notifications that text you the moment a code is scanned are a Max-tier feature; below that you review the trend in the dashboard on your own schedule, which is fine for a weekly giving rhythm.

There is a printing detail that decides whether the screen code works at all, and it is the one churches get wrong most often. A code on a card in someone's hand is read from 12 inches; a code on the projection screen is read from 40 feet by the person in the back row. The rule of thumb scanners need is roughly a 10-to-1 distance-to-size ratio, so a code that scans from 40 feet has to be about 4 feet across on the screen. Most churches size the screen code like the card code, the back rows cannot lock onto it, and the placement with the most reach reports the fewest scans for a reason that has nothing to do with willingness to give. Make the screen code large, hold it on screen for at least 30 seconds during the offering, and keep strong dark-on-light contrast so the projector does not wash it out.

If you only do one thing with the data, kill the placement that gets no scans and move that print real estate to the one that does. A bulletin back-page code that nobody scans after a quarter is telling you the bulletin is not where your people decide to give. Reallocate to the surface that works in your room. And re-test every code on a real phone, on cellular, with no saved login, after any change to the giving page or the platform — printed envelopes and pew cards stay in service far longer than most teams run their test cycle, and a code that worked at print time can break when the platform moves a URL.

Phones made since about 2018 scan a QR with the built-in camera app — no separate app, no download, just point and tap the banner that appears. That covers the large majority of any congregation, including most members in their 60s and 70s who carry a modern phone. The fear that QR giving locks out older members is mostly a fear about phones from 2015, and those are rare now. Still, the right posture is not to assume; it is to make sure nobody is forced onto a phone they cannot use.

Print the giving URL in plain text under every code, every time. give.yourchurch.org typed into a browser reaches the same page, and a member who would rather type than scan is served without a second system. Keep one staffed giving station — a table in the lobby with a volunteer and a card reader, or the front-office check-and-cash option you already run. And keep the offering plate. A church that takes giving by QR, by card at a station, by check, by cash, and by mailed envelope is not replacing the old ways; it is adding the one channel the under-40 crowd actually uses, while losing nobody.

The announcement matters more than the technology. The first three or four weeks, have someone walk the congregation through it from the front: hold up your phone, open the camera, point it at the screen, tap the link. Once a few members have done it from their seat, it stops being a tech question and becomes a habit. The churches QR page covers how giving fits alongside connect cards, sermon notes, and wayfinding as one coordinated program rather than five disconnected codes.

The QR side of a church giving program is a flat monthly subscription with no per-gift fee, and most churches fit the bottom two paid tiers. EZQR generates and tracks the codes; what you pay scales with how many dynamic codes you run, not with how much your congregation gives. A single-campus church running a general fund plus two or three campaigns fits comfortably in the lower tiers. The ladder:

Put your existing giving page behind a QR in four places — the offering envelope, the connect card, the bulletin, and the screen during the offering — and you hand the giving page to every person in the room on the device they actually carry. Use one static code for the permanent general fund, because it never changes and survives a cancelled subscription, and a separate dynamic code for each campaign, building fund, missions appeal, and seasonal push, so you re-point or retire it without reprinting.

EZQR links and tracks; your giving platform charges the card and issues the receipt. Label every code "Give to [Your Church Name]", run it on a custom domain, confirm HTTPS, and walk your lobby monthly to catch the sticker-fraud trick before a visitor does. Print the URL under every code and keep a staffed station, so the people who will never scan are still served.

For a single-campus church, this is a Lite or Pro program — $5 to $10 a month, no cut of the offering. A multi-campus church with a fund per ministry steps up to Max for unlimited codes, bulk import, the API, and a custom domain. The teaching side of the same QR program lives in the church media guide, and the missions-partner side in the missions and ministry-partners playbook. The code costs cents to print and recovers the giver who stopped carrying cash.