The first month of a new subscription marketplace usually goes well. Buyers sign up, sellers ship, the commission lands. The harder questions arrive in month two, when a card fails on renewal, a seller raises the price of a monthly box, or a buyer pauses halfway through a cycle and asks for part of their money back. Each of those is a decision someone has to make, and each one changes an order, a payout and an accounting record at the same time.
That is the real difference between a one-off marketplace and a subscription marketplace. With one-off orders, you settle who gets paid, who ships and what goes to the accounts once per sale. With renewals, the same questions come back every cycle, across every seller, and the answers have to stay consistent. Every renewal is a new order, and it has to agree with the books. If you decide up front who owns the subscription, who can change it, which price a renewal uses and where each renewal is recorded, most of the later problems become routine. If you leave those choices to whatever the software does by default, you find out what it does when your accountant asks why the payouts and the invoices disagree.
Questions operators ask first
What is a subscription marketplace?
A subscription marketplace is a marketplace where charges repeat on a schedule. Either sellers pay the marketplace a recurring plan, or buyers subscribe to sellers’ products or services, such as subscription boxes, memberships or replenishment orders. Both are a form of subscription based marketplace. Some marketplaces run both.
Does every renewal need its own invoice?
In most set-ups, yes, because each renewal is a separate sale with its own charge, order and tax. Where e-invoicing applies, each renewal invoice carries the required fields when it is issued.
Should commission apply to renewals as well as the first order?
That depends on your terms with sellers. Commission can apply to every renewal at the rate fixed at sign-up or at the current rate. Each payout should record which rate it used.
What happens to subscribers if a seller leaves?
They are usually cancelled with notice or moved to another seller, often by subscribing again. Depending on how payments were set up, the marketplace may not be able to change or cancel them itself, so plan the exit before you need it. The section on sellers leaving below explains why.
Can existing subscribers keep their original price?
Yes, if each subscription stores its own price snapshot. The renewal then charges that price until you move the subscriber to a new one with notice. The order and invoice should always show the price actually charged.
Two models, and whether you run both
The term covers two different businesses. In the first, sellers pay the marketplace a recurring plan to list, sell or access tools. Those vendor subscriptions are a relationship between you and each seller, and the buyer never sees them. The marketplace earns a recurring fee from each seller, whatever they sell that month. In the second, buyers subscribe to a seller’s product or service: a monthly box, a membership, a replenishment order for something they run out of. Here the recurring payment is between the buyer and the seller, and the marketplace sits in the middle taking commission.
The two models produce different recurring revenue. Seller plans give the marketplace income that arrives whether or not buyers order. Buyer subscriptions give it a share of each renewal, so its income rises and falls with what subscribers keep paying for. Both are a subscription model, but they put different questions to your finance team: one asks how many sellers stay on their plans, the other asks how many buyers keep renewing across multiple vendors.
Some subscription businesses run both on the same online platform. A seller pays a monthly plan, and their buyers subscribe to their products. That is workable, but the two charges have different owners, different invoices and different refund rules, so they should be kept apart in the records from the first day. A seller plan is income for the marketplace. A buyer subscription is mostly the seller’s income, with your commission taken out.
Who the subscription belongs to, and who can cancel it
When a buyer subscribes to a seller in a subscription marketplace, someone has to be the owner of that agreement. Either the marketplace holds it, and the seller is told what to ship each cycle, or the seller holds it, and the marketplace takes its commission from each charge.
If the marketplace holds it, you control the buyer experience: one place to pause, one place to cancel, one set of rules. You also carry more of the responsibility when something goes wrong, because the buyer sees you as the party who charged them. If the seller holds it, sellers get more freedom to set their own terms, and the marketplace has less to answer for. The cost is consistency. Buyers with subscriptions from three sellers may meet three different cancellation flows, and your support team has to know which one applies. For the customer experience, that is often the part buyers remember.
Ownership also decides who can change the subscription. A useful test is to write down, for each action (change quantity, change price, pause, skip, cancel, refund), who is allowed to do it: the buyer, the seller, your operations team, or a combination. That list becomes your permissions, and it is far easier to agree before launch than after a dispute.
Subscription management also needs an owner inside your own team. Someone has to answer when a buyer writes in asking why they were charged, when a seller asks to change the subscription plans they offer, and when the two disagree. If the marketplace holds the subscription, that person sits in your operations team. If sellers hold it, you still need someone who can see every seller’s subscriptions in one place, or support turns into forwarding emails.
One cart, several sellers
What the subscriber sees
A buyer adds a monthly coffee subscription from one seller and a quarterly equipment service from another, then checks out once. In your records it is at least two subscriptions, with different cycles, different sellers and different payouts.
The decision is whether the cart creates one subscription per seller or one combined subscription that the marketplace splits on each renewal. Separate subscriptions per seller keep each seller’s renewals, failures and cancellations independent, which keeps the accounting clean, though the buyer sees several charges on their statement. A combined charge looks tidier to the buyer, but every renewal then needs a split, and a failure or a cancellation on one seller’s part affects the whole charge. How each payment is divided between sellers and the marketplace is covered in more detail in our guide to marketplace payment splitting. For subscriptions, the extra question is whether that split is worked out again on every cycle or fixed when the buyer first subscribes.
What the subscriber manages afterwards
After checkout, the buyer needs one place to see every active subscription, from every seller, with the next renewal date, the amount and the delivery address for each. If each seller’s subscription is managed separately, the buyer still expects to update their payment details once and have every subscription use the new card. Decide whether a change of card or address applies to all of a buyer’s subscriptions or only to one, and make the screen say which. Small things like this shape the customer experience more than the checkout does, because the buyer meets them every month.
When a renewal fails
A card expires, a bank declines, a balance runs short. Every subscription marketplace meets this in its first weeks of renewals. In a single-seller shop, the shop retries and emails the customer. In a recurring payments marketplace, three parties are affected, and each needs to know something different.
The buyer needs to be told and given a way to update their payment details. The seller needs to know whether to ship. The marketplace needs to know whether a commission is owed, and whether an order exists yet. The hard decision is the seller one. If the seller ships while the payment is retried, the buyer keeps getting their product on time, but the seller carries the risk of shipping something that is never paid for. If shipping waits for a successful payment, nobody ships unpaid goods, though buyers may get late deliveries and cancel.
Retries and notices
Most subscription billing handles failed payments with a retry schedule and a series of notices, often called dunning. The schedule decides how many times the charge is tried again and how far apart. The notices decide what the buyer is told each time: that the payment failed, how to update their payment details, and what happens if nothing changes. Write the wording for each notice, and decide who sends it. A notice from the marketplace about a seller’s product can confuse buyers if the seller sends its own notice as well.
Decide also what the seller sees during the retry period. A seller with dozens of subscribers needs a list of failed payments that are still being retried, the ones that have recovered, and the ones that have given up, so they can plan what to pack. When the last retry fails, the subscription is usually paused or cancelled, and that status change has to reach the seller before their next packing run.
Failed payments also touch commission. If a renewal recovers on the third retry, the commission and the payout follow the date the money arrived, which may fall in a different payout period from the original renewal date. Your payout reports need to show that clearly, or sellers will ask why a renewal appears in the wrong month.
Whichever you choose, decide when the order is created, and make sure order, payment and payout status move together. If an order is created at the scheduled renewal date, a failed payment leaves an unpaid order in the system that has to be marked, retried or voided. If the order is only created once payment succeeds, the records stay clean, but the seller’s fulfilment planning sees the order late.
Pause, skip and cancel mid-cycle, and how a refund is split
Buyers in a subscription marketplace expect to pause for a month, skip a delivery or cancel. Each sounds simple, and each raises a money question when it happens partway through a paid cycle.
If a buyer cancels ten days into a monthly cycle, you can let the subscription run to the end of the period with no refund, or refund the unused part. Running to the end is simpler and leaves the order, payout and invoice untouched. A partial refund is friendlier, but it means calculating the unused share, deciding who pays it back, and creating a credit note that matches. If the seller has already been paid out, the refund has to come back from the seller, or the marketplace covers it and recovers it later. Commission adds another layer: does the marketplace return its commission on the refunded part, or keep it?
A skip is easier if it happens before the renewal charge. Once the charge has gone through, a skip becomes a refund or a credit against the next cycle, and the credit has to be tracked until it is used. A pause raises the question of what happens to the renewal date when the buyer comes back.
Refund rights, cooling-off periods and how tax is treated on partial refunds and credits vary by country and by product. Those rules need an accountant or a lawyer who knows the markets you sell into. The software can apply whatever rule they give you, but it cannot decide the rule for you.
Commission on every renewal
In a subscription marketplace, commission on the first order is easy to set up. The question is what happens on renewal twelve. If the commission rate is stored once at sign-up, every renewal uses the rate that applied when the buyer subscribed. If it is read from the seller’s current terms, a change in your commission policy applies to existing subscribers from their next renewal.
Both are reasonable. Locking the rate at sign-up makes each renewal predictable for sellers, but you may end up running several commission terms side by side for years. Reading the current rate keeps one set of terms, though sellers may see their margin on an existing subscriber change without warning. Either way, each renewal’s payout should record the rate it used, so that a seller asking why a payout looks different can be answered from the record itself.
A price change for existing subscribers
A seller raises the price of their subscription boxes. New subscribers pay the new price. The open question is existing subscribers: does their next renewal charge the price they agreed at sign-up, or today’s price?
Keeping the original price protects buyers and avoids complaints, but it means each subscription carries its own price, and you need a way to move people to a new price later, with notice, if the seller asks. Using today’s price keeps one price list, but every price change becomes a notice you have to send and, in some markets, a consent you have to collect before the change applies. Whichever way you go, the renewal order has to record the price it actually charged, the unit and the tax, so that the invoice matches the charge even if the catalogue price has since moved.
For a Malaysian paint manufacturer whose orders, stock and production run on a system KVY built and has operated since January 2025, each order line keeps a snapshot of price, unit and tax at the moment of sale, and orders sync to its accounting system, QNE Cloud, with Malaysian e-invoice fields. A later price change never alters an order already taken, and the accounting record matches what the customer was charged. A subscription renewal needs the same discipline, with one more decision on top: which snapshot the renewal copies, the one from sign-up or a fresh one from the current price. The accounting record has to match whichever one it is.
From renewal to order to invoice to accounting
Each renewal should produce the same chain as a one-off sale: a charge, an order the seller fulfils, an invoice to the buyer, a payout record for the seller, a commission record for the marketplace, and entries your accounting system receives. The common failure is that the payment provider records the charge and the marketplace records nothing else, so finance rebuilds the month from payment exports.
The payment processing side and the order side usually live in different systems, and each one is right about different things. The payment provider knows whether money moved. The marketplace knows what was ordered, from which seller, at what price and with what commission. The accounting system needs both.
The decision here is where the renewal is first recorded and which system is the reference. If the payment provider leads and the marketplace listens for its notices, a missed notice means a charge without an order. If the marketplace leads and asks the provider to charge, the marketplace has to handle retries and outcomes itself. Either can work, as long as one system is the reference and a daily check compares charges, orders and invoices and flags any that do not match. Where e-invoicing applies, each renewal is an invoice in its own right and has to carry the required fields at the moment it is issued.
When a seller leaves
In any subscription marketplace, sellers close shops, move to another online platform or are removed. With one-off orders, you finish the open orders and pay out. With subscriptions, there are active subscribers who expect another renewal next month.
The payment set-up shapes your options. A payment provider such as Stripe supports three patterns for subscriptions on a marketplace: end customers subscribing to a seller’s connected account, the platform billing end customers, and the platform billing the sellers themselves, as its Connect subscriptions documentation describes. The same Stripe documentation notes that a platform cannot update or cancel a subscription it did not create, and that subscriptions must be cancelled after a connected account disconnects. So if subscriptions were created on the seller’s account, a departing seller’s subscribers cannot simply be handed to another seller, and you may not be able to stop their renewals yourself.
The decision is what you promise subscribers when a seller goes. You can cancel their subscriptions and tell them, or move them to another seller offering a similar product, which usually means asking them to subscribe again. Both need a notice to buyers, a final payout to the seller, a check for refunds or credits still owed, and closing entries in the accounts.
The decisions side by side
| Decision | Option A | Option B | What has to agree in the books |
|---|---|---|---|
| Model | Sellers pay the marketplace a plan | Buyers subscribe to sellers | Plan income and commission income recorded separately if you run both |
| Ownership | Marketplace holds the subscription | Seller holds the subscription | Who issued each charge matches who issues each invoice |
| Multi-seller cart | One subscription per seller | One combined charge split on renewal | Each seller’s share per cycle matches their payout |
| Failed renewal | Seller ships while payment is retried | Seller waits for a successful payment | Order status, payment status and payout status move together |
| Mid-cycle cancel | Run to end of period | Refund the unused part | Refunds, credit notes and recovered payouts match |
| Commission on renewals | Rate fixed at sign-up | Current rate on each renewal | Each payout records the rate it used |
| Price change | Keep the sign-up price | Charge today’s price after notice | Order line price, unit and tax match the invoice |
| Source of record | Payment provider leads | Marketplace leads | Every charge has an order and an invoice, checked daily |
| Seller leaves | Cancel and notify subscribers | Move subscribers to another seller | Final payout, open refunds and closing entries settled |
Off-the-shelf platform or a custom build
An off-the-shelf subscription marketplace platform for subscription services usually makes several of these decisions for you. It will typically have a fixed answer on who owns the subscription, a set retry schedule for failed payments, one way of handling a mid-cycle cancel, and a standard export for accounting. The trade-off is that changing a default later can be difficult or impossible, and the accounting export may need manual work each month to fit what your accounting system expects.
A custom build lets you set each decision yourself: which snapshot a renewal copies, when an order is created, how a refund is split, how each renewal reaches your accounting system with the fields it needs. The trade-off is that you have to make every one of those decisions explicitly, it takes longer before launch, and someone has to run and change the system as your rules change. The wider comparison is set out in our article on custom vs SaaS marketplace builds. Neither route is right for every subscription marketplace. The useful step is to go through the table above and mark which decisions you are happy to accept as a default and which ones your business depends on.
If you are weighing this for your own business, start with a plan. In two to three weeks we map how the system would connect to your ERP, warehouse, payments and sales channels, set out the build in phases with the cost to run it over three years, and give a fixed quote for the first phase. You keep the plan whatever you decide.