Skip to main content
Solved

How to communicate subscription plan after a crossgrade

  • 11 September 2021
  • 6 replies
  • 193 views

Forum|alt.badge.img+3

Say I have subscription plans A and B (same level).

From entitlement.productIdentifier I detect that a user is, say, subscribed to A. With this information, I keep option B available for a crossgrade, and A disabled and marked as active.

When they opt to subscribe to B, A is still active (because it will remain so until the renewal date). The purchase succeeds but do I have the information to communicate the current scenario? I would like to disable B as well, because it is already purchased, and mark it somehow as active starting on certain date. 

Apparently I don’t have the information to figure out this scenario in PurchaserInfo, do I?

Best answer by jazmine

Hey @Germán Buela ,

We don’t have the information for a pending renewal in purchaerInfo, but we do have a workaround with using webhooks. When a user makes a product change, a webhook will be sent out with the event type PRODUCT_CHANGE. Here is an example of this type of webhook :

 

{
  "event" : {
    "event_timestamp_ms" : 1601338594769,
    "product_id" : "com.revenuecat.myapp.monthly",
    "period_type" : "NORMAL",
    "purchased_at_ms" : 1601304429682,
    "expiration_at_ms" : 1601311606660,
    "environment" : "PRODUCTION",
    "entitlement_id" : "subscription",
    "entitlement_ids" : [
      "subscription"
    ],
    "presented_offering_id" : "defaultoffering",
    "transaction_id" : "GPA.1234-1234-1234-12345",
    "original_transaction_id" : "GPA.1234-1234-1234-12345",
    "app_user_id" : "$RCAnonymousID:12345678-1234-1234-1234-123456789123",
    "aliases" : [
      "$RCAnonymousID:12345678-1234-1234-1234-123456789123"
    ],
    "original_app_user_id" : "$RCAnonymousID:12345678-1234-1234-1234-123456789123",
    "new_product_id" : "com.revenuecat.myapp.yearly",
    "currency" : "USD",
    "price" : 0,
    "price_in_purchased_currency" : 0,
    "subscriber_attributes" : {},
    "store" : "PLAY_STORE",
    "takehome_percentage" : 0.70,
    "type" : "PRODUCT_CHANGE",
    "id" : "12345678-1234-1234-1234-12345678912"
  },
  "api_version" : "1.0"
}

In the webhook you get : 

  • product_id : Old product ID you are switching from

  •  new_product_id : New Product ID you are switching to

  • Expiration_at_ms : Expiration date of old product 

    • If this time is in the future this means it is a downgrade/ Crossgrade

    • If this time is in the past this means it was an upgrade

With this information you could store this on your backend and relay the information and possibly disable B subscription ( as you described in your example).

View original
Did this post help you find an answer to your question?

6 replies

Forum|alt.badge.img+2
  • New Member
  • 1 reply
  • September 11, 2021

This question is also of interest. I found only “activeSubscriptions” in the SDK, but this displays an active subscription, and not a subscription for which the renewal will take place. Please let me know if you find the answer.


jazmine
Forum|alt.badge.img+7
  • Dedicated Contributor
  • 122 replies
  • Answer
  • September 15, 2021

Hey @Germán Buela ,

We don’t have the information for a pending renewal in purchaerInfo, but we do have a workaround with using webhooks. When a user makes a product change, a webhook will be sent out with the event type PRODUCT_CHANGE. Here is an example of this type of webhook :

 

{
  "event" : {
    "event_timestamp_ms" : 1601338594769,
    "product_id" : "com.revenuecat.myapp.monthly",
    "period_type" : "NORMAL",
    "purchased_at_ms" : 1601304429682,
    "expiration_at_ms" : 1601311606660,
    "environment" : "PRODUCTION",
    "entitlement_id" : "subscription",
    "entitlement_ids" : [
      "subscription"
    ],
    "presented_offering_id" : "defaultoffering",
    "transaction_id" : "GPA.1234-1234-1234-12345",
    "original_transaction_id" : "GPA.1234-1234-1234-12345",
    "app_user_id" : "$RCAnonymousID:12345678-1234-1234-1234-123456789123",
    "aliases" : [
      "$RCAnonymousID:12345678-1234-1234-1234-123456789123"
    ],
    "original_app_user_id" : "$RCAnonymousID:12345678-1234-1234-1234-123456789123",
    "new_product_id" : "com.revenuecat.myapp.yearly",
    "currency" : "USD",
    "price" : 0,
    "price_in_purchased_currency" : 0,
    "subscriber_attributes" : {},
    "store" : "PLAY_STORE",
    "takehome_percentage" : 0.70,
    "type" : "PRODUCT_CHANGE",
    "id" : "12345678-1234-1234-1234-12345678912"
  },
  "api_version" : "1.0"
}

In the webhook you get : 

  • product_id : Old product ID you are switching from

  •  new_product_id : New Product ID you are switching to

  • Expiration_at_ms : Expiration date of old product 

    • If this time is in the future this means it is a downgrade/ Crossgrade

    • If this time is in the past this means it was an upgrade

With this information you could store this on your backend and relay the information and possibly disable B subscription ( as you described in your example).


Forum|alt.badge.img+3
  • Author
  • New Member
  • 2 replies
  • September 17, 2021

Thank you Jazmine,

I actually don’t have a backend so this solution doesn’t apply to my case.

I suppose not disabling subscription B won’t have any major consequences. If the user picks B again, it would either fail or be reported as success without any unexpected charge.


Forum|alt.badge.img+1

The webhook is not a valid solution. We should be able to get that information, otherwise we can not manage changing from a monthly subscription to an annual one, for example. This is a basic feature we should expect from RevenueCat. 

I don’t think the answer should be marked as SOLVED.

 

:disappointed:


Forum|alt.badge.img+3
  • New Member
  • 1 reply
  • March 1, 2024

@jazmine is there any update on this? webhook isn’t really a good solution


Forum|alt.badge.img+4

I also need this feature, preferably without webhooks, but directly in the customer information.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings