Refund Saver

Whenever a user requests a refund, the store investigates before deciding. To judge if the refund is justified, it asks the developer for information about that user’s activity. Without this evidence, even a heavily used subscription is likely to be refunded.

The Refund Saver answers these requests automatically, protecting your revenue and increasing the chance of denial for unfair requests. It works on both the App Store and Google Play and covers every in-app purchase type — auto-renewable subscriptions, one-time subscriptions, consumables, and non-consumables (including lifetime products).

How Refund Saver works

1. When a user initiates a refund request, the store sends a notification asking for transaction and usage details.

   If you ignore or delay the response, the store is likely to approve the refund.

2. The Adapty Refund Saver answers these notifications automatically and sends the store the necessary data.

   This automation reduces the chance of unnecessary refunds, while saving time and protecting your revenue.

3. Adapty records each outcome — refunded or declined. That data drives the Refund Saver analytics in the Dashboard.

How the stores differ

Refund Saver works on both stores, but each one handles refunds its own way.

On Google Play, a user can get a refund in one of two ways. Google decides a refund request without your input, so Refund Saver never sees it. A chargeback is different: the user asks their bank to reverse the payment, Google asks for your input before the dispute settles, and Refund Saver answers for you. A chargeback the user wins costs you both your share of the purchase price and the bank’s chargeback fee.

Store-specific prerequisites

App Store

When a user asks Apple for a refund, Apple investigates. Before deciding, it sends you a consumption request — a request for details about how the user used the purchase. Refund Saver answers the request with your preferred outcome and the user’s consumption data.

To use Refund Saver on the App Store, you need to:

1. Enable App Store Server Notifications V2: Refund Saver doesn’t work with V1 notifications, which Apple has deprecated.
2. Add the In-App Purchase key: Refund Saver signs its answer to Apple with the In-App Purchase key. Adapty needs the Issuer ID, Key ID, and .p8 file in App settings → iOS SDK, plus your Bundle ID — without all four, it can’t answer a consumption request. See Generate an In-App Purchase key.
3. Disclose consumption-data use in your Privacy Policy: Apple requires the disclosure, and it’s on you, not Adapty. See Apple’s App Privacy Details for what to disclose.
4. Obtain user consent for data sharing: Also on you — Apple requires valid consent before Adapty shares a user’s data. See Obtain user consent.

Google Play

To use Refund Saver on Google Play, connect the store and enable RTDN — both part of the standard Google Play integration: Configure Google Play Store integration and Enable Real-time developer notifications (RTDN). Google announces each refund review through RTDN, so without it, reviews pass unanswered. No user consent is needed — a chargeback dispute involves no personal-data sharing.

Turn on Refund Saver

You turn on Refund Saver once. Once the feature is on, Adapty answers refund requests from both App Store and Google Play, provided the two are properly connected to Adapty, and you satisfy the store-specific prerequisites.

1. Open the Refund Saver section in the Adapty Dashboard.
2. Click Turn on refund saver.

Configure Refund Saver

After the feature is on, you can set up the Refund Saver. Settings apply at two levels:

• App-level defaults: A refund preference for each store, plus the default consent policy — the consent Refund Saver assumes for users with no recorded consent value. You set both in the Edit Refund saver preferences window.
• Per-user overrides: A refund preference and a consent value for a specific user. When set, they take priority over the app-level defaults. Set the preference from the Dashboard, the SDK, or the server-side API — all three write the same value. Consent updates come from the SDK or the API.

Set a refund preference for each store

The refund preference is what Adapty recommends when it answers refund requests. Adapty applies it to every request in that store, instead of deciding case by case. Each store keeps its own preference. The preference is only a recommendation — the store makes the final call.

1. To change your preference, in the Refund Saver section, click Refund Saver Settings.

2. In the Edit Refund saver preferences window, select the Apple or Google tab.

   

3. Choose your Default refund request preference option:

   Option	Description
   Decline first refund request, grant all next	(default) For every transaction Refund Saver encounters, it initially asks the store to decline the refund. If the same transaction appears again, Refund Saver recommends granting the refund. This approach reduces user frustration from unfair refund declines — users can request the refund again and will likely receive it.
   Always decline	Asks the store to decline every refund request, including repeat requests for the same transaction.
   Always refund	Suggests that the store approve every refund request.
   Grant prorated refund	Suggests that Apple refund only the unconsumed part of the purchase, so you keep the revenue for the part the user has already used. App Store only — the Google tab doesn’t offer this option.
   No preference	Do not provide any recommendations to the store. In this case, the store will determine the refund outcome based on its internal policies and user history, without any influence from your settings. This option is the most neutral approach.

Choose the right preference

Declining every request doesn’t guarantee fewer refunds. The store treats your response as only a suggestion. Developers report that Apple may approve a larger share of requests, even when you ask to decline them all. Repeat declines for the same transaction also give the user a reason to submit the request again. For most apps, Decline first refund request, grant all next keeps the upside of declining the first request without creating a pattern of repeat declines.

A prorated refund is the middle option between declining and granting. It works on the App Store only. You return the unused part of the purchase and keep the rest, instead of risking the whole payment on a decline. Prorated refunds fit purchases the user has partly used — a coin pack with half the coins spent, or a yearly plan canceled in the second month. Google accepts only decline, approve, or no preference on a refund review, so Refund Saver can’t ask for a partial refund there. You can still issue one by hand from Play Console Order management.

How Adapty calculates the consumed share

A prorated refund covers the unconsumed part of a purchase, so Apple needs to know how much of the purchase the user has already consumed.

• Auto-renewable subscriptions: Apple calculates the consumed share itself, and Adapty sends the preference to Apple without a consumption percentage.
• Every other product type: Adapty calculates the consumed share and sends it to Apple together with the preference. Adapty takes the share from one of two sources:
  • Virtual currency: The spent share of the virtual currency balance the purchase granted, averaged across every currency it granted. The spent share is only as accurate as the spending your app reports through the server-side API.
  • Access period: The elapsed share of the period, used when the purchase granted no virtual currency.

Apple accepts a prorated refund only for a partly consumed purchase. Adapty sends a different preference in the remaining cases:

• For a fully consumed purchase, Adapty asks Apple to decline the refund.
• For an untouched purchase, Adapty asks Apple to grant the full refund.
• For a purchase with neither virtual currency nor an access period, Adapty has no consumption data to send, and it responds to Apple without a preference. A consumable that grants no virtual currency falls into this case.

Set the default consent policy

The Default consent policy applies to users with no recorded consent value. Your app hasn’t reported their consent through the SDK or the server-side API. The policy defines how Refund Saver treats these users. Match it to the consent approach you chose in Obtain user consent: in the Edit Refund saver preferences window, on the Apple tab, set the Default consent policy option.

Set refund behavior for a specific user in the dashboard

You may want to set individual preferences for specific users. Open the user’s profile and find the Refund saver settings card at the bottom of the left column.

The per-user preference is one value for both stores. Set Refund request preference to Grant refund, Grant prorated refund, Decline refund, or No preference. Adapty applies the value to the user’s refund requests on both the App Store and Google Play. Grant prorated refund has no Google equivalent, so Adapty sends No preference on Google Play.

Obtain user consent

How you collect user consent for data sharing is up to you, but Apple requires valid user consent before sharing any personal data with them. Apple recommends using an opt-in approach, which involves in-app prompts that explain how data will be used and require explicit user action to provide consent. If a user ignores or denies the prompt, they are not considered to have consented. For more details, refer to Apple’s guidelines.

If explicit consent isn’t practical for your app, you can consider an opt-out approach. This involves including a data-sharing clause in your Terms of Service, explaining that users agree to data sharing by accepting the terms. Be sure to clearly outline how users can revoke their consent.

Below is an example clause for the opt-out approach, including the types of data you might share. This is only a sample to guide you in crafting your own text. You are responsible for ensuring your final version complies with all applicable laws and Apple’s requirements.

“If we receive a refund request for an in-app purchase, we may provide Apple with information about the user’s in-app purchase activity. This could include details such as time since app installation, total app usage time, an anonymous account identifier, whether the in-app purchase was fully consumed, whether it included a trial period, the total amount spent, and the total amount refunded.”

After you choose an approach, set the matching default consent policy in the Dashboard.

Check user consent

Review a user’s consent status to verify that their consent choice has reached Adapty. In the Adapty Dashboard, open the user’s profile and find the Allow data sharing setting in the Refund saver settings card. Yes and No show the user’s recorded choice; Not set means Refund Saver follows your default consent policy.

Track savings from refund requests

The Refund Saver section reports how many refund requests Adapty answered and how each was resolved. To view one store’s numbers, select the Apple or Google tab at the top of the page. All Platforms combines both stores.

Google doesn’t notify Adapty when it resolves a refund review, so Adapty polls the order status until the review is settled. As a result, Google Play outcomes appear later than App Store ones.

The Refund Saver section covers only the requests that reached Refund Saver. For all refunds across your app — including the ones Google decides without your input — see the Refund money and Refund events charts in Analytics.

Manage Refund Saver from your app code

Your app can write two per-user values through the iOS SDK:

• Refund request preference: What Adapty recommends when it answers this user’s refund requests. The value belongs to the profile rather than to either platform, so a refund request preference applies on both the App Store and Google Play.
• Consent to share data: Whether Adapty may send this user’s purchase data to Apple. Consent applies to the App Store alone.

Use the SDK for choices the user makes in your own UI — a consent prompt, a preference toggle. The Dashboard and the server-side API write the same two values. Android has no equivalent methods — the multi-platform frameworks write these values on iOS only.

Set a refund preference for a user

You can set the refund preference in your app code individually for every installation depending on some user’s actions. The preference applies to the user’s refund requests on both stores. Use the snippet below to set the preference:

do {
  try await Adapty.updateRefundPreference(<PREFERENCE_VALUE>) // possible values: .noPreference, .grant, .decline
} catch {
  // handle the error
}

try {
  // possible values: AdaptyRefundPreference.noPreference, AdaptyRefundPreference.grant, AdaptyRefundPreference.decline
  await Adapty().updateRefundPreference(<PREFERENCE_VALUE>);
} on AdaptyError catch (adaptyError) {
  // handle the error
} catch (e) {
  // handle the error
}

try {
    await adapty.updateRefundPreference(<PREFERENCE_VALUE>); // possible values: RefundPreference.NoPreference, RefundPreference.Grant, RefundPreference.Decline
} catch (error) {
    // handle the `AdaptyError`
}

Adapty.UpdateAppStoreRefundPreference(<PREFERENCE_VALUE>, (error) => {
  if (error != null) {
    // handle the error
    return;
  }
});

The SDK accepts only the grant, decline, and no-preference values. To set Grant prorated refund for a user, use the Dashboard or the server-side API.

Update a user’s consent

To tell Adapty whether a specific user has given consent, use the updateCollectingRefundDataConsent method. Consent reaches Apple alone: a Google Play refund review carries no consent field at all. The value persists server-side against the profile, so one call per change is enough.

do {
 try await Adapty.updateCollectingRefundDataConsent(<CONSENT_VALUE>) // true = consent is explicitly provided, false = consent is explicitly revoked
} catch {
 // handle the error
}

try {
  // true = user gave consent, false = user revoked consent
  await Adapty().updateCollectingRefundDataConsent(<CONSENT_VALUE>);
} on AdaptyError catch (adaptyError) {
  // handle the error
} catch (e) {
  // handle the error
}

try {
    await adapty.updateCollectingRefundDataConsent(<CONSENT_VALUE>); // true = consent is explicitly provided, false = consent is explicitly revoked
} catch (error) {
    // handle the `AdaptyError`
}

Adapty.UpdateAppStoreCollectingRefundDataConsent(<CONSENT_VALUE>, (error) => {
  if (error != null) {
    // handle the error
    return;
  }
});