SellstampSubscriptions
Recurring revenue, and an honest
account of who is billing it.
A subscription is a product type in your catalogue: monthly or yearly, with an optional trial, sold down the same checkout as everything else. The billing itself belongs to your payment provider, and this page is specific about which one that can be.
Subscription · lifecycle
- 01Trialno charge yet
- 02Activeprovider bills, Sellstamp records
- 03Past duegrace period, three emails
- 04Cancellingone retention offer, once
- 05Endedone transition, one ledger row
Which provider can actually bill one
The payment-provider contract has a recurring capability, and one connectable adapter sets it: Stripe. That is not a roadmap sentence — it is the flag the checkout reads.
Refused early, not halfway
A subscription product on a provider that cannot bill recurring is refused before anything is created. No order, no half-made subscription, no support ticket about a customer charged once.
A Stripe connection needs one more thing
A webhook signing secret dedicated to the subscription route, separate from the one your ordinary payments use. Without it the sale is refused, because taking money Sellstamp could never confirm is worse than not taking it.
Everything else still sells
The other providers take one-off orders exactly as they always did. Only the recurring product type is narrowed.
Where the truth about a subscription lives
Not here. Sellstamp records what your provider says and enforces the order it says it in, so a duplicate delivery, a late webhook or a replayed request body cannot move a subscription somewhere it never went.
- Nothing a browser says is written
- Status, billing periods, trial end and the provider's own ids all come from a signature-verified webhook or a server-side read of the provider. A forged or replayed request body cannot assert a subscription is active.
- A redelivered event is a no-op
- The uniqueness of (provider, event id) is the barrier, in the database, rather than a lookup that can race. Providers retry; retrying changes nothing twice.
- An out-of-order event is skipped, and recorded
- Events arrive out of order. One older than the state already held is written to the ledger and not applied, so the history stays complete while the state stays correct.
- An illegal transition is never forced
- Transitions go through a pure state machine. A change it does not allow is recorded and refused rather than written anyway.
What you can change while it runs
Every one of these is the provider's own operation, read back and recorded. Sellstamp computes no proration and stores no discounted amount, so nothing local can drift from what was billed.
- Move a customer to another plan
- Resolved server-side from your own product rows — no provider price id ever comes from a browser — and the provider computes the proration and raises whatever invoice it decides to.
- Pause and resume collection
- The pause lives on the provider's subscription. There is deliberately no local “we stopped billing but the provider does not know” flag.
- Cancel at period end, or change your mind
- The customer cancels from their portal and keeps access to the end of what they paid for; reactivating before that date undoes it.
- One discount to stay, offered once
- A percentage off for a number of months, minted as the provider's own coupon with a single redemption, attached to the live subscription. A coupon you added yourself in your provider's dashboard is kept, not replaced.
- Trials
- Read from the product row server-side, never from the request body. Zero days means charge immediately.
- Prices in more than one currency
- The per-currency price you typed applies here too. Nothing is converted — a subscription is charged the number you set for that currency.
When a payment fails
- This is not a payment retry
- Stripe runs its own retry schedule against the customer's bank and only then reports past due. By the time a subscription reaches Sellstamp's dunning, the money has been asked for and refused; what is left is the part you own — how long access survives it, what the customer is told, and what happens at the end.
- A grace period you set
- Stamped when the payment fails. Access continues through it, and one transition happens when it runs out.
- Three messages inside it
- Sent at the start, around the middle and near the end, as fractions of your grace window rather than fixed days — so the sequence still makes sense whether you set two days or fourteen. The position is claimed by a conditional update before anything is sent, so an overlapping worker pass cannot send one twice.
- And before it fails at all
- A card about to expire gets its own, earlier sequence. The expiry is read live from the provider each time, because no card fact is stored anywhere in this system — there is nothing local to ask.
What the customer sees
A portal they reach from their email, with no account to create. It is a query over what Sellstamp already recorded rather than a live call to your provider on every page view.
Their invoices
Recorded from the provider's own billing events — number, amount, currency and the provider's hosted invoice link. No PDF is stored or rendered here.
Their own cancel
Cancel, see the retention offer if one applies, accept it, or reactivate. The merchant does not have to be in the loop for any of it.
Their payment method
Updated on the provider's own hosted billing page, because that is the only place a card should be typed.
Limits worth knowing before you build on it
What this does not do
- No recurring billing on PayPal, Monri, CoinGate, Mollie, KEKS Pay or any manual method. The capability flag says so and the checkout enforces it.
- No usage-based or metered billing. A subscription is a fixed price on a monthly or yearly interval.
- No proration arithmetic of Sellstamp's own, anywhere. The provider's number is the number.
- No stored card facts — not a brand, not a last four, not an expiry. Anything about the card is a live read of the provider.
Open a store and try it.
Everything on this page is in the product today. Connect a provider in test mode and put a real order through it before you decide.