Apple grants the refund. On Google Play you grant it, and you own the policy.
Apple issues every App Store refund and decides it without asking you. On Google Play you issue refunds yourself, from Order management in Play Console or through the Google Play Developer API, and Google issues some of its own on top. That one difference sets everything else about handling them. On iOS you build a listener and a twelve hour reply. On Android you build a tool your support person can use, and you write the refund policy it follows, because Google says the policy is yours. Every field name, window and figure below comes from Apple's and Google's own developer documentation, read on 21 October 2026. The price the customer paid, and therefore the amount at stake, came from your app store pricing tiers.
What follows is the handling runbook. Who grants one, the single thing Apple lets you do about a request and the consent duty attached to it, the three documented ways to refund on Google Play, and the question both stores answer the same way: who switches the customer's access off.
Start hereThe short version
One store asks you for evidence. The other hands you the button.
Refund handling on iOS is a server job with a deadline. The App Store tells your server a customer has asked for a refund, you have twelve hours to send what you know about how much of the purchase they used, and Apple decides. Refund handling on Android is an operations job with a policy behind it. You can refund in full, in part, or prorated, from a console screen or from an API, and nobody is going to stop you.
The part that is identical on both stores is the part teams forget. A refund moves money. It does not reach into your database. Unless you use Google's one documented refund and revoke path, the customer still has everything they paid for until your own code takes it away.
Who issues a refund on each store?
On the App Store, Apple. The customer asks Apple, Apple weighs it, Apple pays it. Apple's own sentence, on the Send Consumption Information page read on 21 October 2026, is that the App Store uses a variety of factors to determine if a refund request is approved or denied. The full endpoint list for the App Store Server API, read the same day, carries that out: there is no endpoint anywhere in it that grants a refund or blocks one. Refunds show up twice, and neither is a button. Get Refund History sits under a heading called Refund lookup and reports what Apple already refunded. Send Consumption Information sits under Consumption information and lets you send evidence before the decision is made.
Your app can still start the request. Apple's page points at the StoreKit beginRefundRequest methods for initiating refund requests in an app, so a Request a refund row in your own settings screen is a supported thing to build. What it does is hand the case to Apple sooner. The outcome is Apple's either way, and the contract that lets Apple sell and collect on your behalf is the app store paid apps agreement.
On Google Play there are two people who can refund your customer, and one of them is you. Play Console Help, on a page titled Manage your app's orders and issue refunds, says you can view orders, issue refunds and manage subscription cancellations from the Play Console website or app. The same page has a section headed Why was an order refunded, for refunds you do not recognise. Google issues those as a courtesy to users or as required by law, and includes them as part of its Developer Distribution Agreement. It gives one customer window outright: after buying a paid app, a user has up to two hours to return it for a full refund, and can only return a given app once.
The sentence on that page worth reading twice is about the policy rather than the money. Google states that you are responsible for setting your own refund policies, that buyers may contact you directly with questions, and that you must issue refunds in accordance with your policy. Telling users when the policy changes and keeping it lawful are also listed as yours. Apple publishes no equivalent instruction on the pages read here, which follows from Apple being the one who decides. So on Android you need a written policy before you need a tool.
Apple, Send Consumption Information, App Store Server API, read 21 October 2026
What can you actually do about an App Store refund?
One thing, and it happens before the decision. When a customer requests a refund for any product type, which Apple spells out as consumable, non-consumable, non-renewing subscription or auto-renewable subscription, the App Store sends a CONSUMPTION_REQUEST notification to your App Store Server Notifications V2 endpoint. You answer it by calling Send Consumption Information with what you know about how much of the purchase the customer used. Apple says it uses the consumption information you provide to inform its refund decisions. That is the whole of your influence, and it is worded as influence rather than as a veto.
Two conditions decide whether you can use it at all. The first is the clock. Apple's instruction, as of 21 October 2026, is to respond within 12 hours of receiving the CONSUMPTION_REQUEST notification. The second is consent. If the customer provided consent, you respond. If not, Apple tells you not to respond to the notification at all. The endpoint is marked available from App Store Server API 1.19.0, and an older variant called Send Consumption Information V1 is documented for consumable purchases and auto-renewable subscriptions only, so the newer one is the one that covers all four product types.
The consent rules are the part most teams have not read, and Apple is blunt about whose problem they are. You, the developer, are solely responsible for obtaining valid consent, because you are sharing data you collected from the customer. Apple describes valid consent as freely given, specific, informed and unambiguous. It says opt-in is a higher standard than offering an opt-out, and that without an opt-out it can be difficult to show consent was freely given. If circumstances change or the customer withdraws consent, you update the customerConsented flag and send no further data for that person. And there is one explicit warning: do not use the App Tracking Transparency prompt to collect this consent. Apple says the two features are distinct and unrelated, and that data shared through this endpoint is not used for tracking.
Adopting the endpoint also adds two smaller duties. You answer the app privacy questions so your labels disclose the data you collect and what you use it for. And if a customer asks to see or delete the consumption data, Apple's instruction is to tell them to submit the request directly to Apple at privacy.apple.com. None of this is hard. It is just more than a webhook, and it is easier to put in place while you are building the paywall than during the week your refund rate first looks wrong.
Pick the situation
What you can actually do, per store
Tick what has happened. Every answer below is the action each store documents for that case, with the store's own names for it.
Nothing ticked. If your app takes no money through either store, neither column applies to you yet.
What does Google document about a developer initiated refund?
Three ways in, all current. The Play Billing page titled Manage subscriptions and one-time purchases carries its own last updated date of 15 October 2026 and was read on 21 October 2026. It opens by saying your customer service may need to issue total or partial refunds, or revoke entitlements, and that you can do this from Play Console or from your own system through the Google Play Developer API. The console path is Order management, where you search by order ID or by a user's full email address. The first API is orders.refund, which issues full refunds for any order within three years of purchase and takes a revoke parameter. The second is purchases.subscriptionsv2.revoke, for subscriptions.
Partial refunds are a console feature with real limits, and Play Console Help states them. You cannot issue partial refunds for paid apps. Partial refunds are only supported for orders placed after March 2018. The percentage you refund applies to your payout and to Google's service fee in the same proportion, so a 50 percent refund returns half of each. You can issue several partial refunds against one order, as long as they do not reach the order total.
Prorated amounts live in the API rather than the console. purchases.subscriptionsv2.revoke takes a revocationContext, and you set either fullRefund for the whole current billing period or proratedRefund for the unused part of it. Google's own worked example has a customer cancelling on day 15 of a 30 day plan and getting about 50 percent back with access ending immediately. Prorated refunds are supported for auto-renewing subscriptions and for prepaid plans with a duration of at least one week. This method replaces the legacy purchases.subscription.revoke, which could only do full refunds, and Google notes that a user refund is based on the value of the latest order.
Two sentences to read before anybody on your team gets access to the button. After you issue a refund, it cannot be reversed. And if a refund takes your account balance negative and it stays negative for at least 48 hours, Google collects the money by debiting the bank account that normally receives your payouts. Access is split across two Play Console permissions, Manage orders and View financial data, so the person who can refund and the person who can see the financial reports do not have to be the same person.
Who takes the customer's access away?
You do, on both stores, with one documented exception. A refund is a money event. The unlocked level, the removed watermark and the row in your database that says this account is premium all survive it untouched unless something in your own code reacts. This is the most common gap in a first paywall, and it is invisible until somebody works out that refunding is a free way to keep the feature.
The exception is Google's refund and revoke. orders.refund takes a revoke parameter which Google describes as indicating whether access should be revoked in addition to providing the refund. Set it on a subscription purchase and the subscription is terminated immediately. That fires a SUBSCRIPTION_REVOKED real time developer notification and a VoidedPurchaseNotification, and the second of those is recorded in the Voided Purchases API. Two conditions come with it. Access can only be revoked for a subscription that has current entitlement, and the revoke parameter has to be used on the latest order of that subscription. Use it on an older order and Google says the refund will succeed but the subscription will not be revoked. For an active subscription, Google points you at purchases.subscriptionsv2.revoke with the purchase ID instead.
Cancelling is a different button with a different outcome, and mixing the two up is how a support conversation goes wrong. The purchases.subscriptions.cancel API issues no refund, and the user keeps access until the end of the current billing period. The cancellationType parameter then decides what they can do next. USER_REQUESTED_STOP_RENEWALS behaves as if they had cancelled in the Play Store, so they can restore the subscription before it expires or resubscribe afterwards if the base plan allows it. DEVELOPER_REQUESTED_STOP_PAYMENTS prevents any further payments and stops them restoring from the Play Store, although you can still offer a fresh signup inside your app. Leave the parameter out and DEVELOPER_REQUESTED_STOP_PAYMENTS is what you get.
Apple gives you neither a cancel nor a revoke. The closest lever in the App Store Server API endpoint list is the subscription renewal date extension, which is there to compensate active subscribers for service interruptions rather than to undo anything. So on iOS every revocation is your code: read the notification, find the entitlement, switch it off, write a line in a log. One purchase can also serve more than one person, which is worth settling before you write the rule, so read how family sharing for subscriptions changes who holds the entitlement.
Google, Issue refunds and revocations, Play Billing, last updated 15 October 2026
The same refund, two different jobs
| What you are asking | App Store | Google Play | Same on both |
|---|---|---|---|
| Who can grant a refund | Apple, from the customer's own request | You, and Google itself | No |
| An API call that issues one | No | Yes | No |
| A window for you to send evidence first | 12 hours, and only with the customer's consent | Not on the two pages read here | No |
| Partial or prorated amounts | Not available to you | In-app purchases and subscriptions, never paid apps | No |
| How far back an order can be refunded | Apple's call, not yours | Three years of purchase, by order ID | No |
| A refund you issued can be undone | You cannot issue one | No | No |
| Cancelling also refunds | No developer cancel endpoint exists | No | No |
| Taking access away is your code | Yes | Yes, apart from refund and revoke | Yes |
Where this lands if a builder generated your app
Refund handling is server work and account work, so the question to ask about any builder is whether you end up holding both. Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two way GitHub sync, so the code is always somewhere you can reach. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month and there is no free tier.
Two consequences for refunds follow from the accounts being yours. The CONSUMPTION_REQUEST notifications arrive at your Apple account, and Order management is your Play Console screen, so no vendor sits between you and a customer asking for money back. And Newly does not submit to the App Store on your behalf, because Apple requires the owner of an app's content to submit it, which means your name is on the listing from the first release. Working out the developer account fees around all of this is a separate exercise, covered in what it really cost to publish an app.
The honest limit: generating an app does not hand you a refund policy, a consent flow or a revocation rule. A verified notification endpoint, a record of what each customer consumed, a written policy for your Android support person and one rule about when access switches off are four small jobs you have to ask for. They are far cheaper on the day you build the paywall than on the day you first read a refund report.
Questions people ask about handling refunds on iOS and Android
Apple issues every App Store refund and decides it on its own. Apple's documentation for the Send Consumption Information endpoint, read on 21 October 2026, says the App Store uses a variety of factors to determine if a refund request is approved or denied. There is no step in that sentence for the developer. On Google Play there are two sources. You issue refunds from Order management in Play Console or through the Google Play Developer API, and Google also issues refunds itself, which Play Console Help describes as a courtesy to users or as required by law and includes as part of the Developer Distribution Agreement.
Decide who loses access, before anyone asks for money back
Write the rule down in one sentence, then ask for the notification endpoint that enforces it. A refund becomes a row in a log instead of a support thread nobody knows how to close.
Start building