Subscription cancellation reasons usually reach you before the refund request does, and Google Play hands over far more of them than Apple

Most subscribers who end up refunded cancel first. That cancellation carries a reason, and the two stores hand you very different amounts of it. Google Play runs a short survey and passes the answer to your server, free text included. Apple sends a numeric code that says how the subscription ended, not why the customer wanted out. Read both properly and you'll see refund requests coming while there's still something you can do about them.

What Google Play tells you about subscription cancellation reasons

When a user cancels in the Play subscriptions center, Google asks them why. The answer lands in the subscription resource you get from purchases.subscriptionsv2.get, under canceledStateContext. That object only exists while the subscription is in the canceled or expired state, and it says who ended the subscription: the user, Google's system, you, or a replacement such as a plan change.

When the user did it, the userInitiatedCancellation object holds two fields. cancelTime says when they canceled. cancelSurveyResult holds the survey answer.

The right-hand column is our reading, not Google's. The first two columns come straight from the API reference.

The notification doesn't carry the reason

A canceled subscription triggers a SUBSCRIPTION_CANCELED real-time developer notification, type 3. Google is explicit that these notifications only say the purchase state changed. The payload gives you a purchase token and nothing else useful, so your handler has to call purchases.subscriptionsv2.get to read the survey answer.

The Play Console view

You don't need code to see the totals. Play Console's subscription reports include a Cancellations card that splits churn into voluntary, involuntary and other, and a Cancellation survey responses card for users who chose to answer. Free-text answers from users who picked other can be downloaded as a CSV from the Other responses card. That download needs the View financial data permission, the same one you'd grant a tool that reads your orders.

What Apple tells you, and what it leaves out

Apple runs no cancellation survey that reports back to developers. The closest field is expirationIntent in the signed renewal info, and it describes how a subscription ended, not what the customer thought.

Code 1 is the only one that describes a choice the customer made, and it says nothing about the motive. A customer who left because the app kept crashing and one who simply finished a project look identical.

The signal hiding in AUTO_RENEW_DISABLED

There's one Apple notification worth a closer look. DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED usually means the customer turned off auto-renewal. Apple's documentation adds a second case: the App Store also turns auto-renewal off after the customer requests a refund.

So on iOS, a renewal-off event can be the first trace of a refund request. If the purchase is a consumable or an auto-renewable subscription, a CONSUMPTION_REQUEST may follow, and from that point you have 12 hours to send consumption data. A renewal-off event that arrives with no visible action in your app is worth treating as a heads-up to get that account's usage data ready.

Apple and Google side by side

Where a cancellation turns into a refund

A cancellation stops the next charge. It doesn't return the last one. Whether money goes back depends on which refund flow the customer reaches next, and most of those flows run without you.

• On Google Play, a buyer can get a refund within 48 hours of purchase on their own, and Google decides it.
• Refunds through Google's or Apple's support are decided by the store.
• Apple's CONSUMPTION_REQUEST asks for your consumption data, with a 12-hour window.
• Google Play's chargeback review asks for evidence through orders.reviewrefund, with a 24-hour window. The bank's decision on a chargeback is final.

A cancellation reason doesn't change any of those rules. What it changes is how early you know which customer is unhappy, and whether your evidence is ready when one of the two flows that ask for it arrives.

What each reason costs you

The survey answer is also a rough guide to what an account has already cost to serve, which is the money a refund leaves you holding.

Technical issues

This is the expensive one. The customer used the product enough to hit problems, so you've paid for the compute behind their sessions, the model API calls their requests made, the storage for whatever they created, and any payout owed to a creator whose content they used. If they then get a refund, the price goes back and those costs stay with you. If they go to their bank on Google Play, an order placed after August 3, 2026 costs you the purchase price less Play's service fee, plus the bank's fees.

Cost related

A price complaint costs you less than it looks, unless it hides an unexpected renewal. That's the classic chargeback story, so check whether the cancel came right after a renewal charge and whether your renewal reminders went out.

Not enough usage

Low usage means low serving costs, so a refund here mostly returns money you didn't spend much to earn. It's also the reason where honest consumption data, if Apple asks for it, shows exactly what the customer did and didn't use.

Found a better app

These customers rarely dispute anything. They left for a competitor. The reason is useful for product decisions and almost never for refund defense.

A routine for reading cancellation reasons

• On every Google Play SUBSCRIPTION_CANCELED, call purchases.subscriptionsv2.get and save canceledStateContext with the purchase token and cancelTime.
• Save reasonUserInput verbatim when the reason is other. It's the only free text either store gives you.
• On every Apple DID_CHANGE_RENEWAL_STATUS with AUTO_RENEW_DISABLED, log the event and pull that account's usage, in case a CONSUMPTION_REQUEST follows.
• On every Apple EXPIRED notification, record the subtype and expirationIntent so voluntary churn and billing failures don't blur together.
• For Google Play cancels citing technical issues, check your error logs for that account and reach out before the customer reaches their bank.
• Keep per-account usage logs, so a CONSUMPTION_REQUEST gets an answer inside 12 hours and a chargeback review inside 24.