How it works
How does subscription splitting work?
Subscription splitting on NeverSub starts with a verified community, then moves through groups, rooms, payment into escrow, and release after the cycle runs. The point is to make the agreement, access, and money trail visible before anyone joins.
A room can be opened by someone who already pays for a plan or by someone looking for a seat. Either way, members see what is being shared, how many seats exist, what the billing cycle is, and what happens to their payment before they commit.
Why does it start with a community?
It starts with a community because sharing works better when the circle has a real boundary. A college, company, or housing society gives each room a context beyond a public listing.
NeverSub is not built around an open feed of strangers. A community is the first container: a college verified by its email domain, a company verified by work email, or a housing society entered through an invite. That boundary gives the room context before money or access is involved.
Communities can support different join policies. Some can be open, some can require an email domain, some can be invite-led, and some can use a request flow. The policy is part of the product model rather than a note in chat, so a room can inherit a clearer sense of who is nearby and why they belong there.
What is a group inside a community?
A group is a smaller circle for people who want the same kind of sharing. It keeps rooms relevant without forcing everyone in a large community into one place.
A college might have hostel groups, batch groups, course groups, or friend circles. A company might have team groups or office-location groups. A society might have towers, blocks, or hobby circles. Groups are user-created and can be request-to-join, which keeps them flexible without turning the whole community into a private club.
The group layer matters because most subscriptions are not useful to every person in a community. A room makes more sense when it appears beside people who care about that category and know the context.
What happens in a room?
A room is the actual agreement: what is being shared, how many seats exist, which billing cycle applies, and what each member is expected to do. It is where discovery turns into a payment-backed commitment.
Rooms can be offers, requests, or exchanges. They can have a fixed share, a price range with bids, or exchange terms agreed by the people involved. The host describes the access method, seats, renewal date, and limits members need before paying.
Members do not have to reconstruct the deal from chat messages. The room record keeps the important pieces together: asset, seats, cycle, terms, membership state, and the payment state that decides who can see access details. Chat can support questions, but the room is the source of truth.
Where does the money go?
Members pay their share into escrow, and the money stays held for the whole billing cycle. It is not a quick transfer to the host as soon as someone joins.
Cycle-long escrow is the core difference. The host should not have to chase people one by one, but members also should not lose leverage the moment they pay. Holding funds through the cycle gives NeverSub a payment trail and a practical way to handle obvious failures before funds move to the host wallet.
After payment, a short confirm-or-refund window can catch cases where access does not work or the room is materially different from what was described. Confirmation does not release the host funds early. It only closes that early failure window while the escrow continues until the cycle end.
When is the host paid?
The host is paid after the billing cycle has run, subject to refunds or other checks. Released funds become wallet balance that the host can withdraw on demand.
At cycle end, escrow can be released into the host wallet. If a room ended early, access failed, or a refund path was triggered, the payment record reflects that instead of pretending the room ran normally. The product is designed around state transitions, not informal promises.
That is the whole loop: community, group, room, escrow, release. The mechanism is intentionally plain because the hard problem is not adding more math. It is giving both sides a shared record that can travel with them as they keep using their community.