Skip to main content

Hi there!


We have one subscription subscription_id, within which there are two base plans base_plan_id_1 and base_plan_id_2.

After purchasing, our application sends a fetch token to our server, which we forward to /v1/receipt/:

{
  "app_user_id": "$someUserId",
  "fetch_token": "$someValidFetchToken",
  "is_restore": false,
  "product_id":  "subscription_id"
}
 

The call is executed successfully, but in RevCat and all webhook events, it always shows that the base plan base_plan_id_1 was purchased, regardless of which actual base plan was bought.

Example:

  • User buys a Monthly subscription for 0.99 - it works and is tracked correctly
  • User buys a Yearly subscription for 9.99 - it’s tracked in RevenueCat as Monthly for the price of 9.99


 

After studying the SDK, we tried sending the following variants, but nothing changed.

  1. Sending platform_product_id:
{
  "app_user_id": "$someUserId",
  "fetch_token": "$someValidFetchToken",
  "is_restore": false,
  "product_ids": i
    "subscription_id"
  ],
  "platform_product_ids": i
    {
      "product_id": "subscription_id",
      "base_plan_id": "base_plan_id_2"
    }
  ]
}

 

  1. Sending platform_product_id and pricing_phases:
{
  "app_user_id": "$someUserId",
  "fetch_token": "$someValidFetchToken",
  "is_restore": false,
  "product_ids": _
    "subscription_id"
  ],
  "platform_product_ids": _
    {
      "product_id": "subscription_id",
      "base_plan_id": "base_plan_id_2"
    }
  ],
  "pricing_phases": a
    {
      "billingPeriod": "P1Y",
      "billingCycleCount": null,
      "recurrenceMode": 1,
      "formattedPrice": "£58.99",
      "priceAmountMicros": "58990000",
      "priceCurrencyCode": "GBP"
    }
  ]
}

 

Hey @Haley Pace, @Michael Fogel, @cody 

Sorry for nudging, but could we please get your feedback? We’re currently blocked due to that issue and can not release a yearly subscription on Android due next week. Maybe there are some workarounds? 
Thanks

Best,
Whisk (Samsung Food) Team

Hi @whisk-developer,

It looks like your annual product is still in Draft status (I’m looking at your production app, let me know if this is still testing in your development app) - in order for users to be able to purchase it successfully, the specific base plan would need to be marked as Active. You can check on this by going into your app in Google Play, clicking on the specific subscription ID, then clicking into the base plan that’s not working. It should say “Active” at the top left under “Edit base plan”. If it doesn’t, you can Activate it using the button at the bottom right. 

Hi @kaitlin, nice to meet you. 
Thank you for your response. 
 

We are testing this on the dev app and the issue described happens there. All subscriptions are active there. So I believe that it’s not the issue. 
We’re not ready to move this to production until we have a working flow on the dev environment. 
Thank you

Hi @kaitlin,

Here is an example in our production app - https://app.revenuecat.com/customers/1ed7038e/102018acb4de1a17973a76678c69c5ea558

1) 2023-10-30 01:04 PM UTC - user buys `699-v0` base plan for 7.99 and it’s tracked correctly 
2) 2023-10-30 01:11 PM UTC - user buys `5999-v0` base plan for 69.99 but it’s tracked as `699-v0`.

 All products are in active status.

Hey team, any updates on this please? 
Thanks

@whisk-developer just to understand what you are trying to accomplish.

 

You have your own logic to do the purchase and you are forwarding manually (with your server) requests to the post receipt endpoint, right? 

Hey @MarcosC,
Yes, this is correct.

  • we retrieve the fetch token on the device
  • forward it to our server
  • send it to the /v1/receipt endpoint 

ok, cool, let me dig deeper into this…. my assumption is that we are probably processing your purchase as it was done with billing client 4 (or lower) where there was no concept of base plans, and we take the default value (need to confirm this).

 

In the meantime, as a workaround, could you try adding this header to the request? → `X-Version: 6.9.5`

Thank you @MarcosC.
Yes, this was also our assumption that it’s a fallback to the default value.
Sure, we will give it a try and report back!

@MarcosC 
It seems that the `X-Version` header helps. We still use some undocumented attributes as described in the first post thought. 
Could this be considered as a production-ready solution or we should wait for your update?
Thanks

Cool, it’s what the SDK sends, so it’s fine to use → https://github.com/RevenueCat/purchases-android/blob/3a1ca224769cb3eadc99748a2f615c9648fec297/purchases/src/main/kotlin/com/revenuecat/purchases/common/HTTPClient.kt#L265

 

but we’ll fix this to remove that unnecessary dependency. I

’ll let you know when the header is not needed

Awesome, thanks a lot! 

Reply


Terms & ConditionsCookie settings