React-native-iap: iOS 14: requestSubscription() issues

Created on 20 Sep 2020  ·  57Comments  ·  Source: dooboolab/react-native-iap

Version of react-native-iap

4.4.9

Version of react-native

.62.2

Platforms you faced the error (IOS or Android or both?)

iOS only. Not testing on Android yet.

Expected behavior

Purchase dialog pops up to complete buy and then purchaseUpdatedListener called.

Actual behavior

call requestSubscription(). No purchase dialogs. PurchaseUpdatedListener called immediately with no purchase dialogs or valid receipt.

Tested environment (Emulator? Real Device?)

Real iOS 14 device using TestFlight.

Steps to reproduce the behavior

call RNIap.requestSubscription().

Notes:

  • XCode 12
  • using Sign In with Apple Id.
  • testing in sandbox with real Apple id (not test user)
  • works fine on iPad running iOS 13.7.
  • have applied iOS 14 promise fix.
🍚 need contribution 📱 iOS 🙏 help wanted

Most helpful comment

Here just to say that I'm facing the same problem. I already tested on iOS 12 and it's working nicely... iOS 14 is buggy.

My call of requestSubscription just last forever... And it's bugging in production!

All 57 comments

Same here. Any one can helps?

Not hanging, but returns []

For us the purchase dialog shows, and the purchase listener gets called correctly, but the requestSubscription call returns a promise that is never resolved.

Seems like this might have been resolved here https://github.com/dooboolab/react-native-iap/pull/1064

I applied that promise fix previously, so that's not the problem here.

Works for me with iOS14, here's how I did it:
// request purchase, listener registered above will receive notification when processing done RNIap.requestSubscription(this.productIds[0]).catch(err => { console.log(err.code, err.message); });

I was calling the method with the boolean parameter false, which I think is the recommendation. I removed that and am still seeing very strange behavior on iOS14 no matter how I call the method, and it works fine on an iPhone and iPad running iOS 13 via TestFlight. I tested requestSubscription with and without the boolean and I am never getting the purchase dialogs on iOS 14. Now most times it calls RequestUpdatedListener immediately with what looks like an invalid receipt.

Are there others who are having no problems with their subscriptions in iOS14 and xCode 12 using TestFlight?

Hey, do you any of you use getPurchaseHistory() or getAvailablePurchases() just before requestSubscription()? if so, this seem to be the problem on iOS 14.

I do getAvailablePurchases() earlier in the flow - on app load, the screen right before my Subscription Screen.

yeah, unfortunately this seem to be a bug in iOS 14. No fault of this plugin. I've checked in native code and it is the same issue.

That was the problem. I removed the call to getAvailablePurchases() and the purchase popups occurred and purchase was successful. Regrettably, I need to make that call to getAvailablePurchases, since I check the status of their subscription on App Load. So looks like we need to wait for a iOS 14 patch to fix this? Nothing else anyone can do? By the way, thank you so much theDev23!

You're welcome, the-dut. Your best bet is probably relying on a server-based check.

I was hoping to avoid having a server do this. Is it as easy as copying the code from my react into something like a Firebase Cloud Function? Or is this something that needs to be re-architectured? Probably a dumb question, but hey.. we all started out asking dumb questions. :)

@the-dut You can use iaphub to take care of the server receipt validation

Beverage of your choice if you're ever in the Midwest US. :)

Same issue here affecting live users. @theDev23 do you happen to have a link any discussions about the issue in iOS? Are there any timelines for a fix?

@nicknjpconsultingllc no link, sorry. I did the digging myself.

@the-dut I am using Firebase Cloud Functions as well. Check out this repo.

I ended up saving the receipt to a database on successful purchase in the purchaseUpdatedListener, then on app load I pull the receipt from the database, validate it again and check to see if it's expired or not. That allowed me to get rid of the call to getAvailablePurchases() is it works great in iOS14. It's worked really well so far and is much faster. Now a question on how far I need to take this. If this is all I do, will the UpdatedPurchaseListener get called on all updates to the subscription (basically the auto-renewals) until I finish the transactions? Or do I need to implement the server-to-server notifications to get informed of the auto-renewals? It almost seems like using the UpdatedPurchaseListener is a better (and simpler) solution since I have been reading the server-to-server integration isn't perfect.

Still getting this issue after removing getPurchaseHistory and applying the promise fix. Can't get to make the purchase dialog pop up. Can anybody help?

I'd say take a look at any/all calls you are making to AIP before doing the request to purchase. Are you calling getAvailablePurchases() as well?

I can't exclude the calls to getAvailablePurchases() and getPurchaseHistory(), is there anyway to make it requestSubscription() pop up the purchase menu with these calls?

Hi @HamzaIkram2727 , if I am not wrong, you can just create a new sandbox account to use and delete the old one. It should works.

@the-dut Even I am not using any getAvailablePurchases() and getPurchaseHistory() calls, still i am facing same problem. It does not show purchase dialog but purchased sucess automatically.

I am also calling finishTrsanactionIOS and finishTransation functions

I managed to get the iOS native purchase dialog by exiting the app. This looks to me like some promises finally resolved. I'm not sure if there's any promise dependencies in react-native-iap but the behavior seems weird. Calling requestSubscription resolves in the app but there's no dialog until I exit the app.

I'm having the same problem with getAvailblePruchases(), most of the times the promise does not resolve or reject. It started happening when testing on iOS 14 devices.

I'm having the same problem

  1. I call getAvailablePurchases()
  2. requestSubscription()

I removed getAvailablePurchase and apparently it works fine

Any updates?

Really weird behaviour and for what I'm noticing it is not only on the ios 14 that it happens... I'm contacting apple to try to understand what's going on coz I don't think it's a problem related with the package it self.

Here just to say that I'm facing the same problem. I already tested on iOS 12 and it's working nicely... iOS 14 is buggy.

My call of requestSubscription just last forever... And it's bugging in production!

Well, after a day of "having fun" this is what I've concluded so far... I have various devices on different OS versions and I have this problem on each one of them. I've contacted Apple in regards to this and we're still following up the case, however, without any solid conclusions. I do not believe it is a problem with the package, it must be something on the Apple's side. I've tried everything people are mentioning on this thread and in other threads that have reported a similar problem. The In App Purchase dialog is just inconsistent on showing up and until now, I cannot find a valid reason for it because the outcome are always different. Sometimes I get an E_UNKNOWN error, other times I get zero feedback, sometimes the pop up shows after 10 mins of waiting and other times it just works... I've tried with sandbox users, non sandbox users, I've had the same different outcomes for the same user and device and not even an error or a conclusive/insightful log is shown. This is just frustrating to debug because you can't find pretty much anything... Well, if you guys have any sort of advice or insight, I'm listening ... In the meantime, if I have some news from Apple, I'll keep you posted...
P.S EDIT. after reading the last comment, one thing is consistent and I can confirm it, on iOS 14 the thing seems more inconsistent even though it happens on every OS version that I've tested this (12, 13.7, 14). However, I'm still with the impression that the problem is not solely related the OS version and that's why I'm thinking that it must be something with the Sandbox server or any other thing in the Apple's end ..

We have tested our app package with an App Store approved build and it looks like the inconsistency comes more prominently on iOS version 14+

Our conclusion is that the way Apple verifies the receipt on iOS 14+ is a bit different.

It happens with accounts that have already made purchases

  1. Create a new account in Sandbox
  2. Make a purchase (it works fine because the restorePurchases has no purchases)
  3. Wait until it expires.
  4. Buy again. (Now the restore purchases responds an object and the popup to confirm the purchase no longer works)

It's weird. I was reviewing library code and I added some logs for test. And i got the following

  1. When restorePurchases is called. It run the listener "paymentQueueRestoreCompletedTransactionsFinished"
-(void)paymentQueueRestoreCompletedTransactionsFinished:(SKPaymentQueue *)queue {  ////////   RESTORE
    NSLog(@"\n\n\n  paymentQueueRestoreCompletedTransactionsFinished  \n\n.");
    NSMutableArray* items = [NSMutableArray arrayWithCapacity:queue.transactions.count];
    NSLog(@"Number of items in my array is: %d", [queue.transactions count]);//this will return (5)

    for(SKPaymentTransaction *transaction in queue.transactions) {
        if(transaction.transactionState == SKPaymentTransactionStateRestored
           || transaction.transactionState == SKPaymentTransactionStatePurchased) {
            [self getPurchaseData:transaction withBlock:^(NSDictionary *restored) {
                [items addObject:restored];
                [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
            }];
        }
    }
    NSLog(@"\n  finished paymentQueueRestoreCompletedTransactionsFinished ");

    [self resolvePromisesForKey:@"availableItems" value:items];
}

Here I print in log the transactions size and I got 23 items

  1. The function paymentQueue is executed to finish the restore transactions
case SKPaymentTransactionStateRestored: {
          NSLog(@"Restored ");

         NSLog(@"\n  paymentQueue transaction : %@", transaction.transactionDate);
         [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
           break;
  }
  1. resolvePromisesForKey complete the restorePurchase

  2. requestSubscription start calling the function buyProduct

  3. Here I added logs for see the log
 NSLog(@"\n  produc purchase : %@", product);

  SKMutablePayment *payment = [SKMutablePayment paymentWithProduct:product];

  NSLog(@"\n  payment buy product : %@", payment.productIdentifier);

  [[SKPaymentQueue defaultQueue] addPayment:payment];
  1. I got the following log:
    a) RestorePurchases log
2020-10-22 14:01:49.319677-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.319784-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 16:46:53 2020
2020-10-22 14:01:49.319930-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.319970-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:16:45 2020
2020-10-22 14:01:49.320044-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320082-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:06:37 2020
2020-10-22 14:01:49.320155-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320275-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:01:37 2020
2020-10-22 14:01:49.320421-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320532-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:49:31 2020
2020-10-22 14:01:49.320671-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.320776-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:21:39 2020
2020-10-22 14:01:49.320915-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321018-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:26:39 2020
2020-10-22 14:01:49.321180-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321282-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 16:56:53 2020
2020-10-22 14:01:49.321414-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321516-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 16:51:53 2020
2020-10-22 14:01:49.321648-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321749-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 08:04:31 2020
2020-10-22 14:01:49.321879-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.321984-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:11:41 2020
2020-10-22 14:01:49.322113-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.322214-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 16:41:53 2020
2020-10-22 14:01:49.322346-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.322444-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:31:39 2020
2020-10-22 14:01:49.323955-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324097-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 12:07:14 2020
2020-10-22 14:01:49.324240-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324344-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:16:39 2020
2020-10-22 14:01:49.324474-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324579-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:11:39 2020
2020-10-22 14:01:49.324709-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.324808-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:39:31 2020
2020-10-22 14:01:49.324934-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.325030-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:59:31 2020
2020-10-22 14:01:49.325163-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.325260-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:26:45 2020
2020-10-22 14:01:49.327079-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327212-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:44:31 2020
2020-10-22 14:01:49.327360-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327465-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 07:54:31 2020
2020-10-22 14:01:49.327594-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327695-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 14:37:11 2020
2020-10-22 14:01:49.327823-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:49.327923-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:21:45 2020
2020-10-22 14:01:49.328099-0500 ApplicationTest[532:51039] 

  paymentQueueRestoreCompletedTransactionsFinished  

2020-10-22 14:01:49.328204-0500 ApplicationTest[532:51039] Number of items in my array is: 23
2020-10-22 14:01:49.336873-0500 ApplicationTest[532:51039] 
  finished paymentQueueRestoreCompletedTransactionsFinished
2020-10-22 14:01:50.317721-0500 ApplicationTest[532:51234] 

b. buySubcription log:

2020-10-22 14:01:50.319607-0500 ApplicationTest[532:51234] 
  produc purchase : <SKProduct: 0x2839c0630>

2020-10-22 14:01:50.319694-0500 ApplicationTest[532:51234] 
  payment buy product : test.applicationtest

**2020-10-22 14:01:50.319849-0500 ApplicationTest[532:51039] Restored
2020-10-22 14:01:50.319895-0500 ApplicationTest[532:51039] 
  paymentQueue transaction : Mon Oct  5 19:16:45 2020**

So I don't understand why the paymentQueue method is executed with a SKPaymentTransactionStateRestored dated October 5

@andresordonezfm Have you called finishTransaction after the purchase?

Also regarding the pop-ups, here are great trials given in #863. Hope it helps.

@andresordonezfm Have you called finishTransaction after the purchase?

Sure! also I called clearTransactionIOS() anyway if it could be the problem but nothing.

Also regarding the pop-ups, here are great trials given in #863. Hope it helps.

Thank you. I gonna review-it

Any solutions/updates?

Nothing yet. I was reviewing and Apple added new features in StoreKit and Notification Types..
I'm not sure if that could be the problem

https://developer.apple.com/videos/play/wwdc2020/10661/

i did downgrade the package to 4.5.2 worked for me
check if you're calling
await RNIap.initConnection();
before RNIap.requestSubscription

Seems I solved following this issue:
https://github.com/dooboolab/react-native-iap/issues/1146

First of all, when I was validate the receipt I was passing true as isTest parameter (even when was a production build).
Then I added RNIap.clearTransactionIOS(); in the purchaseUpdatedListener before validating the receipt and RNIap.finishTransaction(purchase, false) after RNIap.finishTransactionIOS(purchase.transactionId);

I tested in TestFlight and I could complete a purchase for the first time (with a sandbox account), now I going to test it in production 🤞

Seems I solved following this issue:

1146

First of all, when I was validate the receipt I was passing true as isTest parameter (even when was a production build).
Then I added RNIap.clearTransactionIOS(); in the purchaseUpdatedListener before validating the receipt and RNIap.finishTransaction(purchase, false) after RNIap.finishTransactionIOS(purchase.transactionId);

I tested in TestFlight and I could complete a purchase for the first time (with a sandbox account), now I going to test it in production 🤞

Hi dude I tried this solution but not worked for me.

I'm running into the same issue. It happens when you try purchasing subscription after restoring purchase.

I can confirm logs from @andresordonezfm , where it seems that SKPaymentQueue receives transaction of the SKPaymentTransactionStateRestored type , instead of the SKPaymentTransactionStatePurchasing type, which is the reason for the "Restore" string being logged on purchase.

Hi Guys sorry for the delay.

I was reviewing and I found a solution for this problem. The problem is that before calling the restore purchases, the newly opened transactions of the same restore purchases do not close properly. Then I forcibly close them.

Then the clearTransactionIOS function of the library, the promise must be added to wait for the transactions to be closed using the function removedTransactions

Here is my code:

File: react-native-iap/ios/RNIapIos.m

  1. Replace the function RCT_EXPORT_METHOD(clearTransaction) with the following code
RCT_EXPORT_METHOD(clearTransaction:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject) {  

    NSLog(@"\n\n\n  ***  clear remaining Transactions. Call this before make a new transaction   \n\n.");

    NSArray *pendingTrans = [[SKPaymentQueue defaultQueue] transactions];
    countPendingTransaction = (NSInteger)(pendingTrans.count);

    if (countPendingTransaction > 0) {
        [self addPromiseForKey:@"cleaningTransactions" resolve:resolve reject:reject];

        for (SKPaymentTransaction *transaction in pendingTrans) {
            [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
        }

    } else {
        resolve(nil);
    }
}
  1. Add the following new function (I added this function at the end of the RNIapIos.m file. Before the line "@end" )
-(void)paymentQueue:(SKPaymentQueue *)queue removedTransactions:(NSArray *)transactions {
    NSLog(@"removedTransactions");
    if (countPendingTransaction != nil && countPendingTransaction > 0) {
        countPendingTransaction--;
        if (countPendingTransaction == 0) {
            [self resolvePromisesForKey:@"cleaningTransactions" value:nil];
            countPendingTransaction = nil;
        }
    }
}

File: react-native-iap/ios/RNIapIos.h

  1. Under the code "SKProduct * promotedProduct;" add the following line
  NSInteger countPendingTransaction;

Finally before calling the "RNIap.requestSubscription (productId, false)" function.
The clearTransactionIOS function must be called, for example:

    if (Platform.OS === 'ios') {
      await RNIap.clearTransactionIOS();
    }
    await RNIap.requestSubscription(productId, false);

I hope it helps. The strange behavior of restore purchases I have not been able to find the reason. But this solved for me testing in Sandbox.

If you have any suggestions please let me know.

I also have this problem,please author,help me ,thank your family

I also have this problem,please author,help me ,thank your family

Hi dude, In the previous comment, the steps I did to solve it are explained

If you have any comments, let me know

@andresordonezfm would you be willing to create a PR for these changes?

For the issue of purchases coming as SKPaymentTransactionStateRestored that happens after restoring, I created a new account and made a few purchases and it's not happening for that account. I'm able to call RNIap.getAvailablePurchases() and RNIap.requestSubscription() afterwards.

It seems that it may be related with the amount of purchases a user has? I haven't run any tests on production yet.

Well, after a day of "having fun" this is what I've concluded so far... I have various devices on different OS versions and I have this problem on each one of them. I've contacted Apple in regards to this and we're still following up the case, however, without any solid conclusions. I do not believe it is a problem with the package, it must be something on the Apple's side. I've tried everything people are mentioning on this thread and in other threads that have reported a similar problem. The In App Purchase dialog is just inconsistent on showing up and until now, I cannot find a valid reason for it because the outcome are always different. Sometimes I get an E_UNKNOWN error, other times I get zero feedback, sometimes the pop up shows after 10 mins of waiting and other times it just works... I've tried with sandbox users, non sandbox users, I've had the same different outcomes for the same user and device and not even an error or a conclusive/insightful log is shown. This is just frustrating to debug because you can't find pretty much anything... Well, if you guys have any sort of advice or insight, I'm listening ... In the meantime, if I have some news from Apple, I'll keep you posted...
P.S EDIT. after reading the last comment, one thing is consistent and I can confirm it, on iOS 14 the thing seems more inconsistent even though it happens on every OS version that I've tested this (12, 13.7, 14). However, I'm still with the impression that the problem is not solely related the OS version and that's why I'm thinking that it must be something with the Sandbox server or any other thing in the Apple's end ..

Exactly what I'm experiencing on my end, even after the fix suggested by @andresordonezfm (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-734805587). @106firestarter, did Apple ever reply?

I'll see what I can find in the developer forums meanwhile.

For the issue of purchases coming as SKPaymentTransactionStateRestored that happens after restoring, I created a new account and made a few purchases and it's not happening for that account. I'm able to call RNIap.getAvailablePurchases() and RNIap.requestSubscription() afterwards.

It seems that it may be related with the amount of purchases a user has? I haven't run any tests on production yet.

I'll try that, but production is a concern as well, indeed.

For the record, I'm also calling getAvailablePurchases() before requestSubscription().

I can confirm as well that with a brand new account the issue is no longer as @Paduado stated (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-742685043).

Correction: using a brand new account together with the fix suggested by @andresordonezfm makes it work on my end. Without the fix, after the very first subscription, the same behavior I was experiencing before emerges again and I can no longer subscribe again. One more thing I noticed after applying the fix is that subscriptions appear to no longer auto-renew automatically, not even once, although using sandbox they are expected to renew 5 times.

@andresordonezfm would you be willing to create a PR for these changes?

Hi, dude sorry for the delay again. I created a pull request to react-native iap

~I can confirm as well that with a brand new account the issue is no longer as @Paduado stated (#1120 (comment)).~

Correction: using a brand new account together with the fix suggested by @andresordonezfm makes it work on my end. Without the fix, after the very first subscription, the same behavior I was experiencing before emerges again and I can no longer subscribe again. One more thing I noticed after applying the fix is that subscriptions appear to no longer auto-renew automatically, not even once, although using sandbox they are expected to renew 5 times.

Hi dude I think it is a sandbox problem. Do you keep giving that behavior?

@andresordonezfm yes, I too suspect it is an issue with Apple's sandbox. I didn't perform any more tests since my last comment and I'm yet to check production. However, to date, I didn't receive any complaints from customers.

The sandbox appears to be back on track on my end when using a brand new account, as previous reported by @Paduado, without any making any changes to the code. 🤷‍♂️ 😕

@andresordonezfm I encountered the same thing and your patch seams to fix it. However, I think I see subtle bug in your code that could potentially cause cleartTransactionsIOS() to hang. removeTransactions may be called with 1 or more transactions to be removed. So in removeTransactions, I think we want:

        countPendingTransaction -= [transactions count];

In practice, I've only seen removedTransactions called with one transaction, but apple docs say it could be one or more. Nice find by the way! I was stuck on this for a while.

@andresordonezfm I encountered the same thing and your patch seams to fix it. However, I think I see subtle bug in your code that could potentially cause cleartTransactionsIOS() to hang. removeTransactions may be called with 1 or more transactions to be removed. So in removeTransactions, I think we want:

        countPendingTransaction -= [transactions count];

In practice, I've only seen removedTransactions called with one transaction, but apple docs say it could be one or more. Nice find by the way! I was stuck on this for a while.

Hi dude, thank you for you recommendation. I tested your propose and it works well for me. I made a pull request with that change.

Note: Yes, I reviewed that documentation but since it only is fired from transaction to transaction I did not implement it. But it is a very good recommendation. Thank you!

Was this page helpful?
0 / 5 - 0 ratings