Payment Stack for Solo Founders: Stripe, Paddle, Lemon Squeezy, or WeChat Pay?

Disclaimer: This article does not provide tax, legal, company-registration, foreign-exchange, or entity-eligibility advice. For Merchant of Record arrangements, VAT/GST/sales tax, domestic or overseas entities, and payout routes, rely on provider terms and qualified professional advice.

Your pricing.ts defines starter_monthly, pro_yearly, lifetime_license, and wechat_one_time, but the database has only one is_paid field. A checkout.session.completed webhook arrives and the customer returns through success_url, yet entitlements is still empty. The problem is not the payment button. The payment system has failed to connect products, orders, subscriptions, and access rights.

A solo founder should answer five questions before choosing a provider: What are you selling? How is it billed? Who is buying it? Who owns the transaction and sales-tax responsibilities? Who grants access after payment? Stripe, Paddle, Lemon Squeezy, and WeChat Pay are not four equivalent buttons. They cover different layers and responsibilities.

Define the Sales Model Before Choosing a Payment Provider

One-time purchases revolve around orders and delivery. SaaS subscriptions require the full billing lifecycle. Usage-based billing also needs traceable usage data. Put the model into products, prices, and local tables before comparing providers.

Keep three points in mind:

• A one-time product primarily needs orders, fulfillment, refunds, and redelivery. It does not need the full subscription lifecycle.
• A SaaS subscription needs a subscriptions table with current_period_start/end, cancel_at, and status. Metered billing also needs auditable usage_events.
• WeChat Pay is a payment rail and merchant system, not a replacement for a global Merchant of Record or SaaS billing platform.

Stripe Billing, Paddle Billing, and WeChat Pay capabilities can change. Before implementation, recheck account region, product mode, payment-method eligibility, API version, and provider terms.

A Merchant of Record Does Not Remove Every Responsibility

A Merchant of Record, or MoR, is the seller of record for a transaction. Paddle and Lemon Squeezy both use the Merchant of Record model for eligible digital products and handle payments, sales tax, refunds, or disputes within the scope of those transactions. This reduces global sales-tax and billing operations, but it does not eliminate the creator’s or company’s income-tax, entity, product-compliance, data-protection, and accounting obligations.

KiloClaw - Managed OpenClaw for enterprise, enabling AI Agent orchestration and smart model routing

Get Started →Ad

With the Stripe route, the merchant normally remains the seller of record. Stripe Tax can help calculate sales tax, VAT, and GST and provide threshold-monitoring and registration-related tools, but it does not automatically make Stripe your Merchant of Record. Registration, filing, and entity responsibilities depend on the jurisdiction and transaction.

Do not choose an MoR from a fixed revenue threshold. Compare these dimensions instead:

The final contract and tax boundary depends on the entity, jurisdiction, product, and customer type. Marketing pages describe product positioning; they do not replace provider terms or professional advice.

Choosing Between Stripe, Paddle, Lemon Squeezy, and WeChat Pay

If you want subscriptions and WeChat Pay, split the problem first. Subscription lifecycle, global payments, and mainland-China payment coverage do not have to come from one provider. A payment method appearing on a platform does not mean it works for every account region, Checkout mode, or recurring flow.

The following points were confirmed in official documentation on July 18, 2026:

• Stripe Checkout supports hosted pages, embedded pages, and composable components. Payment methods depend on region, currency, and Checkout mode.
• Paddle webhooks use at-least-once delivery. Paddle retries when an endpoint does not return 200 within five seconds. Events can be duplicated or arrive out of order, so deduplicate with event_id and use occurred_at when reasoning about sequence.
• Lemon Squeezy currently lists Cards, PayPal, Apple Pay, Google Pay, Alipay, WeChat Pay, Cash App Pay, and bank debits. Subscription products currently support only Cards, Apple Pay, Google Pay, and PayPal.
• A WeChat Pay H5 flow requires server-side order creation, payment callbacks, and active order queries. A browser redirect alone is not authoritative.

Fees, payment methods, settlement schedules, supported countries, and product policies can all change. Open the provider’s current pricing and contract pages when building the final budget instead of copying an old percentage from an article.

Webhooks Are the Entitlement-Sync Boundary

Consider two common failures:

1. checkout.session.completed arrives and success_url redirects, but entitlements is not updated, so a paying customer still cannot use the product.
2. The same event reaches webhook_events twice, and the handler issues two licenses.

Both failures come from treating one HTTP request or a success page as final business truth. Payment events can be duplicated, delayed, or delivered out of order. Some states also require an order query or a later event for confirmation.

Webhook Endpoint Design Principles

The operating rules are straightforward:

• A webhook or payment callback is the entitlement-sync entry point. success_url should display “processing,” not grant access.
• Verify the signature first, then store the raw event or required fields in webhook_events. Move complex business work to an asynchronous job.
• Enforce idempotency with a unique constraint. Record event_id, source, occurred_at, processed_at, status, and payload_hash.
• For out-of-order delivery, compare provider event time, object update time, or state version. Do not overwrite state based only on request arrival order.
• Run reconciliation periodically, query order or subscription state, and keep a manual recovery path.

Orders, Subscriptions, Entitlements, and Events

Do not copy every object from one provider’s API into local tables. Define the stable fields needed for access checks, then store provider object IDs for queries and reconciliation.

Vultr - High-performance NVMe VPS with 32 global locations, one-click Docker deploy

View Pricing →Ad

Entitlement Synchronization Strategies

Paddle’s official provisioning documentation recommends a lean cache for most applications. Move to a state mirror only when richer local queries are necessary. Lemon Squeezy license keys also require application-side validation of product and customer data and a mapping from each instance to your account and device model.

Provider-Specific Implementation Notes

These notes define the first implementation boundary. They do not replace each provider’s complete integration documentation.

Stripe Implementation Notes

An early SaaS product can start with hosted Checkout and Customer Portal rather than maintaining a custom card form. Stripe Billing handles lifecycle capabilities such as subscriptions, invoices, usage-based billing, and revenue recovery. Stripe Tax is a tax calculation and workflow tool, not a Merchant of Record.

Products and prices must map to local entitlements: product_id represents a product or access package, while price_id represents monthly, annual, per-seat, or usage pricing. Do not leave only is_paid on the users table.

For an implementation example, see the Next.js cart and Stripe payment tutorial, which covers Checkout Sessions, a webhook endpoint, and order handling.

Paddle Implementation Notes

First confirm that a tutorial targets Paddle Billing rather than Paddle Classic. Their APIs, webhooks, Paddle.js versions, and Product/Price models differ.

Paddle Checkout presents the checkout, but your application still owns provisioning. Most applications only need the customer, subscription, status, price, product, and scheduled-change fields involved in access decisions. Build a state mirror only when the operations interface truly needs complete billing data.

Whichever cache model you choose, update it through webhooks and run reconciliation. Using a Merchant of Record does not make the application automatically know who can access each feature.

Lemon Squeezy Implementation Notes

Lemon Squeezy is a practical starting point for early digital products, licenses, and relatively simple subscriptions. It provides a Merchant of Record, checkout, subscriptions, usage-based billing, webhooks, and License Keys. Confirm actual fees and support against the current store plan and documentation.

Railway - Modern deployment platform, zero-config, go live in minutes

Start Now →Ad

After activating a license key, save the instance ID and validate store_id, product_id, variant_id, and the customer. A key for another product or a resold key must not map directly to a Pro entitlement.

If the requirement is a WeChat Pay subscription, verify subscription payment methods separately. The current documentation lists WeChat Pay and Alipay as available payment methods, but subscription products support only Cards, Apple Pay, Google Pay, and PayPal.

WeChat Pay Boundaries

WeChat Pay works well for mainland-China and WeChat checkout, but it is not a global Merchant of Record and does not provide a complete SaaS billing lifecycle. The merchant still needs order state, callback signature verification, order queries, refunds, reconciliation, invoicing, and entitlement synchronization.

H5, JSAPI, Mini Program, and Native are payment scenarios, not separate subscription systems. In an H5 flow, the backend creates an order and passes h5_url to the frontend. When the browser returns, the backend still queries the order and applies the payment callback to the order identified by out_trade_no.

Confirm product permissions, merchant entity, domains, fees, and API parameters against the current WeChat Pay merchant documentation.

Next Step: Turn the Payment Button into a Testable State Machine

After choosing providers, break the integration into testable engineering tasks:

1. Create orders, subscriptions, entitlements, and webhook_events. Add usage_events for metered billing.
2. Implement signature verification, idempotency, out-of-order handling, fast acknowledgment, and failure recovery for every webhook or payment callback.
3. Make the success page query local order state instead of setting is_paid=true.
4. Add tests for provider queries, reconciliation, refunds, failed renewals, and manual recovery.
5. In the sandbox, resend events and deliver state updates out of order. Verify that access is neither granted twice nor rolled back incorrectly.

For backend deployment and database choices, continue with the Supabase Edge Functions guide and the backend and database articles in this series. Completion is not a successful payment-page redirect. It is the point where orders, subscriptions, and entitlements converge on the correct state despite duplicates, delays, out-of-order delivery, and refunds.