
- Home
- Services
- E-commerce and Marketplaces
- Marketplaces, subscriptions and memberships
Part of E-commerce and Marketplaces
Marketplaces, subscriptions,and memberships.
A marketplace, a subscription and a membership are models where the platform is the product: money and identity are continuous rather than one time. It is one of two services under E-commerce and Marketplaces.
Billing that survives edge cases, both sides handled properly, and churn visible from launch day.
Know what you are building? Book a discovery call. Not sure where the problem is? Request the audit.
HUREAL / Material studies
In your words
Soundslike this?
We are moving from one time sales to a plan, and nobody owns what happens when a card fails.
Members email us to cancel, because there is no way to do it themselves.
We built one side of the marketplace and the other side is a spreadsheet.
Renewals are a calendar reminder and a person.
Our membership tool cannot express our pricing tiers, so the exceptions are handled by hand.
We cannot say what a member is worth over three years.
Payouts to our providers are assembled manually at month end.
If what you sell is a product somebody buys once, the store is the project and the page for it is E-commerce platforms.
In plain language
Money and identityare continuous.
These are not stores with extra features. A marketplace has two customers who need different things and have to be brought together. A subscription business earns its revenue in the eleventh month rather than the first. A membership organization is judged on whether a member can do the thing they joined for without emailing anyone.
A store ends at the order. A platform starts there.
Accounts, entitlements, renewals, failed payments, upgrades, downgrades and payouts are the real work, and they are where these projects succeed or quietly fail. None of them is visible in a demonstration. All of them are visible in the eleventh month.
Failed payment recovery is usually the largest single revenue lever in a subscription, which is why it is designed with you rather than left at a default: how many retries, on what schedule, what the member sees, when access pauses, and how it is restored.
When an off the shelf tool is the right answer. Where a membership or subscription product matches your model, it is the better buy and we will say so. These tools work well when entitlements and pricing look like everybody else's. They get expensive and awkward at the point where your tiers, your payouts or your access rules are specific to your business, and that is the point at which building is the cheaper of the two over three years.
The capability table
What a platformbuild includes.
Fourteen capabilities, what each one does in plain words, and what it changes for the business. The money group is the longest because it is where these projects are actually decided.
| Capability | What it does | What it changes |
|---|---|---|
| The modelBefore anything is built | ||
| Model design | Who the sides are, what each needs, what the platform charges for, and when money changes hands. | The commercial question is settled before it becomes a code question. |
| The account system | Identity, entitlements, and every state a member can be in. | What a lapsed member can still see is a decision rather than an accident. |
| Onboarding and verification | The checks your business requires before a provider or a member is live. | The wrong side of a marketplace does not get in by default. |
| The moneyWhere these projects fail quietly | ||
| Recurring billing | Plans, trials, proration, upgrades, downgrades and cancellations. | A price change is a configuration rather than a migration. |
| Dunning and failed payment recovery | Retries, the schedule, what the member sees, when access pauses, and how it is restored. | The largest single revenue lever is designed rather than defaulted. |
| Entitlements | Who can see what, and what happens the day a subscription lapses. | Access is true on the day it matters. |
| Payouts, commissions and statements | What each provider is owed, in a statement your finance team can reconcile. | Month end stops being assembled by hand. |
| Tax handling | On subscriptions and on marketplace transactions, by province. | The accounting does not have to be corrected afterwards. |
| The experienceTwo or three products that have to feel like one | ||
| Listings, availability, matching and search | The core of a two sided platform. | The two sides actually find each other. |
| Member and provider self service | Profile, billing, invoices, history and cancellation. | Routine account work stays off your team. |
| Member only content, cohorts and progress | Where the model calls for them. | The thing they joined for is the thing they can reach. |
| Notifications tied to real account events | Renewal, failure, upgrade, lapse and restoration. | A member is never surprised by their own account. |
| Admin tools | So your operations people can intervene without a developer. | An exception is handled in minutes rather than in a ticket. |
| Recurring revenue reporting | Monthly revenue, churn, cohort retention and lifetime value, from launch day. | The model can be judged early enough to change it. |
Scroll the table sideways to read it.
How it works
The same board,read every month.
The parent's drawing, read as a recurring model. What the catalogue holds is plans and terms rather than stock. What checkout does happens again next month. And what fulfilment and returns mean here is access granted and access removed.
Scroll the drawing sideways to read it.
The same board, read every month. Fulfilment is access granted. A return is a lapse.
The work, the path it takes, and everything HUREAL builds. It never means anything else.
The line, its single opening, and the plate standing in it. On a light board it is the one dark plate.
Present, named, and not for sale. The lowest contrast on the board, deliberately.
-
One place knows the plan.
Plans, prices, trial terms and what each tier is entitled to live in one place, the way a catalogue holds cost and stock. Every screen a member sees reads from there, which is why a price change is a configuration rather than a migration.
-
Anyone, and their account.
A visitor sees the public offer. A signed in member sees their plan, their invoices, their history and the cancel button. On a marketplace the same split is the two sides, and each side is a product in its own right.
-
Checkout happens again next month.
The first payment is the easy one. The design work is the second year: proration on an upgrade, a card that expires, a retry schedule, the moment access pauses, and the path back. All of it decided with you rather than left at a default.
-
Access is granted, and access is removed.
Entitlement is the equivalent of fulfilment here, and a lapse is the equivalent of a return. What a lapsed member can still see is a decision somebody should make on purpose, and it is the one most often made by accident.
-
The credit stops at the line.
Refunds, waived terms and exceptions wait for a person, because they are commercial decisions. What renewed and what churned goes back to the plan structure, which is how a model gets judged early enough to change it.
Cohort and churn reporting from launch day is not a later phase. A subscription business that cannot see its eleventh month cannot fix it, and the first cohort is the cheapest one to learn from.
Read the methodThe deliverables
What youend up with.
- A platform with both sides handled
Rather than one side with a form for the other.
- Billing that survives edge cases
Which is most of what billing actually is.
- A dunning design
Retries, messages, the pause and the path back, written down rather than defaulted.
- Entitlements you can read
Who can see what, and what happens the day a subscription lapses.
- Self service for members and providers
Profile, billing, invoices, history and cancellation.
- Payouts and statements
What each provider is owed, in a form your finance team can reconcile.
- Admin tools your operations people control
So an exception is handled without a developer.
- Recurring revenue reporting from launch day
Monthly revenue, churn, cohort retention and lifetime value.
What is not on this list. The one time storefront. Catalogue, merchandising, shipping and returns on a product somebody buys once are on E-commerce platforms, and plenty of businesses need both. The lifecycle messaging and retention work that follow launch are Care and Optimization.
By category
What a platformconnects to.
By category, because the category is the question. On a recurring model the connections are mostly about money being true in two places at once.
Subscription and billing engines
Where plans, proration and retries are actually executed.
Stripe Billing, Recurly, Chargebee, a platform's own billingPayments
Where the money moves, and where a failed card is retried.
card, Interac, digital wallets, your acquirerAccounting
Where recurring revenue has to reconcile.
QuickBooks, Sage, Xero, NetSuiteCRM
Where a member is also a relationship rather than only a subscription.
Salesforce, HubSpot, Zoho, DynamicsIdentity and access
Where sign in, roles and entitlements are enforced.
your own account system, single sign on providersEmail and lifecycle messaging
Where renewal, failure and lapse notices are sent.
Klaviyo, Mailchimp, Customer.ioAssociation and member systems
Where dues, chapters and member records already live.
an association management system, an in house registerAnalytics
Where churn and cohorts are measured rather than estimated.
your own reporting, a product analytics tool
Every connection is validated by HUREAL's engineers during scoping and confirmed in writing before signature. Where a system genuinely cannot be connected, you hear it during discovery rather than during the build, and the scope is drawn around it instead of making a platform migration the price of entry.
Asked and answered
Questions peopleactually ask.
-
Should we start with one side of the marketplace?
Usually yes. Most two sided platforms are built by making one side work with a manually assembled other side, then automating the second once demand is real. We help you decide which side is the hard one, because that is the side to build for.
-
Can we use an off the shelf membership tool?
Sometimes, and we will say so if that is the answer. These tools work well when your model matches theirs. They get expensive and awkward when entitlements, pricing tiers or payouts are specific to your business, and that is the point at which building is cheaper over three years.
-
What happens when a payment fails?
That is a design decision, not an accident, and we design it with you: how many retries, on what schedule, what the member sees, when access pauses, and how it is restored. Recovering failed payments is often worth more than acquiring new members.
-
Can members cancel themselves?
Yes, and it is a design requirement rather than a setting. A cancel path that works is also where you learn why people leave, and a cancellation that requires an email is a support queue and a bad review at the same time.
-
How do payouts work?
Providers are paid against a statement your finance team can reconcile: what was sold, what commission applied, what was refunded, and what is owed. The schedule and the thresholds are yours, and the rules sit in the build rather than in a spreadsheet at month end.
-
Can we see churn from the first month?
Yes, and that is the point of building the reporting into the launch rather than after it. Monthly revenue, churn, cohort retention and lifetime value are available from the first cohort, which is the only time the model is still cheap to change.
-
What does it cost?
The build price is set after the discovery call and sent in a written proposal, because an honest number needs the scope, and here the scope is mostly the account states and the money rules. The number is written into the signed scope and does not move once it is signed.
Three pages next to this one
Where thissits.
-
E-commerce and Marketplaces
The whole of it. A recurring model is one of two things under this pillar, and the pillar page is where the choice between them gets made rather than assumed.
E-commerce and Marketplaces -
E-commerce platforms
Most recurring businesses still sell something once. The catalogue, the checkout and the shipping rules for that half are a store build, and the two are scoped together.
E-commerce platforms -
Web Applications and Portals
Self service is most of what a member actually experiences. The account, the permissions and the screens a person works in are the same craft as a portal, which is why the two pillars keep meeting.
Web Applications and Portals
Close
Two ways to start.Both end with a document you own.
Book a discovery call
For when you know what has to change and want the scope before the spend. A discovery call with the people who own the outcome. We go through margin, repeat rate, average order, returns and the systems involved, and afterwards you get a written proposal with a scope, a price and a timeline you can sign or walk away from.
Book a discovery callRequest a performance audit
For when you want the evidence before the decision. We look at what you have against the job you want it to do, and give you a prioritised plan with the arithmetic attached. The document is yours either way.
Request a performance auditKnow what you are building? Book a discovery call. Not sure where the problem is? Request the audit. If neither is right for you, we will say so, and tell you what is.
Not ready for either? Talk to the demonstration in your browser for three minutes, or paste your own address and hear it answer as your business. No form and no booking, and the transcript arrives by email a minute later.
Hear it work
Models where the platform is the product.
HUREAL / Material studies