One link for every repo
README, FUNDING file, docs footer, CLI upgrade notice. The same short URL works everywhere you already ship text.
For open source maintainers
Put one URL in the README, the docs footer, and the release notes. Tips from users, monthly tiers from companies, and a goal for the maintenance nobody wants to do.
Why it works
README, FUNDING file, docs footer, CLI upgrade notice. The same short URL works everywhere you already ship text.
A named monthly tier with a receipt is something a team lead can push through procurement. An anonymous donate button isn't.
A goal attached to a specific milestone — a migration, a rewrite, a year of security patches — raises far more than a general appeal.
A developer who just had a bug fixed will tap once to say thanks. They won't fill in a card form to do it.
Where the link goes
The highest-converting moment in open source is right after something worked — a fixed issue, a successful upgrade, a docs page that answered the question. Put the link there, not just on a sponsors page.

Corporate support
Individual tips are lovely and small. Sustained funding comes from businesses that depend on your project — and they need an invoice, a receipt, and a named tier to justify it internally.

Transparency
Posts let you publish what got done with the funding. Nothing sustains sponsorship like a visible line between money in and maintenance out.

Getting started
01
Use the project name rather than your personal one if the project is bigger than you are.
02
One-time verification, then payouts to your bank on a rolling two-day schedule.
03
Name it after what it buys — an hour of maintenance a month is easier to justify than a generic tier.
04
Top of the README, footer of the docs, and one line in the next release notes.
The standard pattern is a donate button on a sponsors page that nobody visits, asking for money in the abstract. It converts badly because it's disconnected from any moment where the project delivered value.
Funding works when it's adjacent to relief. The upgrade that went smoothly, the issue that got closed, the documentation that saved an afternoon — those are the moments where an ask feels earned rather than begged.
Treat them as two different audiences with two different asks. Individual developers respond to a low-friction tip: one tap, small amount, no account, done in seconds.
Companies respond to structure: a named tier, a monthly amount, a receipt, and something to point at in a report. Make the second path obvious and give it a price a manager can approve without a meeting.
'Support development' is a weak ask. 'Two days a month on issue triage and security patches' is a strong one, because it describes work someone can imagine not happening.
Publish an update when a goal is met. The projects that sustain funding are the ones that close the loop between the money and the maintenance.
FAQ
Yes. Many maintainers list several funding routes. Put whichever converts best first and keep the others as options.
Every payment produces a Stripe receipt. For companies needing a formal invoice, Stripe's data covers the details your accountant will ask for.
The page belongs to the connected Stripe account, so an organisation account can hold it rather than an individual.
A plain link works everywhere and never breaks. Standard shields-style badges pointing at your thx.so URL work fine too.
Yes — funds settle in your own Stripe Connect account and pay out to your bank. Nothing is held in a platform balance.