An app for fundraising is judged by where the money lands and what the donor gets back.

Apple treats a donation differently from a purchase

Guideline 3.1.1 of the App Review Guidelines says that if you want to unlock features or functionality in your app, you must use in-app purchase. That covers subscriptions, premium content, game levels and full version unlocks. A donation unlocks nothing, so this is not the rule that governs it. Charitable money is handled separately, and the separation is the thing most teams get wrong.

Guideline 3.2.1(vi) lets approved nonprofits fundraise directly inside their own apps or inside third party apps, as long as the campaign follows the rest of the guidelines and offers Apple Pay support. Those apps must disclose how the funds will be used, abide by required local and federal laws, and make sure appropriate tax receipts are available to donors. A platform that connects donors to other nonprofits has to make sure every nonprofit it lists has been through the same approval process.

Everyone else falls under guideline 3.2.2(iv). Unless you are an approved nonprofit, collecting funds within the app for charities and fundraisers is not allowed. Apps raising money for such causes must be free on the App Store and may only collect funds outside of the app, for example through Safari or SMS. There is one narrow neighbouring case in 3.2.1(vii): an individual may give another individual an optional monetary gift outside in-app purchase if 100 percent of it goes to the receiver, but a gift tied to digital content has to use in-app purchase again.

One thing to state plainly before you design around any of this. Newly has no built-in payments. Whatever you build with it, the charge runs through a processor you connect yourself or through a page you host, and your approval status with Apple decides which of those is even permitted on iOS. Confirm your own status before you draw the screen, because the answer moves the money off the device or keeps it on.

Apple App Review Guidelines, sections 3.1.1, 3.2.1 and 3.2.2

What the receipt has to say, and by when

Apple requires that appropriate tax receipts are available to donors. United States tax law is more specific about what those receipts contain. Two dollar thresholds do most of the work, and a donation app that does not know them will send out paper a donor cannot use.

The first is 26 U.S. Code section 6115. A charity that receives a quid pro quo contribution in excess of 75 dollars has to give the donor a written statement. It must inform the donor that the deductible amount is limited to the excess of the contribution over the value of the goods or services the organization provided, and it must give a good faith estimate of that value. A quid pro quo contribution is the gala ticket, the raffle entry, the auction lot: money given partly in exchange for something.

The second is 26 U.S. Code section 170(f)(8). No deduction is allowed for a contribution of 250 dollars or more unless the donor substantiates it with a contemporaneous written acknowledgment from the organization. That acknowledgment states the amount of cash, describes any non-cash property without valuing it, says whether goods or services were provided in consideration, and describes and estimates them if they were. Contemporaneous means the donor holds it by the earlier of the date they file the return for that year or the due date of that return including extensions.

The design consequence is that receipt text is a function of the gift, not a template with a name merged into it. The app needs the amount, the fair value of anything given back, and the date, and it has to produce wording that changes when those change. Leave it to a year end batch and somebody will be reconstructing what a donor took home from an auction nine months earlier.

26 U.S. Code 6115, disclosure related to quid pro quo contributions

Peer to peer moves the ask away from you

In a peer to peer fundraising app the organization does not do the asking. Supporters do. Each one gets a page, a target and a link, and sends it to people who have never heard of you. That single change breaks most donation app data models, because a gift now has two people attached to it on your side: the donor who gave it and the supporter who brought it in.

So the record needs a soft credit. The gift belongs to the donor for tax and receipt purposes, always. The credit belongs to the fundraiser, for the leaderboard, the thank you note and next year's recruiting. A school selling raffle books through its pupils meets this on the first day, which is why a school fundraising app is usually built from the team structure outwards rather than from the donate button.

Recurring giving is the opposite shape and needs different fields. A church giving app mostly serves a stable group giving a set amount every month, designated to one fund or another. The interesting parts there are the designation, the pause, the change of amount and the failed card retry. Both patterns can live in one app, but they rarely should. Build the one your money actually comes from and keep the other simple.

What a gift record has to hold

A donation app stores more than a name, an amount and a date. Every gift needs a designation, because money given to the roof fund cannot quietly pay salaries. It needs a method, because a cheque banked on the tenth and a card charged on the first land in different months and different reports.

It needs an acknowledgment state kept separate from the payment state. Paid and thanked are two different facts, and folding them into one flag is how donors get thanked twice or never. It needs an anonymity flag that applies to the public list and not to your own ledger, because an anonymous gift still has to be receipted to a real person.

Pledges belong in their own object. A pledge is a promise, not money, and adding pledges to the same total as gifts is the fastest way to lose the finance team. Keep the pledge, the payment schedule and the actual payments against it as three separate things that reference each other.

All of that is about the record rather than the charge. Fees, failed cards, refunds and the mechanics of moving the money are a separate subject, and taking money inside an app is the place to go once the record design is settled.