Written by Introduction
Open source maintainers often sit in a strange spot: you create real infrastructure that companies depend on, but the payment workflow is unclear.
Some maintainers rely on donations or sponsorships. Others do paid support, priority fixes, audits, or integration help. In all cases, the challenge is the same: you need a simple way to request payment that doesn’t require you to run a full invoicing operation.
Payment requests are a practical tool here. They let you attach a clear “pay this” action to a specific piece of work.
The Typical Workflow Problem
The default maintainer workflow often looks like:
- A company asks for help (bugfix, feature, audit, support)
- You agree on scope
- You do the work
- You send an invoice (or ask “how do you pay contractors?”)
- The process slows down
Friction points:
- You’re not in their vendor system
- They need procurement approval
- International payments create friction
- The request isn’t owned (engineer asks, finance pays)
If you’ve ever tried to request payment from client (a company) as a maintainer, you know the real issue is workflow ownership.
Maintainership is “services” even when it doesn’t feel like it
Companies often treat maintainer work like a service purchase:
- “Can you prioritize this fix?”
- “Can you review our integration?”
- “Can you help us understand the roadmap?”
If you frame your work as a deliverable with an outcome, payment becomes easier to approve.
Payment Requests (Instead of Invoices)
Payment requests simplify the “last mile.”
Instead of a PDF invoice that needs processing, you provide a link that can be forwarded internally with minimal explanation.
It’s effectively a freelancer payment link attached to maintainer work.
What to use payment requests for
Common maintainer-paid work:
- Priority bugfixes
- Security reviews or audits
- Integration support (“help us adopt this library”)
- Paid office hours
- Long-term support contracts (broken into monthly cycles)
This is also a clean way to charge clients online for support without building a sales/billing stack.
How to scope maintainers’ paid work (so payment doesn’t slip)
Keep scope tight and outcome-based:
- One issue
- One release
- One audit report
- One support session
Then attach the payment request to that outcome. The more specific the deliverable, the easier it is for the company to approve and for you to avoid endless “can you also…” requests.
Optional: define a simple support tier
If you do recurring paid support, define a lightweight tier so companies can justify the spend:
- Response time (e.g., 2 business days)
- Scope (e.g., integration questions + troubleshooting)
- Duration (e.g., monthly)
Then send a payment request per cycle. This is a practical way to make maintainer work “purchasable” without building a full sales process.
Gitpay Payment Requests (Natural Fit)
Gitpay allows service providers to create payment requests and share a payment link with clients.
- Gitpay homepage: https://gitpay.me
- Gitpay payment requests (service payments): https://gitpay.me/#/use-cases/service-payments
You can keep the workflow straightforward:
- Define the work
- Deliver the work
- Share the payment request link
If procurement is strict
Some companies require vendor onboarding. In those cases, payment requests still help because they create a single “pay this” step once onboarding is complete. You can also ask the company what they need up front:
- Who pays contractors?
- Do you require an invoice or PO?
- What’s your typical payment cycle?
This reduces surprises.
Example Use Cases
1) Priority fix for a company
Deliverable: “Fix for issue #123 + release v1.2.3.”
Send:
- Link to the release notes
- Any migration steps
- Payment request link
2) Security audit
Deliverable: “Audit notes + recommended patches.”
Tie the payment request to a concrete report.
3) Paid support session
Deliverable: “60-minute support call + notes.”
This is the maintainer version of “get paid online freelance”: knowledge work with a simple payment step.
4) Sponsorship-style payments
If a company wants to support the project, a payment request can function as an easy-to-action sponsorship payment.
5) Priority roadmap session
Deliverable: “60-minute roadmap alignment + written summary.”
This gives teams a clear way to get maintainer time and gives you a clean way to close the loop on payment.
Why This Workflow Is Simpler
Payment requests help maintainers because they reduce admin work and make payments easy for companies:
- No complex invoicing software required to get paid for support
- Easy forwarding inside a company
- Clear scope attached to each request
- Good for international payments
- Works for digital deliverables like releases, audits, and support
One-minute checklist for company payments
To make it easy for your contact to get approval, include:
- The deliverable outcome (“release v1.2.3 with fix X”)
- A link to the work (issue/PR/release notes)
- The amount
- The payment request link
It’s the difference between “please pay a maintainer” and “please pay for this concrete outcome.”
A maintainer-friendly habit
When you deliver a fix or report, include the payment link in the same message. Treat payment as part of delivery, not a separate task.
A simple note for companies
If you want to make it easy for your contact, include a one-liner they can paste in Slack:
Maintainer delivered (fix/audit/support). Please pay using this link: (payment request link).
CTA
If you want a simpler way to get paid for open source support or deliverables, you can try creating a payment request on Gitpay:
- https://gitpay.me
- https://gitpay.me/#/use-cases/service-payments
