Paddle on StackOnward

How to Model SaaS Products, Plans, and Prices

Fri, 11 Sep 2026 04:18:00 +0800

RouteNest is about to raise Pro monthly from $19 to $24. If the system stores one mutable row—plan=pro, price=19, stripe_price_id=...—writing 24 over 19 removes the basis for existing subscriptions. Whether the $190 annual price moves, whether the euro price is recomputed, which amount WELCOME20 discounts, and which Paddle or Creem object to charge all become guesses.

How to model SaaS products and prices depends on when each fact changes. Product says what is sold. Plan says which features and limits the buyer receives. Price says amount, currency, interval, and version. A promotion only changes a qualifying sale. A provider mapping only projects an internal Price onto a payment channel. Orders and subscriptions must store the snapshot from the sale; they cannot reread “the current price” to explain the past.

Why a Payment Processor Application Gets Rejected, and How to Resubmit Evidence

Fri, 11 Sep 2026 04:16:00 +0800

A payment processor application is rejected when a reviewer cannot independently match who is selling, through which domain, what the buyer receives after payment, who handles cancellation or refunds, and who receives the net proceeds. Genuine files still fail when those facts point at different businesses.

The application names Northstar Labs, Inc.. The site footer only shows the product name RouteNest. The pricing page sells a USD 19 monthly auto-renewing subscription, while the refund page still describes a one-time download. The product is behind login and the reviewer has no account. The payout account still names the founder personally. Each of those statements can be true. Together they do not say who sells what, how it is delivered, or where the money goes.