Skip to main content

Lately I received multiple users who already have an active subscription from Google Play, then signed out and created a new account and from what I understand they won’t be allowed to subscribe with the same billing / Google account.

However, I received a webhook call from RevenueCat that he subscribed successfully in the new account with a $0 bill.


This is the webhook call back I have received from RC:

"presented_offering_id": "plus","price": 0,"price_in_purchased_currency": 0,…"transaction_id": "GPA.3333-***

 

And both records has a unique transaction id under the same Google Play account, here’s records:


I am not sure what’s happening, it’s the third times in the last 2 weeks.

Please advise.
 

P.S. I am adding a price check on the webhook function, rejecting new subscriptions with price=0, but not sure any side effects and the user still receive a “successfully subscribed” message on the frontend, so from the user’s angle it will be confusing.

Thank you.

@ryan 
FYR, from the webhook

event type: INITIAL_PURCHASE

event id: 6E796426-1AE6-4CC7-B6F5-BA01D3019CAD

 

Hey @Kev! It looks like that event ID is for a Google transaction GPA.3388-*****. Do you have the one for the $0 transaction?

@ryan 
Here’s all the related events from same Google Play account for payment.
I have attached 1 more cases for your reference.

Case 1 

(1) 2021-07-13 12:35 PM  ( Success and normal )
8176b45e-61e9-4fa5-a005-f30a1b905f35

(2) 2021-08-11 12:08 PM ( New Account, $0 and success )
d6ba4c2e-d04b-4e27-b94f-3a9d8079ce1e

(3) 2021-08-29 12:48 PM ( New Account, $0 and success )
6e796426-1ae6-4cc7-b6f5-ba01d3019cad

Case 2 
(1) 2021-03-08 2:39 AM  ( Success and normal )
e1bb4228-f0ad-4e6f-87ae-c9f55a8d4e84

(2) 2021-08-28 5:11 AM ( New account, $0 and success )
07279e40-e9d1-4491-81b6-7c4f5c712ae9

 

All the above event types are INITIAL_PURCHASE

Thanks @Kev!

The $0 transactions look legit. They have a Google receipt that validates properly, however they show a "purchaseState": 0 value.  According to the Google documentation, this means the payment is pending: https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.subscriptions. 

I also see that the old transactions (that had a price) have a "cancelReason": 2, which would indicate that  “Subscription was replaced with a new subscription “.

This seems to be just Google’s way of handling resubscribes from the same Google account. I would continue to make sure you’re honoring access even for the $0 initial purchase events. 

 

 

 

 

Thanks @Kev!

The $0 transactions look legit. They have a Google receipt that validates properly, however they show a "purchaseState": 0 value.  According to the Google documentation, this means the payment is pending: https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.subscriptions. 

I also see that the old transactions (that had a price) have a "cancelReason": 2, which would indicate that  “Subscription was replaced with a new subscription “.

This seems to be just Google’s way of handling resubscribes from the same Google account. I would continue to make sure you’re honoring access even for the $0 initial purchase events. 

 

I think in most cases user with multiple accounts shouldn’t be able to share the subscription across them. Especially if they only paid once.

Normally, I thought RC could return the receiptAlreadyInUseError or receiptInUseByOtherSubscriberError to avoid this? Why in this case I should continue to honoring the access?

I think in most cases user with multiple accounts shouldn’t be able to share the subscription across them. Especially if they only paid once.

The first purchase token is expired, so both App User IDs don’t have access, only the latest one.

 

There’s no receiptAlreadyInUseError here because they’re different purchase tokens.

 

 

So any best practices to handle such case?

Delay the subscription status when the webhook has “purchaseState: 0”?

So any best practices to handle such case?

Can you clarify the case that needs special handling? Listening to the webhook events and checking the expiration date should keep the correct subscription status in-sync with your database.

Reply


Terms & ConditionsCookie settings