Payments for Independent Builders

Payment is part of validation

A signup says someone is curious. A payment says the problem, timing, trust, and offer were strong enough for someone to act.

That does not mean every early project needs a complete billing system. Often the best first payment tool is a hosted link you can place in a README, launch post, email, or simple landing page. It lets you test the offer before spending weeks on checkout code.

Before choosing a provider, write down:

• what you sell: a service, physical good, digital download, software license, or subscription;
• where you and your customers are located;
• whether the price is one-time, recurring, fixed, or chosen by the customer;
• who must issue receipts, collect tax, manage refunds, and answer payment disputes;
• how and when money reaches your bank account.

Provider eligibility, fees, payout methods, and product restrictions change. Confirm them on the provider's official site before committing.

Four useful models

1. Hosted payment link

A hosted link is the fastest route from an offer to a real transaction. The provider owns the checkout page while you share a reusable URL.

Stripe Payment Links supports one-time products, subscriptions, and customer-chosen amounts without requiring a custom checkout. It is a good fit when Stripe supports your business country and you are prepared to own the wider business and tax responsibilities that apply to you.

Use it when:

• you need to validate an offer quickly;
• a standard hosted checkout is enough;
• you want control over the product and customer relationship;
• you can manage the obligations that the processor does not take over.

2. Merchant of record

A merchant of record, often shortened to MoR, becomes the legal seller in the transaction. It generally handles payment collection, indirect sales tax, compliant receipts, refunds, and parts of fraud and chargeback operations. You receive a payout under the platform's agreement.

Polar is a developer-focused merchant of record for software and digital products, with products, subscriptions, checkout, webhooks, and automated benefits such as license keys, file delivery, and private community access. Lemon Squeezy and Paddle also use the merchant-of-record model for software and digital products. Gumroad combines a simple storefront with a merchant-of-record model for creator products.

Use an MoR when:

• you sell digital products or software across countries;
• reducing tax and compliance operations matters more than maximum checkout control;
• the provider accepts your business location and product category;
• its fees, payout schedule, customer support boundary, and data access are acceptable.

An MoR removes work, not responsibility for reading the agreement. Understand refund rules, prohibited products, account review, reserves, and what happens if you migrate later.

3. Marketplace or creator platform

A marketplace may combine discovery, storefront, payment, file delivery, memberships, and audience tools. This can be useful when the platform replaces several systems at once.

The tradeoff is dependence: fees may be higher, customer access may be narrower, and the platform can shape how your offer is presented. Treat discovery as a possible benefit, not a guaranteed distribution strategy.

Use a marketplace when speed and built-in operations matter more than owning every layer.

4. Local bank payment

For a small local audience, direct bank transfer can be the shortest path. In Vietnam, VietQR can encode bank, account, amount, and transfer information into a scannable QR flow.

This model is simple at low volume, but reconciliation becomes real work. Give every order a unique reference, verify payment server-side or manually, record refunds, and never treat a screenshot alone as proof of settlement.

Use local bank payment when:

• customers already trust and use the rail;
• transaction volume is small enough to reconcile safely;
• recurring billing and international cards are not requirements;
• you understand the local invoicing and tax obligations.

Donations and sponsorships are different

A donation supports work without purchasing a defined deliverable. A sponsorship may include recognition or an ongoing relationship. A pre-order, paid membership, or software subscription is a sale even if the language around it feels informal.

GitHub Sponsors is useful for supporting an eligible developer or organization around technical work. A customer-chosen payment link may suit one-time support. In every case, describe clearly what the contributor receives and whether a payment is recurring.

Do not disguise a product sale as a donation. Clear language protects trust and makes accounting easier.

A practical progression

Before the first payment

1. Write the offer in one sentence.
2. State the price, currency, refund expectation, and delivery date.
3. Choose one hosted or local payment path.
4. Complete a test payment and refund yourself.
5. Save an order record outside the payment notification email.

After repeated payments

Add automation only where manual work has become risky:

• use webhooks to confirm completed and refunded transactions;
• make event handling idempotent so retries do not fulfill twice;
• keep provider secrets on the server, never in public source or screenshots;
• attach your own order ID to provider metadata;
• monitor failed renewals and make cancellation understandable;
• export transaction and customer records regularly.

Before changing providers

Compare the complete operating cost, not only the transaction percentage. Include tax work, failed-payment recovery, refund handling, support, engineering time, payout delay, migration limits, and the cost of losing a working checkout.

The smallest sensible choice

For an early independent project:

One offer
One price
One hosted checkout or local payment rail
One confirmation path
One order record
One written refund rule

The goal is not to look like a large company. The goal is to let one person pay confidently, receive what was promised, and know whom to contact when something goes wrong.