Skip to main content
Question

After subscription restore: unable to change payment plan (Google Play)

  • April 1, 2026
  • 1 reply
  • 12 views
N
Forum|alt.badge.img+1

Our app offers a single subscription, with a monthly and an annual payment plan (in Google Play terms, one subscription with two base plans). Subscribed users can access the whole content of the app without limitations.

For better flexibility, we also offer subscribed users to switch the payment plan. Since this is a single subscription, we have to use the WITHOUT_PRORATION replacement mode. We build our purchase params like so: 

PurchaseParams.Builder(activity, subscriptionOption)    .oldProductId(currentSubId)    .googleReplacementMode(GoogleReplacementMode.WITHOUT_PRORATION)    .build()

Here is the problem: When a user is currently running with a subscription that has been restored (via the Purchases.sharedInstance.restorePurchasesWith(onError, onSuccess) method), it is no longer possible to switch the payment plan. For the “Transferring purchases seen on multiple App User IDs” setting, we use “Transfer to new App User ID”.

The Play Store shows an error message “Error: We are unable to change your subscription plan” 

After acknowledging, the RevenueCat SDK returns with a PurchaseInvalidError: 

  • message = “One or more of the arguments provided are invalid.” 
  • underlyingErrorMessage = “Error updating purchases. DebugMessage: Account identifiers don't match the previous subscription.. ErrorCode: DEVELOPER_ERROR. SubResponseCode: NO_APPLICABLE_SUB_RESPONSE_CODE.”

I have tried to research the issue on Google, but I wasn’t able to find anything helpful. We do not use anonymous app users. 

    1 reply

    Tarek
    RevenueCat Staff
    Forum|alt.badge.img+4
    • Tarek
    • RevenueCat Staff
    • April 2, 2026

    Hello there,

     

    Tarek from RevenueCat here, happy to assist!

     

    Thank you for all the details, this really helped when investigating this.

     

    First, because your monthly and annual options are base plans of the same Google Play subscription, this switch generally should not be started with oldProductId(...) and googleReplacementMode(...).

     

    For base-plan changes within the same subscription, Google Play handles the switch automatically using the default replacement mode configured in Play Console. Google mentions this in their subscriptions guide here: https://developer.android.com/google/play/billing/subscriptions#resubscribe_or_switch_plans_within_the_same_subscription (matched by our own doc too)

     

    The first thing you could try is testing this flow by launching the purchase for the target subscriptionOption as a normal purchase, without explicitly setting the old product or replacement mode.

     

    Second, the restore case seems to be what triggers the error you’re seeing. When a subscription is originally purchased through the RevenueCat SDK, Google Play stores an obfuscated account identifier for that purchase. If restorePurchases() later transfers that subscription to a different identified App User ID in RevenueCat, the ownership changes on the RevenueCat side, but Google Play still appears to associate the subscription with the original identifier. After that, when a plan change is attempted, Google rejects the replacement with the error you mentioned. This is a limitation on Google’s side unfortunately.

     

    Here a few workarounds I can suggest, in case the first fix above doesn’t work:

     

    • Try and keep a stable App User ID for the same real customer whenever possible.
    • If your app already knows the customer’s original App User ID, using logIn() with that same ID is preferable to restoring into a different App User ID.
    • If a subscription has already been transferred to a different App User ID and the in-app switch keeps failing, a fallback is to send the user to Google Play’s subscription management page, where they should be able to perform the switch.
    • If none of the above fits, another fallback is to cancel the current subscription and then let the user purchase again as a fresh subscription.

     

    I hope this is useful, let me know if there’s anything else I can help you with!

     

    Best regards,

    Terms & ConditionsCookie settingsAccessibility statement