When Google Play Rejects Your Donation Link: What AnkiDroid's 501(c)(6) Standoff Taught Me

Two weeks ago I got the email every maintainer of a donation-funded Android app dreads: "Your app changes were not published due to an issue with the following policy." I run a small open-source app on the Play Store that takes donations through Open Collective, and the notice flagged the exact same clause — Payments policy, "In-App Experience," screenshot attached, seven days to fix it or lose distribution. Before I touched a single line of code, I went looking for anyone else who'd hit this recently, and I found a much bigger, much better documented version of my own problem sitting in the AnkiDroid issue tracker.

AnkiDroid is the Android client for the Anki flashcard system, with something like 10 million installs, and its entire funding model runs through an Open Collective page hosted by Open Source Collective, a US non-profit. On August 28, Google started rejecting AnkiDroid's app updates over that donation link, and unless the maintainers resolved it, the app was set to disappear from the Play Store everywhere except India and Russia on September 11. What makes this case worth writing about isn't just the deadline — it's that AnkiDroid did exactly what Google's own policy says to do, submitted exactly the documentation Google asked for, and got rejected anyway on a technicality nobody at Google would explain.

I'm going to walk through what actually happened to AnkiDroid, because the GitHub issue is unusually detailed with full email transcripts, and then show the fix I ended up shipping for my own app while I wait to see how the bigger fight resolves.

What the rejection notice actually says

If you've never seen one of these, the wording is almost comically bureaucratic. The Play Console flags a specific app version, attaches a screenshot of the offending UI element, and cites "Violation of Payment Policy" with a generic explanation that your app is "directing users to payment methods other than the Google Play billing system." It doesn't tell you which text or button triggered it — you have to guess from the screenshot, and in my case the screenshot was just a cropped view of my own about screen with the donate button circled.

The underlying rule lives in Google Play's Payments policy, and the core sentence is blunt about what's normally required. Section 3 of that policy carves out a narrow exception for certain kinds of payments, and outside of that exception, everything has to go through Play's billing system.

"Google Play's billing system must not be used in cases where payments include … tax exempt donations."

Read that carefully, because the phrasing is backwards from what most developers assume. It's not saying donations must use Play Billing — it's saying Play Billing must not be used for tax-exempt donations, meaning an external link is actually the compliant path, provided the recipient organization can prove tax-exempt status. That's the exception AnkiDroid was trying to use, and it's the same exception my app was relying on before any of this started.

The AnkiDroid case: right documentation, still rejected

AnkiDroid's donations flow entirely through Open Source Collective, its fiscal host, which holds an IRS determination letter confirming 501(c)(6) tax-exempt status. When Google's automated compliance system first flagged the app in July 2026, the maintainer — identified in the GitHub issue as "Mike" — asked Open Source Collective for that letter and forwarded it to Google as proof. Benjamin Nickolls, president of Open Source Collective, provided a signed letter stating that donations made through the AnkiDroid Open Collective page "are received and held by Open Source Collective and are exempt from tax."

Google's response, over the following weeks, is the part that's genuinely strange. Google's August 6 email told AnkiDroid that donations may only be collected for a "validated tax-exempt organization (for example, a validated 501(c)(3) charitable organization … or the local equivalent)." AnkiDroid pointed out, reasonably, that they'd already sent exactly that kind of documentation. Google's next reply, on August 7, didn't answer the question — it just repeated that AnkiDroid "allows users to contribute donations to an organization that is not tax-exempt," with no explanation of why a 501(c)(6) determination letter didn't count. As the AnkiDroid maintainers noted in their own write-up of the exchange, Google support never explained why the 501(c)(6) documentation was considered insufficient.

Here's the rough shape of how that exchange played out over six weeks, condensed from the full transcript in the issue:

Under that deadline pressure, the AnkiDroid team made the call to strip the donation link out of their Play Store build entirely, while saying explicitly that they were doing it "under protest." That's the detail that stuck with me — this wasn't a team caving to a policy they misunderstood, it's a team removing a compliant feature because they couldn't get a straight answer from the platform that gatekeeps most of their users.

Why 501(c)(3) and 501(c)(6) aren't interchangeable to Google

The IRS distinguishes these codes for a reason, and it matters here even though Google never spelled it out. A 501(c)(3) is a public charity or private foundation — donations to it are typically tax-deductible for the donor, and the org exists for charitable, religious, educational, or similar public-benefit purposes. A 501(c)(6) is a business league or trade association — it's tax-exempt at the organizational level, but contributions to it are generally not deductible for the person giving the money.

Open Source Collective and its sibling Open Collective Foundation both operate as fiscal hosts specifically because most small open-source projects can't justify the overhead of incorporating and filing for their own 501(c)(3) status. The fiscal host holds funds on the project's behalf and takes on the compliance burden instead. The AnkiDroid GitHub issue includes a pointed clarification of its own: 501(c)(6) status is real tax-exempt status, it's just not the donor-deductible kind — and Google's communications used the word "tax-exempt," not "tax-deductible," throughout.

That gap between what Google's written policy says and what Google's support reps enforce is, as far as I can tell, the entire dispute. The policy text says "tax exempt donations" without specifying which IRC subsection counts. Google's support emails narrowed that, informally and inconsistently, to imply that only 501(c)(3) or "the local equivalent" actually qualifies — a standard that isn't written anywhere on the public policy page, which is exactly why the AnkiDroid issue asks Google directly for clarification rather than assuming an answer.

The fix I shipped for my own app

I wasn't going to bet my app's Play Store listing on Google clarifying its own policy on someone else's timeline. Play Console's automated scanner re-checks every submitted build, and a stuck rejection means real users don't get real bug fixes until the whole thing is resolved, regardless of who's technically in the right.

So I did the boring, defensive thing: split the donation UI out by build flavor, so the Play Store variant never even contains the link, while my F-Droid and direct-APK builds keep it fully intact. Before this fix, my donate button was just always visible, gated on nothing:

// SupportScreen.kt — before
@Composable
fun SupportScreen() {
    Column {
        Text("Enjoying the app?")
        Button(onClick = { openUrl("https://opencollective.com/mynotesapp/contribute") }) {
            Text("Support development")
        }
    }
}

That single unconditional link is exactly the kind of thing a Play Console reviewer's automated scanner flags, screenshots, and attaches to a rejection email. The fix was to gate it behind a build-time flag set per product flavor, so the Play variant literally never compiles that button into the APK in the first place:

// SupportScreen.kt — after
@Composable
fun SupportScreen() {
    Column {
        Text("Enjoying the app?")
        if (BuildConfig.DONATIONS_ENABLED) {
            Button(onClick = { openUrl("https://opencollective.com/mynotesapp/contribute") }) {
                Text("Support development")
            }
        } else {
            Text("Find ways to support this project on our GitHub page.")
        }
    }
}

The DONATIONS_ENABLED flag comes from two Gradle product flavors, playstore and fdroid, each setting a different BuildConfig boolean at compile time instead of checking a runtime setting. That way the Play variant's APK is provably free of the donation link, rather than just hiding it behind a condition somebody could flip back on by accident in a future release. It's not an elegant solution, and I don't love maintaining two flavors just to dodge a policy ambiguity I didn't create, but it means my Play Store users see a plain mention of the project's GitHub page instead of a live external payment link, and I stopped losing sleep over the next automated scan.

The alternatives Google actually offers, and why they're all worse

Once you accept that "wait for Google to clarify the policy" isn't a real plan, you're left choosing among the options Google itself hands you in the rejection email. AnkiDroid's timeline shows this menu appearing twice, in the July automated notice and again in the August 6 human reply, worded almost identically both times.

Google's rejection emails to AnkiDroid listed four concrete options for resolving a Payments policy violation, and they're worth going through because none of them are free for a donation-funded open-source project:

• Remove the donation feature entirely — the option AnkiDroid ultimately took under protest, and the one I took defensively for the Play build of my own app.
• Collect donations through Google Play's own in-app billing system instead of an external link — which means Google's standard revenue cut (up to 30%, 15% for the first million dollars a year under the small business program) applies to money meant to go straight to volunteer maintainers.
• Enroll in the US Alternative Billing System program — only usable if you're offering in-app payment options exclusively to US users, which rules it out for a global app with a global donor base.
• Enroll in Google's External Content Links program — built for directing US users outside the app for promotions, not really designed for a persistent donation link, and it still requires Google's separate approval.

None of these actually solve the problem AnkiDroid ran into, which isn't "can we link outside the app" but "does Google's support team recognize our tax status." Taking a cut through Play Billing doesn't fix that dispute; it just avoids the argument by giving up part of the money instead. That's a bad trade for a project that's entirely volunteer-funded, and I think it's worth saying plainly: Play Billing isn't a neutral fallback here, it's effectively a tax on projects that can't win an unwinnable classification argument with a support queue that won't engage with the substance of what they're asking.

What I'd check before you ship anything similar

If your app has any kind of "support the developer" link and you distribute through Play, don't assume your fiscal host's paperwork will save you the way it apparently should have for AnkiDroid. Check what tax status your fiscal host actually holds — 501(c)(3), 501(c)(6), or something else entirely if you're outside the US — and don't be surprised if Google's support team ends up applying a narrower standard than the one actually written in the policy page.

It's also worth remembering that the trigger isn't limited to an obvious "Donate" button. Reviewers' automated scanning has flagged plainer things than that in the past, and the surrounding discussion around cases like this one includes reports of donation mentions buried in an about screen or a linked README getting caught the same way.

I'd keep an eye on how the AnkiDroid situation actually resolves, too, because whatever precedent gets set there — whether Google eventually accepts a 501(c)(6) determination or holds the line regardless of documentation — is going to be the de facto answer for every other Open Collective-funded Android app watching this play out from the sidelines. Until that's settled, I'm treating the F-Droid build of my app as the "real" home for the donation link and the Play build as the version that just points people toward it.

Where this leaves donation-funded apps on Android

The technical fix here — build flavors, a compile-time flag, a plain mention of a GitHub page instead of a live link — took me about an hour to ship, and most maintainers in the same spot could do the same in an afternoon. The actual problem, getting a platform's support team to apply its own written policy consistently, isn't something a Gradle config can fix, and I don't think there's a clean workaround for that part short of public pressure or a policy update from Google itself. If you're maintaining a donation-funded app and haven't been flagged yet, don't take that as a sign you're compliant; it just means the automated scanner hasn't gotten to your listing this month. Split your donation UI out by distribution channel now, while it's a calm decision you can make on your own schedule, rather than during a seven-day countdown with your app's future on the line.

Sources: AnkiDroid — [Community Help Needed] Google Play: no longer allowing our Open Collective donation link (GitHub Issue #21656)