You can refund a Google Play order yourself, and doing it before a chargeback saves you the bank fee
You can refund any Google Play order under three years old with one API call, with or without revoking access. Doing it yourself before a dispute turns into a chargeback saves you the bank fee that lands on developers from August 3, 2026. Here is how orders.refund works.

Key takeaways
- The `orders.refund` endpoint in the Google Play Developer API lets a developer refund any one-time purchase or subscription order directly, with no review, no reason required, and no customer request needed.
- A refund and a revoke are separate actions. `orders.refund` takes an optional `revoke` flag. Leave it off and the buyer keeps access, set it to true and Google terminates access to the item immediately.
- Orders older than three years cannot be refunded through the Google Play Developer API. Once that window closes, the order is permanently out of reach.
- `orders.refund` issues full refunds only. A prorated, partial refund on a subscription requires the newer `purchases.subscriptionsv2.revoke` endpoint with a `proratedRefund` context.
- Refunding a subscription order with `revoke` set to true triggers a `SUBSCRIPTION_REVOKED` Real-time Developer Notification, so your backend learns about the revocation the same way it learns about any other subscription event.
- From August 3, 2026, Google charges the purchase price plus bank fees of a chargeback back to the developer. A refund you issue yourself returns the purchase price only, so refunding a shaky order early can be cheaper than letting it become a chargeback.
- A developer-initiated refund is the only Google Play refund flow you fully control. The 48-hour self-service refund, support refunds, and voided purchases are all decided without you.
You do not have to wait for a customer to open a dispute. If you want to give money back, you can refund a Google Play order yourself, directly, with a single API call or two clicks in Play Console. Google will not ask you why, and it will not second-guess you. This is the one refund flow where you hold the button, and using it early, before a dispute hardens into a bank chargeback, is often the cheapest way out.
The one refund flow you actually control
Most refunds on Google Play happen to you, not through you. A buyer who asks Google within 48 hours gets an automatic self-service refund with no developer input. A support agent can grant one that is final the moment it is issued. A bank chargeback is decided between the cardholder and their bank. In all of those, you are a spectator who finds out afterward.
The developer refund is the exception. Here you are the one deciding to return the money, on your own schedule, for your own reasons. It is a goodwill tool, a customer-service tool, and quietly, a cost-control tool. Knowing exactly how it behaves is what turns it from a panic button into a deliberate choice.
What orders.refund does, in one call
The orders.refund method in the Google Play Developer API refunds a single order, whether that order was a one-time in-app purchase or a subscription payment. You send an empty POST to the order's refund path, authenticated with your service account, and a successful call returns an empty body. That is the entire mechanism.
The revoke flag decides whether they keep access
The one choice the call gives you is the revoke query flag. Google's reference is blunt about what it does: if set to true, access to the subscription or in-app item will be terminated immediately. Omit it, and the money goes back while the customer keeps whatever they bought. That single boolean is the difference between a friendly refund and a clean cancellation.
| Part of the call | Value |
|---|---|
| Method and path | POST /androidpublisher/v3/applications/{packageName}/orders/{orderId}:refund |
packageName | Your app id, for example com.acme.app |
orderId | The order id shown to the buyer at purchase |
revoke | Optional query flag. true terminates access immediately, omit it to refund and leave access intact |
| Request body | Empty |
| OAuth scope | https://www.googleapis.com/auth/androidpublisher |
Full refund by default, prorated only for subscriptions
orders.refund returns the entire order value. It has no field for a partial amount. If you need to hand back part of a subscription, reach for the newer purchases.subscriptionsv2.revoke endpoint, which accepts a revocation context and can issue either a full refund or a prorated one based on the time left in the period. The older purchases.subscriptions.revoke did full refunds only, which is the main reason the v2 method exists. For one-time orders, partial refunds are available through the Play Console website for purchases placed after March 2018, and never for paid apps.

The three-year wall and other limits
The hard boundary is age. Google states plainly that orders older than three years cannot be refunded. There is no appeal and no override once an order crosses that line, so a refund is a decision with an expiry date on it. A handful of other limits shape what the call can and cannot do.
| Limit | What it means |
|---|---|
| Three-year age cap | Orders older than three years cannot be refunded through the API |
| Full amount only | orders.refund returns the whole order value, never a partial amount |
| Partial refunds | Available for subscriptions via purchases.subscriptionsv2.revoke, or through the Play Console for one-time orders placed after March 2018, never for paid apps |
| Not reversible | Once you issue a refund it cannot be undone |
What this saves you in money
Every refund is already a loss before you touch the button, because the money you spent serving that purchase does not come back with it. If the buyer generated images, ran API calls against your models, consumed storage, or triggered a payout to a third party, those costs are spent and stay spent. The refund only decides who holds the sale price on top of that.
The reason to reach for a refund yourself is what happens if you don't. Google's documentation is explicit: from August 3, 2026, when a customer disputes a charge with their bank, Google passes the purchase price and the bank's chargeback fee to the developer. A refund you issue through orders.refund returns the purchase price alone. So for an order you already expect to lose, a self-issued refund is cheaper than the chargeback by exactly the bank fee, and it closes the case before it can escalate.
Where a self-refund sits among the other refund flows
It helps to see the developer refund next to everything else that can pull money back out of your account. Only two of these flows ever ask for your input, and only one of them lets you start the refund yourself.
| Refund flow | Who decides | Your control |
|---|---|---|
Developer refund (orders.refund) | You | Full. You choose whether and when |
| 48-hour self-service refund | None. Google refunds automatically | |
| Support-agent refund | Google or Apple support | None. Final once granted |
Chargeback review (orders.reviewrefund) | Google, using your evidence | A 24-hour input window only |
| Voided Purchases API | Nobody, it is read-only | None. You only read what already happened |
How to refund a Google Play order, start to finish
From the Play Console
- Open Play Console and select Order management in the left menu.
- Find the order by its order id or the buyer's full email address.
- Under the price, choose Refund and pick a refund reason. Use the website, not the mobile app, if you need a partial refund.
From the API
- Authenticate a service account that holds the
androidpublisherscope and financial permissions in Play Console. - Send an empty POST to the order's refund path, adding
revoke=trueonly if you also want to cut off access. - Handle the empty success response, and if you revoked a subscription, expect a
SUBSCRIPTION_REVOKEDnotification to reach your backend.
A developer refund is a small, sharp instrument. It gives you a clean way to make a customer whole, and a cheaper exit than a chargeback on an order you were going to lose anyway. The only rule is to use it on purpose, with the revoke flag set the way you actually mean it.
Frequently asked questions
- Can I refund a Google Play order without cancelling the customer's access?
- Yes. Call `orders.refund` and leave the `revoke` flag off. The buyer gets their money back and keeps access to the item. Set `revoke` to true only when you also want to terminate access to the purchase immediately.
- How far back can I refund an order on Google Play?
- Up to three years from the purchase date. The Google Play Developer API states that orders older than three years cannot be refunded, and there is no override once that window closes.
- Does orders.refund support partial refunds?
- No. `orders.refund` issues the full order amount only. For a partial or prorated refund on a subscription, use `purchases.subscriptionsv2.revoke` with a `proratedRefund` context, or issue a partial refund through the Play Console for eligible one-time orders.
- Will my backend find out when I revoke a subscription with a refund?
- Yes. Refunding a subscription order with `revoke` set to true triggers a `SUBSCRIPTION_REVOKED` Real-time Developer Notification, so your server can update entitlement the same way it handles any other subscription event.
- Is refunding an order myself better than letting it become a chargeback?
- Often, in pure cost terms. From August 3, 2026 a chargeback costs the developer the purchase price plus the bank fee, while a refund you issue returns the purchase price only. If an order is clearly heading for a dispute, refunding it early avoids the added bank fee.
Sources and further reading
- Google Play Developer API: Method orders.refund
- Android Developers: Manage subscriptions and one-time purchases
- Play Console Help: Manage your app's orders and issue refunds
- Google Play Developer API: Method purchases.subscriptionsv2.revoke
- Google Play Console Help: refund protection and chargeback cost responsibility
- Google Play Help: Learn about Google Play refund policies
RefundHalt
The refund autopilot for the App Store and Google Play
Keep reading
Apple's Send Consumption Information now asks for five fields, not twelve, and here's each one
When a customer asks Apple for a refund, the Send Consumption Information payload is your reply. Apple cut it from twelve fields to five, three required and two optional. Here is every field, the values each one accepts, and the 12-hour window you send it in.
There's one endpoint that returns a customer's entire App Store refund history, and here's what it hands back
Apple's Get Refund History endpoint returns a customer's full App Store refund history as signed transactions. Here is every field, how the revision token paginates, why it is per customer and not per app, and what a refund you miss costs you.