Question

A recovered Android subscription was cancelled because it was not acknowledged by the API.

  • 3 October 2022
  • 2 replies
  • 72 views

Badge +2

In our testing, we tried a sandbox PurchaseProduct on Android that resulted in a code 10 network error:


"message": "Error performing request.",
"context": "PurchaseProduct",
"underlyingErrorMessage": "Hostname api.revenuecat.com not verified:\n certificate: sha1/3LiOs5Y962AdAv8grdgm7+0i67g=\n DN: CN=*.gci-mckinsey.com\n subjectAltNames: [*.gci-mckinsey.com]",
"readableErrorCode": "NetworkError",
"code": 10

 

The tester then attempted to purchase the same subscription and got a code 6 (ITEM_ALREADY_OWNED). Because of this, our app triggered a SyncPurchase, resulting in a subscribed status for the user after a few seconds.

 

However, a email was promptly sent to our tester by GooglePlay about the subscription being cancelled as in that scenario, no acknowledgement had apparently been sent by Revenue Cat.

 

So apart from the network issue, the concern for us is that recovered transactions are not acknowledged by the API. If it can help debug, the UserID is DBE441C2AD27727E

 

To try to mitigate this issue, we plan to now do an Android Restore when receiving a network error on a PurchaseProduct. Especially since we can expect a callback in that case (SyncPurchase is a simple synchronous call). Would this be enough?

Is there a better option to recover from a network error on a PurchaseProduct? What is the API retrying pattern for network errors on a PurchaseProduct?


2 replies

Userlevel 4
Badge +8

@Gabriel_Ulu 

In cases like this, calling `SyncPurchases` should solve it. `RestorePurchases` is similar, but on iOS it could trigger a prompt to log in to App Store, so we recommend tying usages of `RestorePurchases` to Restore buttons or other user actions, so the user isn’t confused about why they get the prompt. 

`SyncPurchases` should be safe to use. 

 

That being said, it would be great to identify why this issue `Hostname api.revenuecat.com not verified` is happening - it’s certainly not usual. I think I remember you showing me you were getting random SSL issues with our backend on iOS as well? Is this still true? Do you ever get that kind of issue with other domains? 

Badge +2

In cases like this, calling `SyncPurchases` should solve it. `RestorePurchases` is similar, but on iOS it could trigger a prompt to log in to App Store, so we recommend tying usages of `RestorePurchases` to Restore buttons or other user actions, so the user isn’t confused about why they get the prompt. 

`SyncPurchases` should be safe to use. 

 

In the case I described, SyncPurchases was actually called. It resulted in the account being linked to the valid subscription, as expected.

What was not expected is the early cancellation email from Apple. Because the purchase had never been acknowledged and marked as processed. E.G.: (1) It was not acknowledged on the actual transaction, likely because of the network error, and (2) was not acknowledged on the SyncPurchase either. 

 

That being said, it would be great to identify why this issue `Hostname api.revenuecat.com not verified` is happening - it’s certainly not usual. I think I remember you showing me you were getting random SSL issues with our backend on iOS as well? Is this still true? Do you ever get that kind of issue with other domains? 

 

I agree that this is kind of a different issue and it would be great to figure it out.

I do not remember having seen a similar error outside of RevenueCat. That being said, we do have quite intricate retry patterns on all the network calls we are managing. That was why I was also asking about “if” or “how” receipt posts are retried by RevenueCat’s SDK in case of errors in such a crucial network call. 

We do get SSL errors on iOS along those lines:

	"underlyingErrorMessage": "An SSL error has occurred and a secure connection to the server cannot be made.",
"message": "Error performing request.",
"readableErrorCode": "NETWORK_ERROR",
"code": 10

On both Android and iOS, these errors do not tend to repro for very long. This is why the crucial part of this thread is about ways to recover from this kind of errors.

 

Reply