-
-
Notifications
You must be signed in to change notification settings - Fork 655
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error when upgrade/downgrade subscription on Android with DEFERRED mode #888
Comments
Try to call I am not quite sure tough hope it helps. Please feel free to leave any other trials and discussions. |
I tried getAvailablePurchases() after upgrade/downgrade the subscription, but unfortunately, only the transaction receipt of original purchase is in the returned array. RNIap v2.3.19 & v2.5.5 works correctly, buySubscription() will return a new receipt when upgrade/downgrade the subscription. But I would like to upgrade to v3 or v4 which has a better event based model if possible. Here is a reference document which explains how Android subscription upgrade/downgrade works and why we need the new receipt after upgrade/downgrade. |
@howg0924 Thanks for confirming this. I'd like to compare the differences with v2 and our current version and see how I can fix this issue. |
I've looked up the code on the weekend for you in #893 Could you kindly test |
@hyochan I just tried 4.4.0-rc.1, but the situation is still the same. After calling RNIap.requestSubscription(oldSku, false, newSku 4) and finish the upgrade/downgrade, error listener is called with following error: { message: 'purchases are null.', And getAvailablePurchases() only contains old receipt. |
@howg0924 If you know how to debug |
@howg0924 Oh wait~! I think I found the problem let me get back to you soon! |
@howg0924 Could you try |
@hyochan 4.4.0-rc.2 build failed on:
|
@hyochan I monitored buyItemByType() of 4.4.0-rc.1. When upgrade/downgrade, it did execute:
and also executed:
Do you want me to monitor/dump any flow/data? |
(removed due to some misunderstanding) |
@howg0924 Sorry that I've made mistake because I did not have a good debugging |
After compare with 2.5.5, I found 2.5.5 does not call builder.setReplaceSkusProrationMode(BillingFlowParams.ProrationMode.DEFERRED); when using the DEFERRED mode. So I try to remove this line on 4.4.0-rc.1, and it works! But, I don't know: 1.what proration mode it is working on now. |
We are currently passing down the |
I mean if I change code to:
then I can use RNIap.requestSubscription(newSku, false, sku, 4 /* DEFERRED mode */) to upgrade/downgrade a subscription. Though I am not sure what proration mode it actually works on since builder.setReplaceSkusProrationMode() is not executed, as v2.5.5 did. Following code is from v2.5.5:
|
@howg0924 Well this is very strange since we did not even set I think the reason might be something different. I hope you can come back if there is some other news. |
OK, I will try more and report back. Related #707 |
@hyochan After further test on 4.4.0-rc.1: IMMEDIATE_WITH_TIME_PRORATION => works
I believe this is because of the following code in 4.3.0 still set it to DEFERRED mode:
However, above code does not exist on 2.3.19 & 2.5.5. Therefore, when I called RNIap.requestSubscription(newSku, false, sku, 4 /* DEFERRED */) on 2.3.19 & 2.5.5, I thought it worked before, but now I realized it actually worked on the default IMMEDIATE_WITH_TIME_PRORATION mode. |
Ok so we should know why the Deffered won't work. I couldn't find the reason for now. |
* Update requestionSubscription code on android side * Support ProrationModesAndroid enum type for handling better proration mode * Fetch oldSku detail properly - Fixes for #888 * Revert setting wrong oldSku * Simplify oldSku null check * Ensure connection for acknowledgement call (#895) (#896) * Ensure connection in acknowledgePurchase() * Resolve #898 * Just check oldSku nullable Co-authored-by: Niklas Kors <niklas@relive.cc>
I've got the same issue but behavior is different. When I call Happens on both version |
Last time I've found this issue either. It strangely doesn't work only in |
Hi @howg0924, did you get a solution for this issue yet? |
@nenjamin2405 No, I am still using the default IMMEDIATE_WITH_TIME_PRORATION mode, and I really hope this could be fixed. |
Hi @hyochan, any update on this? My app's new feature is stuck by this issue. Really appreciate your effort in investigating this, thanks |
Not yet. I've not had time to go over this issue. |
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "For Discussion" or "Good first issue" and I will leave it open. Thank you for your contributions. |
We've been looking at this issue and wanted to share with the community, it may help some people out there. The issue is due to the purchase updated listener being called with a empty list of purchases on a deferred subscription replace, which is how Android works (See here here "For the deferred replacement mode...") We added the support of android deferred subscription replace on react-native-iaphub by doing a fix looking when the error listener is called with the Of course you'll have to do some modifications on your server side validating your receipts as well, refreshing the receipt isn't enough when dealing with deferred subscriptions. Or you can just use IAPHUB which is doing all of that for you 🙂 |
Any plans to resolve this issue? |
As @iaphub mentions, the issue is that From google docs:
So it's just a matter of handling that case inside that listener. But I'm uncertain about what should be the proper way of handling that situation:
What do you think? |
Hi @Paduado do you find a good solution ? |
Not really @Patzelly, like I said the issue is happening because the way Android handles deferred purchases was not considered on the React Native API. Correctly handling this will be a breaking change on the API, I think any of the options I mentioned would work but I would like to have the input of any of the maintainers. For now my JS code looks something like this: try {
await RNIap.requestSubscription(
productId,
false,
lastPurchase.productId,
lastPurchase.purchaseToken,
ProrationModesAndroid.DEFERRED,
);
} catch (e) {
if (e.code === 'OK' && !e.message && e.responseCode === 0)) {
return 'success';
}
throw e;
} |
As described in the issue below, when requested `proration mode` with `deferred`, purchases can be `null`. Handle this case in the event to know that this was successful. Resolve #888
@hyochan Yes that would solve it 👌 , but I think that the type definition for the returned value of |
@Paduado I hope you can create a PR for that. I would like to give i the credit. |
For completeness: #1387 |
Version of react-native-iap
4.3.3
Version of react-native
0.59.10
Platforms you faced the error (IOS or Android or both?)
Android
Expected behavior
When upgrade/downgrade a subscription with DEFERRED mode, purchase update listener should be called with new transaction receipt.
Actual behavior
purchase error listener is called with following error:
{ message: 'purchases are null.',
code: 'OK',
debugMessage: '',
responseCode: 0 }
Tested environment (Emulator? Real Device?)
Real Device - sandbox
Steps to reproduce the behavior
1.Purchase a subscription with RNIap.requestSubscription(sku), this works correctly.
2.Upgrade or downgrade the subscription with RNIap.requestSubscription(newSku, false, sku, 4). (4 is the DEFERRED Proration Mode) Google Play billing dialog will show the subscription plan is changed successfully, and you will receive a notification email from Google Play about that. However, the error listener is called with the above mentioned error.
3.If you call RNIap.requestSubscription(newSku, false, sku, 4) again, Google Play billing dialog will say they cannot change the subscription plan, and the error listener is called with the following error:
{ message: 'Google is indicating that we have some issue connecting to payment.',
code: 'E_DEVELOPER_ERROR',
debugMessage: '',
responseCode: 5 }
But sometimes Google Play billing dialog will say your order is under processing and your product should be delivered soon, and the error listener is called with the following error:
{ message: 'You already own this item.',
code: 'E_ALREADY_OWNED',
debugMessage: '',
responseCode: 7 }
I guess this is due to the transaction of step 2 is waiting to be acknowledged. However, since step 2 does not return a receipt, we cannot acknowledge it.
The text was updated successfully, but these errors were encountered: