Skip to main content
Refund Keeper is enabled per store. The App Store and Google Play have separate requirements and a handling option each, and that option is what turns a store on, so enabling one leaves the other untouched. Before you start, check the requirements. Setup spans two places: the Refund Keeper section hosts the setup guide that tracks your progress, while the controls themselves live in Settings — the store credentials on each store’s card, and the handling option under Settings → Refund Keeper.

​
What does the setup guide check?

The Refund Keeper section shows a setup guide that tracks each prerequisite and completes items by fact rather than by self-attestation. Two of the items complete themselves once data starts arriving, and you cannot tick them manually. The first two items of each store are its connection items, and they are what gates the store: until both are complete, Refund Keeper cannot be turned on for it. The third item is the handling choice itself — the step that turns the store on once its connection is in place, not a precondition for it. The dashboard names the specific missing item instead of failing with a generic error.
The Refund Keeper setup guide, with three App Store steps and three Google Play steps tracked separately

The setup guide tracks the App Store and Google Play steps separately; the notification steps complete on their own

The guide’s Enable … in Settings button is not a separate switch — it is a shortcut to that store’s handling option, which is the control that turns the store on. It stays disabled while the store’s connection items are open. When the guide says a store’s steps must be complete before you enable it, it means those connection items: the third item is the enabling itself.

​
How to enable Refund Keeper for the App Store

1

Point App Store Server Notifications V2 at Qonversion

Follow the Apple Server-to-Server Notifications guide. Version 1 notifications are not supported: they do not carry the refund events Refund Keeper needs. This step completes itself once a notification arrives, which can take a few minutes.
2

Add a key for App Store Server API requests

Refund Keeper sends consumption responses through the App Store Server API. Use an In-App Purchase API key, the key Apple documents for this API, or an App Store Connect API key. Upload the .p8 file with its Key ID and Issuer ID in Settings → App Store. Pages written before the menu was reorganised call the same place Project Settings → Stores → Apple App Store.
3

Choose how refund requests are handled

Open Settings → Refund Keeper and pick one of the App Store options: Do not handle, Send usage data and let Apple decide, Ask Apple to decline the refund, or Ask Apple to grant the refund. The option is the switch: anything other than Do not handle turns Refund Keeper on for the App Store. Refund Keeper then starts answering refund requests that arrive from this moment on, and requests Apple already decided are not revisited.

​
How to enable Refund Keeper for Google Play

On Google Play, Refund Keeper answers chargeback disputes, not regular Play refunds. See how the Google Play flow works.
1

Connect an Android app with a Google Play service account key

Refund Keeper answers through the Google Play Developer API using the same credentials Qonversion uses to validate purchases. Follow Set up Google Play for Qonversion and make sure the service account has access to the Google Play Developer API.
2

Point Real-time developer notifications at Qonversion

Refund Keeper learns about disputes only from RTDN. Follow Google Real-time Developer Notifications. This step completes itself once the first notification arrives.
3

Choose how chargeback disputes are handled

Open Settings → Refund Keeper and pick one of the Google Play options: Do not handle, Send usage data and let Google decide, Ask Google to decline the dispute, or Ask Google to grant the dispute. As on the App Store, the option is the switch: anything other than Do not handle turns Refund Keeper on for Google Play, and it starts answering disputes that arrive from this moment on, within Google’s 24-hour response window.
The Refund Keeper settings page with one handling option per store: the App Store set to Ask Apple to decline the refund, Google Play set to Do not handle

Settings → Refund Keeper: one handling option per store, with Do not handle as the off state. Here the App Store is on and set to decline, while Google Play is still off because its RTDN step is not finished — until RTDN arrives, a Google Play answering option cannot be applied

Enabling Google Play requires RTDN to have delivered at least one notification. Until a store’s connection steps are done — the credentials, and a first notification actually received — the dashboard does not let you turn that store on, and the setup guide’s own Enable Google Play in Settings action stays disabled. Choosing the handling option is the step that follows, not a precondition. This is by design: a keeper that is on while notifications are silent loses disputes without any signal.

​
What happens right after you enable a store?

  • Refund Keeper answers only events that arrive after the store is on. Nothing is applied retroactively.
  • The first answers may take a few minutes to appear because the opt-in is cached briefly on the serving path.
  • Items start appearing in the Refund Keeper table with status Pending. App Store requests show a countdown to Apple’s answer deadline; Google Play disputes appear only once Google has accepted Refund Keeper’s answer, and their Deadline column shows Answered. See Refund Keeper analytics.
  • Changing the handling option later affects the next event only. Answers already sent cannot be revised.

​
Troubleshooting

The dashboard names the missing prerequisite. The usual causes are a missing or rejected App Store key, no App Store notification received yet, no Android app with a service account key, or no RTDN notification received yet.
Both notification items complete by fact, so they stay open until a message actually arrives. Re-check the destination configured in App Store Connect or in the Google Play Console, then trigger any purchase event in a sandbox or test environment. For Google Play, confirm the topic you configured matches the one Qonversion shows, and that the subscription attached to it still points at the Qonversion endpoint.
Refund Keeper requires a key Apple accepts for App Store Server API requests. Replace it with an In-App Purchase API key and confirm the Key ID and Issuer ID match the uploaded .p8 file.
Google does not return the verdict when the answer is sent. Qonversion detects the outcome afterwards from follow-up notifications and order state, so Saved or Refunded appears later than the answer. Until then the dispute stays Pending. If seven days pass with no refund on the order, the dispute is recorded as Saved, dated at that seven-day mark; the row itself flips about two days later, once late refund data has had time to arrive.
Refund Keeper Refund Keeper Analytics