Skip to main content
Refund Keeper answers two different store events on your behalf: Both stores keep the final decision. Refund Keeper only makes sure the store hears your side before deciding, and it answers within the store’s response window — a window most teams cannot hit by hand. Each store is enabled separately. Turning Refund Keeper on for the App Store does not enable it for Google Play, and the opposite is also true.

​
How does Refund Keeper answer App Store refund requests?

1

A customer requests a refund

The request goes to Apple, not to you.
2

Apple asks for usage data

Apple sends a CONSUMPTION_REQUEST App Store Server Notification V2 to Qonversion.
3

Refund Keeper answers through the App Store Server API

It sends how much of the purchase was consumed, whether a sample or trial was provided, and your refund preference.
4

Apple decides

With usage data in hand, Apple approves fewer unjustified refunds. Without an answer, Apple decides on the data it already has.
The App Store refund flow with Refund Keeper answering on the developer's behalf

The App Store refund flow with Refund Keeper answering on the developer's behalf

​
How does Refund Keeper answer Google Play chargeback disputes?

A chargeback is not a refund request. The customer disputes the charge with their bank or payment provider, and Google Play asks the developer to review only those chargebacks that are eligible for review.
1

A customer disputes a charge with their payment provider

Google Play receives the chargeback.
2

Google Play asks for a review

Google sends a PendingRefundReviewNotification through Real-time developer notifications (RTDN). Chargebacks that Google does not send this notification for are outside Refund Keeper’s scope.
3

Refund Keeper answers through the Google Play Developer API

It calls orders.reviewrefund with your preference and the purchase usage evidence it has: whether a sample or trial was provided, and the consumed share of the purchase.
4

Google decides, and Qonversion detects the outcome

The result is not returned in the response. Qonversion detects it afterwards from Google’s follow-up notifications and order state, so the outcome appears in analytics with a delay.

​
What are the Google Play timings?

If the purchase has not reached Qonversion within the 2-hour grace period, Refund Keeper still answers before the window closes, but without usage evidence. Answering with less data beats not answering: the review is the only point at which your preference and evidence can reach Google, and a review left unanswered is decided without either.

​
Why does answering a Google Play dispute matter?

Because the chargeback is now partly your cost. Google states that for orders placed after 3 August 2026, Google Play and developers share chargeback costs, split as follows: Google’s own guidance on those changes points to the Review Refund API as the way to take an active role: sharing the order’s delivery state and consumption status lets Google Play identify and contest illegitimate chargebacks on the developer’s behalf. That API is exactly what Refund Keeper calls for you, inside the response window, on the review-eligible disputes that arrive once Google Play is enabled. See Updates to refund protection and chargeback cost responsibility for Google’s statement of the cost split.

​
What does Refund Keeper send to the store?

What Refund Keeper sends is the purchase usage described in the table above, derived from the customer’s own purchase history as Qonversion tracks it. That is data collected from your customer, which is why Apple puts the consent and disclosure duty on you: see the consent prerequisite below and keep the sharing disclosed in your privacy policy.

​
What do you need before enabling Refund Keeper?

​
Requirements for both stores

  1. Qonversion implemented in Analytics or Subscription Management mode. Refund Keeper can only describe transactions Qonversion knows about.
  2. A privacy policy that discloses sharing app usage data. Required by Apple’s guidelines and good practice for Google Play.
  3. An EULA that permits sharing end-user data with third parties, including the stores. If you integrated the Qonversion SDK, this clause may already be in place. See the Qonversion Privacy Policy.
  4. Customer consent to share their purchase usage with the store, obtained by you. Apple requires the developer to have the customer’s consent before consumption information is sent, and documents it as part of the consumption request. This is a separate obligation from the App Tracking Transparency prompt, which covers tracking across apps and services and is not a consent to share purchase usage. Refund Keeper does not collect this consent for you and cannot verify it: obtaining it, in your app or in your terms, stays on your side. See Apple’s Send Consumption Information guide.

​
Additional requirements for the App Store

  1. App Store Server Notifications V2 pointed at Qonversion. Version 1 notifications do not carry the refund events Refund Keeper needs. See Apple Server-to-Server Notifications. This requirement is satisfied by the fact of a received notification, not by a checkbox.
  2. A key for App Store Server API requests. An In-App Purchase API key is the key Apple documents for this API and is the recommended choice. An App Store Connect API key also works. Apple must accept the key: a key Apple rejects blocks enabling.

​
Additional requirements for Google Play

  1. An Android app connected to Qonversion with a Google Play service account key, the same credentials used for purchase validation. See Set up Google Play for Qonversion.
  2. Real-time developer notifications (RTDN) pointed at Qonversion, with at least one notification already received. Refund Keeper learns about disputes only from RTDN. See Google Real-time Developer Notifications.
Refund Keeper refuses to enable Google Play until RTDN has delivered at least one notification. An enabled keeper with silent notifications would mean disputes lost without anyone noticing.

​
What are the refund handling options?

You choose one option per store in Settings → Refund Keeper in the Qonversion dashboard. The dashboard wording below is exactly what you see there, and the option doubles as the on/off switch: Do not handle leaves the store off.

​
App Store options

​
Google Play options

A store you have never configured starts at Do not handle, and it cannot be turned on until that store’s connection steps are done. Ask Apple to decline the refund and Ask Google to decline the dispute are the options that protect revenue, and they are the usual choice when turning a store on. Changing the option takes effect for the next event; answers already sent cannot be revised.

​
What are the limitations?

  • Each store is independent. Enabling one store does not enable the other, and the preference is stored per store.
  • The store always decides. Refund Keeper influences the decision and can never force an outcome.
  • App Store: subscriptions and non-consumable purchases only. Consumable products, such as in-game currency, are not eligible.
  • Google Play: review-eligible chargebacks only. Regular Google Play refunds are decided by Google without developer input, and Refund Keeper neither answers nor tracks them.
  • One answer per event. After Refund Keeper answers, the answer cannot be changed or withdrawn.
  • Google Play outcomes arrive late. Google does not return the verdict in the API response, so the result shows up in analytics after Qonversion detects it.
  • Nothing is retroactive. Refund Keeper answers events that arrive after you enable it.

​
Where do you see the results?

The Refund Keeper section of the dashboard shows requests, disputes, what was won back, and the answer deadline for every item. See Refund Keeper analytics.

Enable Refund Keeper

Step-by-step setup for the App Store and for Google Play.

Refund Keeper analytics

Widgets, the refund table, statuses and filtering by store.
Webhooks Enable Refund Keeper