What to Know Before Moving to Subscriptions

Moving from one off sales to subscriptions changes the business model, and it puts a different kind of load on the software than most people expect.

The expected load is collection. The real load is state. The system has to know at any moment what each person is entitled to, because if it gets that wrong it either withholds from someone who paid or serves someone who did not.

Know the store rules first

On iOS and Android, digital content and subscriptions consumed inside the app must go through the store payment system, and the store takes a commission.

Physical goods and services delivered outside the app fall outside that rule. Which side you are on is decisive during review, so we settle it before any code is written. An app on the wrong side comes back from review and the schedule slips.

A receipt is not proof

This is the most expensive mistake in subscription systems. Granting an entitlement on the strength of what the app reports.

That information comes from the device, and a device is not a trustworthy source. The transaction has to be verified against the store own servers. Does it exist, does it belong to your app, is it the product being claimed, and has it been revoked. All four get checked.

If verification cannot be completed, no entitlement should be granted. A system that opens up on failure gets exploited by the first person who finds that gap.

One purchase, one account

Without that link, the same receipt unlocks several accounts for free. It is the most common abuse we see, simple to handle in code, and awkward to retrofit.

Read the state, not the event type

Stores and payment providers send event notifications. Renewed, cancelled, payment failed.

Deciding from the type of event is error prone. The right approach is to read the current status. If a subscription in arrears still counts as active, a user who stopped paying keeps being served.

The same event can arrive twice

Providers send the same notification more than once, and the second one carries a valid signature too. That is not a fault, it is how they are designed.

The event id has to be recorded and the second arrival swallowed. Otherwise one renewal notification extends the subscription twice and nobody notices.

Refunds and cancellations

If there is no endpoint telling you the store issued a refund, you only find out the next time the user opens the app. You keep serving them in the meantime.

We recommend building that endpoint from the start. It can be added later, but the time in between is a straight loss.

Quotas and credits

Where a plan grants a limited number of something, the deduction has to happen in one operation. Checking first and deducting afterwards hands out the same credit twice when two requests land together.

This matters most where the underlying action is expensive. If every credit costs you something, a deduction open to a race shows up directly on the bill.

What happens when it ends

This gets decided at the start. Is the data deleted, frozen or left readable.

Deciding it afterwards leaves user data in limbo. Account deletion also has to live inside the app under store rules, and pointing people at a form on the web does not count.

How it reaches the accounts

With store sales the money does not come to you directly. It arrives through the store, with commission deducted, and later than you expect.

So the sale figure in the system is never the figure that lands in the bank. The reporting has to show that gap from the start, or reconciliation becomes a manual job every month.

Trials and the first period

Free trials work well and carry two traps.

The first is forgetting to close access when the trial ends. That is a silent loss and usually surfaces months later.

The second is the same person opening trial after trial. What the trial entitlement is tied to has to be decided at the start. Email, device, or payment method. All three are different degrees of strict and all three have a way around them.

Changing plans

When a user moves up or down a plan, how the difference is calculated is a decision.

Are remaining days prorated, is the difference charged immediately, does someone moving down stay on the higher plan until the period ends. Code written before those questions are answered needs manual correction on the first plan change.

Selling from both web and store

Subscriptions arriving from two sources merge onto one account, and which one wins needs a written rule.

What happens when a user subscribes both in the app and on the site? Leaving both routes open without writing that rule is the most common confusion we run into, and it comes back as support load.

What to measure

The number to watch in a subscription business is not monthly revenue. It is how many left, how many stayed, and whether new arrivals cover the ones who went.

If those three do not come out of the system, you can be standing still while believing you are growing. Recording the reason for leaving is valuable too, because a cancelling user is telling you where the product falls short.