Every in-app purchase type refunds differently, and only two of them ever ask for your side

The in-app purchase type you chose in App Store Connect or the Play Console decides more than how the product is sold. It decides how a refund behaves when one lands, whether the customer can get the item back for free afterward, and whether you are ever asked for your side before the money moves. A coin pack, a lifetime unlock, a monthly subscription, and a one-off season pass are four different legal and technical objects, and the refund rules treat them that way. Most developers ship all of them through the same purchase code and then wonder why refunds feel inconsistent. They are not inconsistent. They are type-specific.

Here is what each in-app purchase type is, how a refund hits it, and why only two of the four ever route the decision through your server.

The four in-app purchase types, and why refunds split along them

Apple defines four product types. A consumable is used up and bought again: game currency, hints, an energy refill. A non-consumable is bought once and kept forever: a pro unlock, a removed-ads upgrade, a downloadable level pack. An auto-renewable subscription bills on a repeating cycle until the customer cancels. A non-renewing subscription grants access for a fixed span that does not renew on its own, like a season of content sold as a single term.

Google Play sorts the same catalog differently but lands in the same place. It splits products into one-time products and subscriptions, and a one-time product is flagged as consumable or not by whether your app consumes it after purchase. The words differ. The refund consequences do not.

Consumables are the type refund fraud actually targets

A consumable is the hardest refund case you will face, and it is no accident that it is the one Apple built the consumption request around. The moment a customer buys 10,000 coins and your server grants them, the value is delivered. If they spend those coins and then file for a refund, the store can return their money, but the coins are gone and so is whatever it cost you to honor them. Apple's own tooling reflects this: a consumable leaves the transaction record once completed and never carries a cancellation date, because there is nothing persistent to cancel.

That is why the consumable is the product type where evidence pays. When a customer requests a refund on a consumable, Apple sends your server a CONSUMPTION_REQUEST and waits up to 12 hours for a Send Consumption Information call. In that call you set a deliveryStatus and, when you delivered, a consumptionPercentage. The percentage is an integer in milliunits from 0 to 100,000, where 100,000 means the customer used the entire purchase. A coin balance your records show fully spent is an 100,000 you can report, and it is the strongest single fact you can put in front of an unintended-purchase claim.

Consumables cannot be restored, so timing is everything

Because a consumable cannot be restored, you cannot claw it back the way you can revoke a subscription. Once a refund is granted, your only protection is the record you kept at the time of sale. If you did not log delivery and consumption when it happened, you are reconstructing it under a 12-hour clock, which is the worst moment to go looking for data. Record it on the way in, not on the way out.

Subscriptions refund on a clock you do not control

Auto-renewable subscriptions are where most apps make their money, and the WWDC24 refund update finally routed them through the same evidence window as consumables. Since App Store Server Notifications version 2.11, a refund request on an auto-renewable subscription also fires a CONSUMPTION_REQUEST. So the subscription refunds that used to be decided entirely without you now arrive with a 12-hour window attached.

The catch is how consumption is measured. For an auto-renewable subscription, Apple does not want you to invent a usage percentage. It computes consumption from elapsed time on its own, so someone six months into an annual plan reads as roughly half consumed no matter what you send. Your lever is not the percentage. It is an honest refundPreference of GRANT_FULL, GRANT_PRORATED, or DECLINE, backed by whatever usage signal you actually hold. Send the preference the evidence supports and let Apple weigh it.

Non-renewing subscriptions sit closer to a one-time unlock

A non-renewing subscription is a fixed term the customer buys once, and it behaves more like a non-consumable than like an auto-renewable plan for refund purposes. Apple rarely routes a CONSUMPTION_REQUEST to it, and there is no automatic renewal to prorate against. Your app is responsible for tracking the term and restoring it across the customer's devices, so a refund means ending an access window you were managing yourself, not one Apple was clocking for you.

Non-consumables are permanent, which cuts both ways

A non-consumable is the cleanest thing to sell and a quiet trap on refund. It is bought once, it is tied to the customer's store account forever, and the store can restore it to any device on demand. That permanence is a feature until a refund arrives, because now you have to revoke an entitlement the account still remembers. If your revoke logic only checks at purchase time and never re-verifies, a refunded customer can restore purchases and walk right back into the paid feature.

Google Play adds one hard edge here that catches new developers. If your app does not acknowledge a purchase within 72 hours, Google automatically refunds it and revokes the entitlement. A non-consumable that your billing code forgot to acknowledge does not sit in limbo. It reverses itself, and the customer loses access to something they paid for, through no request of their own.

Who can even issue the refund changes by store and type

Before you plan any refund response, know who holds the pen. On the App Store, only Apple can issue an in-app purchase refund, for every product type. Your StoreKit code cannot refund a purchase, and neither can your support desk. You can send consumption data to influence Apple's decision on the two types that open a window, and that is the whole of your direct control.

Google Play is the opposite. You can refund a one-time product or a subscription order yourself from the Play Console or the Voided Purchases and refund APIs, in full or in part. That freedom is also a responsibility: a refund you issue on a consumable still has to revoke the item in your own backend, because Google does not know your coins are spent. The product type you picked decides how clean that revoke is.

What each refund type actually costs you

The refunded price is the line everyone watches and the smallest part of the bill. When any store grants a refund, it reverses its own commission along with it, so you lose your net proceeds rather than the full sticker price. That is the good news, and it stops there. What the store returns is the cut it took. What it never returns is what you already spent to fulfill the sale, and that number changes sharply by product type.

The consumable is the expensive refund

A refunded consumable is the one that can cost more than its price. Say a customer buys 5,000 credits that each trigger a paid inference call, spends 4,000 of them, then files for a refund. The store hands back the price and its commission, but the compute, the per-token API bill, the images you generated, and any creator payout those credits funded are all spent. A non-consumable refund at least pulls an entitlement back into your control. A consumable refund pulls back a sale whose entire cost you already paid.

A chargeback is the heavier version of the same bill

A refund and a chargeback are different events, and the gap now has a date on it. When a customer disputes the charge with their bank instead of asking the store, a completed chargeback is bank-final. For Google Play orders placed on or after August 3, 2026, a lost chargeback bills the developer the purchase price less Play's service fee, plus the bank's chargeback fee, a flat charge the card network sets. Google Play routes a chargeback to you for review through orders.reviewrefund with a 24-hour window, the only Google flow that asks for your evidence, and it can land on any product type.

How to respond when the type decides the rules

You cannot change which product type a refund lands on after the sale, but you can stop handling all four the same way.

• Record delivery and consumption for consumables at the moment they happen. That log is your entire defense on the one type that cannot be restored, and the 12-hour window is far too short to build it from scratch.
• Re-verify entitlements for non-consumables after a refund, not only at purchase. A restore call should check current status, so a refunded customer cannot walk back into the paid feature.
• Answer both evidence windows automatically. A 12-hour consumption request and a 24-hour chargeback review cannot wait for someone to read an inbox, and they do not extend for time zones.
• Judge your refund defense on the two contestable types only. A rising count of refunds on types that never opened a window is a product or pricing signal, not a failure of your evidence.

None of this is about beating the store. It is about matching your response to the object that was actually sold. RefundHalt answers the consumable and subscription CONSUMPTION_REQUEST and the Google Play orders.reviewrefund review automatically, inside the window, with the delivery and usage evidence you recorded at the time of sale, and it keeps the refunds no window ever let you contest in their own ledger, so the number you judge yourself by stays honest.