QR Codes for Missions: One Card Per Partner, Re-Pointed Monthly

Here's what actually matters before you generate a single code: a QR holds a short web address, not a file. Your 12-minute field video is hundreds of megabytes; the QR stores a few hundred characters. So the video has to live somewhere on the web, and the QR sends the phone to that address. We generate and track the code. We do not store your video, your prayer letter, or your photos, and there is no per-gigabyte or per-terabyte storage bill from us, because we are not your host.

That split is the point, not a gap. Keep the video on a host you control and the QR is a pointer you can re-aim every month. Put the file inside a vendor that also owns the QR, and the day they raise storage prices your whole field archive is hostage. Most vendors won't tell you this, because bundling storage is how they keep you.

For a field video, two hosts cover almost everyone. Vimeo gives you a clean player with no ads and privacy controls, which matters when the footage names workers in sensitive regions. YouTube as an unlisted upload is free at any volume and works when the content is not security-sensitive. Your prayer letter and support page already live on your sending agency's website. The QR just points there. The hosting and durable-card mechanics carry over almost exactly from the church media distribution playbook, so this guide stays on the missions and support-raising side and links there for the host-by-host detail.

The structure that makes this cheap is one card per partner, kept for years, not a new card with every newsletter. Give each supporter a single dynamic code, printed on a sturdy card or in the corner of your sent-once welcome packet. Every month you re-point that code to the new field video and prayer letter. The same card already in their hand now opens this month's update. No reprint. No second mailing of cards. No postage on the card after the first send.

This is the opposite of how most missionaries picture the switch. They imagine printing and mailing a fresh QR card with every update, which is just the old newsletter with a code stapled to it. A dynamic code removes the monthly print run entirely, because the printed pattern stays fixed while the destination behind it changes. You mail the card once. After that the only thing that travels each month is the edit you make to where the code points, and that edit is free.

Contrast that with the static code on your support page. Your giving URL at your sending agency rarely changes, so a static code printed on a prayer card is fine there and works forever with no account behind it. The monthly update is the opposite case: the destination changes every single month, the card never does, so it has to be dynamic. Get this one distinction right and the whole program runs on near-zero recurring cost. The supporter who keeps opening your updates is the supporter who keeps giving, so a card that follows them for years is a relationship investment, not a printing line item.

Give each partner a unique code and every scan becomes a quiet engagement read. The dashboard shows each code's activity: how many times it was opened, on what date, and from which city, exportable to a spreadsheet. Print the same field-video link behind 300 unique codes and you can see which supporters opened this month's update and which didn't, by card, without ever asking them.

That is the number that should change how you work. A partner whose code went dark three months running is the partner to call before the gift stops, not after. You are no longer guessing which relationships are cooling. The data tells you, quietly, in time to do something pastoral about it. This is the read a printed newsletter could never give you, and it is the entire reason to bother with QR over paper.

There is a practical way to use it on a partnership-development rhythm. Sort the export by last-scan date once a month. The names at the bottom, the ones with no open in 60 or 90 days, become your call list before the next appeal goes out, ahead of any drop in giving. The names at the top, the partners who open every update within a day, are the ones to ask for a referral or a bump, because they are already engaged. You are reading the relationship from behavior, not from the gift record alone, and behavior moves first.

What you do not get, and should not tell your sending committee you get, is surveillance. EZQR tracks the code, not the person. There is no name, no email, and no precise location on a scan; the data is the code's activity, the timestamp, the city, and the device type. There is also no instant alert on the lower tiers. Real-time scan notifications are a Max-tier feature; below that you review engagement in the dashboard on your own rhythm. Analytics retention also scales with the plan: Lite keeps 30 days, Pro and Max keep the full history, which matters when you want to compare this quarter's opens to last year's.

The same card that opens your field video can carry the supporter to your support page in one more tap, and the routing is where missionaries get nervous, so be clear about it. EZQR never handles the gift. The QR points to your sending agency's giving platform, the supporter gives there, and that platform issues the receipt and the year-end tax statement under the agency's own tax-exempt status. We are the road sign, not the bank.

This is the right division for missions specifically. Your sending org is the registered charity, your deductible receipts come from them, and your account with them is what stays compliant. A QR that pointed at your personal payment app would break all of that, the same way it breaks deductibility for any nonprofit, so route support-raising QRs to the agency platform every time. The deeper trust-design and receipt mechanics live in the donations playbook, and the nonprofits page covers the registered-org pattern your agency operates under.

On a prayer card you hand out at a sending church, the support QR and the update QR can sit side by side, or you point a single code at a simple page that offers both. The churches page covers how this fits a sending congregation's own giving and connect-card setup, and the church-giving guide covers the giving routing in more depth. Keep the giving destination on a domain a supporter recognizes as your agency's, not a bare checkout URL, because a support gift is a trust decision made in two seconds at the landing page.

Generating one code is a click. Generating a code for every name on a partner list of thousands is a Max-tier job, because the features that make volume sane all sit on that tier. Bulk import from a spreadsheet, the REST API, unlimited dynamic codes, and team access are Max ($20/mo) capabilities. Pro at $10/mo caps at 100 dynamic codes, which a list in the thousands clears in a week, so Pro is the wrong tier for a large partner base even though it is right for a smaller one. The team seats matter here too: an agency with a development office, a media person, and several field staff sharing one partner database needs the 5 seats Max includes, so nobody works out of a single shared login.

The flow has two moves. First, create the codes once: upload a spreadsheet of your partner list and bulk-generate a unique code per row, or call the API to create them in a batch, tagged with each partner's reference so you can match a scan back to a household. Second, re-point them every month. Here is the honest part most tool pages skip: there is no one-click bulk re-point button in the dashboard yet. At thousands of codes, the monthly re-point runs through the API, a short script that walks your list and sends one PATCH /api/v1/qr-codes/[id] call per code to swap the destination to the new field-video URL. It is one job instead of thousands of clicks, but it is a script, not a button, and we'd rather you know that before you commit a list of 3,000 partners to the model.

For a missions team sending to a few hundred partners, none of this applies. You re-point a few hundred codes by hand in the dashboard in an afternoon, or you stay under Pro's cap and skip the API entirely. The API and bulk import earn their keep only when the list is large enough that clicking it monthly stops being realistic.

A card that rides through international post and lives in a supporter's kitchen drawer for years needs more error tolerance than a code on a screen. Generate at error-correction level H, which rebuilds the code from up to 30% damage, so a bent corner or a coffee ring does not kill the scan. Keep strong contrast, a dark pattern on a light field, and leave quiet margin on all four sides. Export a vector file, SVG or PDF on Lite and up, for your printer rather than a low-resolution PNG, so the code stays sharp at any card size.

Put a short, plain instruction next to it. "Scan for this month's update from the field" reads better to a longtime supporter than a bare code. Print the destination address under the QR too, so a partner who would rather type than scan can still reach the update, and so the visible URL reads like your agency, which is its own quiet trust cue. We produce the code and the branded artwork; the card stock, the printing, and the mailing are your print vendor's job, and a mail house will quote those at volume far better than any QR tool could.

Test before the run. Scan the proof on an actual phone, on cellular, with no saved cookies, and confirm the field video loads in under three seconds. A card you cannot cheaply reprint is a card you test twice. If your supporters are spread across countries, test on a phone outside your own region too, because a host that streams instantly at home can crawl on a slower connection, and the supporter who waits ten seconds for a video to buffer is the supporter who closes the tab. The sermon and connect-card guide covers the same print discipline for the cards a sending church hands out, and the rules carry straight over to a prayer card.

The economics favor the card from the first mailing and compound after it. A printed newsletter or a DVD set carries duplication, printing, and postage on every send. An update program on durable cards pays for printing and postage once per partner, then runs on a flat monthly subscription no matter how many updates you release that year. The tier that fits depends entirely on how many partners you have.

You do not need a project to start. Here is the order of operations for the missionary standing this up for the first time, before the next field video goes out. Budget about thirty minutes for the first run; after that the monthly version takes ten.

First, upload the video. Put this month's footage on Vimeo or a video host you control, set the privacy level the content needs, and copy the stable URL. Second, generate one dynamic code per partner pointed at that URL. A small team does this by hand in the dashboard; a large list does it by bulk import from a spreadsheet. Third, brand and export. Add your logo, set error-correction H, and export a vector file for the printer. Fourth, mail the cards once. After that the card stays in their hands for good.

Then the part that repeats. Each month, you record the new update, upload it, and re-point the codes to the new URL: a few clicks for a short list, an API script for a long one. Nothing physical moves again. The same card opens the new video, and your dashboard fills with the per-partner read you never had on paper. If you only do one thing differently this quarter, watch which partners stop opening updates, and reach out before the gift does. That single signal is worth more than every newsletter you have ever printed.

Drop the paper newsletter and the DVD, keep the relationship. Host your field video on Vimeo or YouTube, point a durable QR card at it, and give every partner their own code on a card you mail once. Re-point that code to the new update every month so you never reprint, and let the dashboard tell you which supporters open it and which went quiet, without collecting anything personal about them. Route the support-raising QR to your sending agency's giving page, where the money and the receipt are handled, and keep EZQR as the tracking layer it is.

A few hundred partners run comfortably on Pro at $10/mo. Thousands of partners and a scripted monthly re-point run on Max at $20/mo, with bulk import and the API doing the heavy lifting. Either way the card costs cents, opens on every phone, and outlasts the next time a supporter throws out their last disc drive, which is the one thing a printed update could never promise. If your support flows through a home church, the same codes slot into that congregation's wider giving and connect-card program without a second account.