Pareil ici. Quelqu'un peut-il aider?

Non suspendu, mais renvoie []

Pour nous, la boîte de dialogue d'achat s'affiche et l'auditeur d'achat est appelé correctement, mais l'appel requestSubscription renvoie une promesse qui n'est jamais résolue.

On dirait que cela aurait pu être résolu ici https://github.com/dooboolab/react-native-iap/pull/1064

J'ai appliqué ce correctif de promesse auparavant, donc ce n'est pas le problème ici.

Fonctionne pour moi avec iOS14, voici comment je l'ai fait:
// request purchase, listener registered above will receive notification when processing done RNIap.requestSubscription(this.productIds[0]).catch(err => { console.log(err.code, err.message); });

J'appelais la méthode avec le paramètre booléen false, ce qui, je pense, est la recommandation. J'ai supprimé cela et je constate toujours un comportement très étrange sur iOS14, peu importe comment j'appelle la méthode, et cela fonctionne bien sur un iPhone et un iPad exécutant iOS 13 via TestFlight. J'ai testé requestSubscription avec et sans le booléen et je n'obtiens jamais les dialogues d'achat sur iOS 14. Maintenant, la plupart du temps, il appelle immédiatement RequestUpdatedListener avec ce qui ressemble à un reçu invalide.

Y en a-t-il d'autres qui n'ont aucun problème avec leurs abonnements sous iOS14 et xCode 12 en utilisant TestFlight?

Hé, est-ce que l'un d'entre vous utilise getPurchaseHistory() ou getAvailablePurchases() juste avant requestSubscription() ? si tel est le cas, cela semble être le problème sur iOS 14.

Je fais getAvailablePurchases () plus tôt dans le flux - lors du chargement de l'application, l'écran juste avant mon écran d'abonnement.

ouais, malheureusement, cela semble être un bogue dans iOS 14. Aucune faute de ce plugin. J'ai vérifié le code natif et c'est le même problème.

C'était ça le problème. J'ai supprimé l'appel à getAvailablePurchases () et les fenêtres contextuelles d'achat se sont produites et l'achat a réussi. Malheureusement, je dois passer cet appel pour getAvailablePurchases, car je vérifie l'état de leur abonnement sur App Load. On dirait donc que nous devons attendre un correctif iOS 14 pour résoudre ce problème? Personne d'autre ne peut faire? Au fait, merci beaucoup theDev23!

De rien, le devoir. Votre meilleur pari repose probablement sur une vérification basée sur le serveur.

J'espérais éviter qu'un serveur fasse cela. Est-ce aussi simple que de copier le code de ma réaction dans quelque chose comme une fonction Firebase Cloud? Ou est-ce quelque chose qui doit être ré-architecturé? Probablement une question stupide, mais bon ... nous avons tous commencé à poser des questions stupides. :)

@ the-dut Vous pouvez utiliser iaphub pour prendre en charge la validation des reçus du serveur

Boisson de votre choix si vous êtes déjà dans le Midwest américain. :)

Même problème ici affectant les utilisateurs en direct. @ theDev23 avez-vous un lien pour discuter du problème sous iOS? Y a-t-il des délais pour un correctif?

@nicknjpconsultingllc pas de lien, désolé. J'ai creusé moi-même.

@ the-dut J'utilise également Firebase Cloud Functions. Découvrez ce repo .

J'ai fini par enregistrer le reçu dans une base de données lors de l'achat réussi dans purchaseUpdatedListener, puis au chargement de l'application, je tire le reçu de la base de données, le valide à nouveau et vérifie s'il a expiré ou non. Cela m'a permis de me débarrasser de l'appel à getAvailablePurchases () si cela fonctionne très bien dans iOS14. Cela a très bien fonctionné jusqu'à présent et est beaucoup plus rapide. Maintenant, une question sur jusqu'où je dois aller. Si c'est tout ce que je fais, le UpdatedPurchaseListener sera-t-il appelé sur toutes les mises à jour de l'abonnement (essentiellement les renouvellements automatiques) jusqu'à ce que je termine les transactions? Ou dois-je implémenter les notifications de serveur à serveur pour être informé des renouvellements automatiques? Il semble presque que l'utilisation de UpdatedPurchaseListener est une meilleure solution (et plus simple) puisque j'ai lu que l'intégration de serveur à serveur n'est pas parfaite.

Ce problème persiste après la suppression de getPurchaseHistory et l'application du correctif de promesse. Impossible de faire apparaître la boîte de dialogue d'achat. Quelqu'un peut-il aider?

Je dirais de jeter un oeil à tous les appels que vous faites à AIP avant de faire la demande d'achat. Appelez-vous getAvailablePurchases () également?

Je ne peux pas exclure les appels à getAvailablePurchases () et getPurchaseHistory (), y a-t-il de toute façon pour le faire requestSubscription () faire apparaître le menu d'achat avec ces appels?

Salut @ HamzaIkram2727 , si je ne me trompe pas, vous pouvez simplement créer un nouveau compte sandbox pour utiliser et supprimer l'ancien. Cela devrait fonctionner.

@ the-dut Même si je n'utilise aucun appel getAvailablePurchases () et getPurchaseHistory (), je suis toujours confronté au même problème. Il n'affiche pas la boîte de dialogue d'achat mais les achats réussis automatiquement.

J'appelle également les fonctions finishTrsanactionIOS et finishTransation

J'ai réussi à obtenir la boîte de dialogue d'achat native iOS en quittant l'application. Cela me semble que certaines promesses sont enfin résolues. Je ne sais pas s'il y a des dépendances de promesse dans react-native-iap mais le comportement semble étrange. L'appel de requestSubscription résout dans l'application mais il n'y a pas de boîte de dialogue jusqu'à ce que je quitte l'application.

J'ai le même problème avec getAvailblePruchases (), la plupart du temps, la promesse ne se résout pas ou ne rejette pas. Cela a commencé à se produire lors des tests sur les appareils iOS 14.

J'ai le même problème

1. J'appelle getAvailablePurchases ()
2. requestSubscription ()

J'ai supprimé getAvailablePurchase et apparemment cela fonctionne bien

Les mises à jour?

Comportement vraiment bizarre et pour ce que je remarque, ce n'est pas seulement sur l'ios 14 que cela se produit ... Je contacte apple pour essayer de comprendre ce qui se passe car je ne pense pas que c'est un problème lié au paquet soi.

Ici juste pour dire que je suis confronté au même problème. J'ai déjà testé sur iOS 12 et ça marche bien ... iOS 14 est bogué.

Mon appel à la demandeL'abonnement dure pour toujours ... Et ça bouge en production!

Eh bien, après une journée à "m'amuser" c'est ce que j'ai conclu jusqu'à présent ... J'ai divers appareils sur différentes versions d'OS et j'ai ce problème sur chacun d'eux. J'ai contacté Apple à ce sujet et nous continuons à suivre l'affaire, cependant, sans aucune conclusion solide. Je ne pense pas que ce soit un problème avec le package, cela doit être quelque chose du côté d'Apple. J'ai essayé tout ce que les gens mentionnent sur ce fil et dans d'autres fils qui ont signalé un problème similaire. La boîte de dialogue Achat dans l'application est tout simplement incohérente et jusqu'à présent, je ne trouve pas de raison valable car le résultat est toujours différent. Parfois, j'obtiens une erreur E_UNKNOWN, d'autres fois je n'ai aucun retour, parfois le pop-up s'affiche après 10 minutes d'attente et d'autres fois cela fonctionne juste ... J'ai essayé avec des utilisateurs de sandbox, non utilisateurs de sandbox, j'ai eu le les mêmes résultats différents pour le même utilisateur et le même appareil et même pas une erreur ou un journal concluant / perspicace. C'est juste frustrant à déboguer parce que vous ne trouvez à peu près rien ... Eh bien, si vous avez des conseils ou des idées, j'écoute ... En attendant, si j'ai des nouvelles d'Apple, Je te tiendrai au courant...
PS EDIT. après avoir lu le dernier commentaire, une chose est cohérente et je peux le confirmer, sur iOS 14 la chose semble plus incohérente même si cela se produit sur toutes les versions d'OS que j'ai testées (12, 13.7, 14). Cependant, j'ai toujours l'impression que le problème n'est pas uniquement lié à la version du système d'exploitation et c'est pourquoi je pense que cela doit être quelque chose avec le serveur Sandbox ou toute autre chose du côté d'Apple.

Nous avons testé notre package d'application avec une version approuvée par l'App Store et il semble que l'incohérence soit plus visible sur iOS version 14+

Notre conclusion est que la façon dont Apple vérifie le reçu sur iOS 14+ est un peu différente.

Cela arrive avec les comptes qui ont déjà effectué des achats

1. Créer un nouveau compte dans Sandbox
2. Faire un achat (cela fonctionne bien car la restauration des achats n'a pas d'achats)
3. Attendez qu'il expire.
4. Achetez à nouveau. (Maintenant, les achats de restauration répondent à un objet et la fenêtre contextuelle pour confirmer l'achat ne fonctionne plus)

C'est étrange. J'étais en train de réviser le code de la bibliothèque et j'ai ajouté quelques journaux pour le test. Et j'ai ce qui suit

1. Lorsque restorePurchases est appelé. Il exécute l'écouteur "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];
}

Ici, j'imprime dans le journal la taille des transactions et j'ai 23 articles

1. La fonction paymentQueue est exécutée pour terminer les transactions de restauration

case SKPaymentTransactionStateRestored: {
          NSLog(@"Restored ");

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

1. résoudrePromisesForKey terminer la restaurationPurchase

2. requestSubscription commence à appeler la fonction buyProduct

3. Ici, j'ai ajouté des journaux pour voir le journal

 NSLog(@"\n  produc purchase : %@", product);

  SKMutablePayment *payment = [SKMutablePayment paymentWithProduct:product];

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

  [[SKPaymentQueue defaultQueue] addPayment:payment];

1. J'ai le journal suivant:
   a) Journal de restauration des achats

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. buySubscription 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**

Donc je ne comprends pas pourquoi la méthode paymentQueue est exécutée avec un SKPaymentTransactionStateRestored daté du 5 octobre

@andresordonezfm Avez-vous appelé finishTransaction après l'achat?

En ce qui concerne également les pop-ups, voici de superbes essais donnés dans # 863. J'espère que ça aide.

@andresordonezfm Avez-vous appelé finishTransaction après l'achat?

Sûr! aussi j'ai appelé clearTransactionIOS () de toute façon si cela pouvait être le problème mais rien.

En ce qui concerne également les pop-ups, voici de superbes essais donnés dans # 863. J'espère que ça aide.

Merci. Je vais le revoir

Des solutions / mises à jour?

Rien pour le moment. J'étais en train de réviser et Apple a ajouté de nouvelles fonctionnalités dans StoreKit et les types de notification.
Je ne sais pas si cela pourrait être le problème

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

j'ai rétrogradé le package à 4.5.2 a fonctionné pour moi
vérifiez si vous appelez
await RNIap.initConnection();
avant RNIap.requestSubscription

Il semble que j'ai résolu ce problème:
https://github.com/dooboolab/react-native-iap/issues/1146

Tout d'abord, lorsque j'ai validé le reçu, je passais true comme paramètre isTest (même s'il s'agissait d'une version de production).
Ensuite j'ai ajouté RNIap.clearTransactionIOS(); dans le purchaseUpdatedListener avant de valider le reçu et RNIap.finishTransaction(purchase, false) après RNIap.finishTransactionIOS(purchase.transactionId);

J'ai testé en TestFlight et j'ai pu effectuer un achat pour la première fois (avec un compte sandbox), maintenant je vais le tester en production 🤞

Il semble que j'ai résolu ce problème:

1146

Tout d'abord, lorsque j'ai validé le reçu, je passais true comme paramètre isTest (même s'il s'agissait d'une version de production).
Ensuite j'ai ajouté RNIap.clearTransactionIOS(); dans le purchaseUpdatedListener avant de valider le reçu et RNIap.finishTransaction(purchase, false) après RNIap.finishTransactionIOS(purchase.transactionId);

J'ai testé en TestFlight et j'ai pu effectuer un achat pour la première fois (avec un compte sandbox), maintenant je vais le tester en production 🤞

Salut mec, j'ai essayé cette solution mais cela n'a pas fonctionné pour moi.

Je rencontre le même problème. Cela se produit lorsque vous essayez d'acheter un abonnement après avoir restauré l'achat.

Je peux confirmer les journaux de @andresordonezfm , où il semble que SKPaymentQueue reçoive une transaction de type SKPaymentTransactionStateRestored , au lieu du type SKPaymentTransactionStatePurchasing , qui est la raison de la "restauration" chaîne en cours de connexion lors de l'achat.

Salut les gars désolé pour le retard.

J'étais en train de réviser et j'ai trouvé une solution à ce problème. Le problème est qu'avant d'appeler les achats de restauration, les transactions nouvellement ouvertes des mêmes achats de restauration ne se ferment pas correctement. Puis je les ferme de force.

Puis la fonction clearTransactionIOS de la librairie, la promesse doit être ajoutée pour attendre que les transactions soient clôturées à l'aide de la fonction removeTransactions

Voici mon code:

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

1. Remplacez la fonction RCT_EXPORT_METHOD (clearTransaction) par le code suivant

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. Ajoutez la nouvelle fonction suivante (j'ai ajouté cette fonction à la fin du fichier RNIapIos.m. Avant la ligne "@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;
        }
    }
}

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

1. Sous le code "SKProduct * promuProduct;" ajouter la ligne suivante

  NSInteger countPendingTransaction;

Enfin avant d'appeler la fonction "RNIap.requestSubscription (productId, false)".
La fonction clearTransactionIOS doit être appelée, par exemple:

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

J'espère que cela aide. Le comportement étrange des achats de restauration, je n'ai pas été en mesure de trouver la raison. Mais cela a résolu pour moi de tester dans Sandbox.

Si vous avez des suggestions, s'il vous plaît faites-le moi savoir.

J'ai aussi ce problème ， s'il vous plaît auteur, aidez-moi, remerciez votre famille

J'ai aussi ce problème ， s'il vous plaît auteur, aidez-moi, remerciez votre famille

Salut mec, Dans le commentaire précédent, les étapes que j'ai suivies pour le résoudre sont expliquées

Si vous avez des commentaires, faites-le moi savoir

@andresordonezfm seriez-vous prêt à créer un PR pour ces changements?

Pour le problème des achats à venir en SKPaymentTransactionStateRestored qui se produit après la restauration, j'ai créé un nouveau compte et effectué quelques achats et cela ne se produit pas pour ce compte. Je peux appeler RNIap.getAvailablePurchases() et RNIap.requestSubscription() par la suite.

Il semble que cela puisse être lié au montant des achats d'un utilisateur? Je n'ai pas encore effectué de tests sur la production.

Eh bien, après une journée à "m'amuser" c'est ce que j'ai conclu jusqu'à présent ... J'ai divers appareils sur différentes versions d'OS et j'ai ce problème sur chacun d'eux. J'ai contacté Apple à ce sujet et nous continuons à suivre l'affaire, cependant, sans aucune conclusion solide. Je ne pense pas que ce soit un problème avec le package, cela doit être quelque chose du côté d'Apple. J'ai essayé tout ce que les gens mentionnent sur ce fil et dans d'autres fils qui ont signalé un problème similaire. La boîte de dialogue Achat dans l'application est tout simplement incohérente et jusqu'à présent, je ne trouve pas de raison valable car le résultat est toujours différent. Parfois, j'obtiens une erreur E_UNKNOWN, d'autres fois je n'ai aucun retour, parfois le pop-up s'affiche après 10 minutes d'attente et d'autres fois cela fonctionne juste ... J'ai essayé avec des utilisateurs de sandbox, non utilisateurs de sandbox, j'ai eu le les mêmes résultats différents pour le même utilisateur et le même appareil et même pas une erreur ou un journal concluant / perspicace. C'est juste frustrant à déboguer parce que vous ne trouvez à peu près rien ... Eh bien, si vous avez des conseils ou des idées, j'écoute ... En attendant, si j'ai des nouvelles d'Apple, Je te tiendrai au courant...
PS EDIT. après avoir lu le dernier commentaire, une chose est cohérente et je peux le confirmer, sur iOS 14 la chose semble plus incohérente même si cela se produit sur toutes les versions d'OS que j'ai testées (12, 13.7, 14). Cependant, j'ai toujours l'impression que le problème n'est pas uniquement lié à la version du système d'exploitation et c'est pourquoi je pense que cela doit être quelque chose avec le serveur Sandbox ou toute autre chose du côté d'Apple.

Exactement ce que je vis de mon côté, même après le correctif suggéré par @andresordonezfm (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-734805587). @ 106firestarter , Apple a-t-il déjà répondu?

Je vais voir ce que je peux trouver dans les forums des développeurs en attendant.

Pour le problème des achats à venir en SKPaymentTransactionStateRestored qui se produit après la restauration, j'ai créé un nouveau compte et effectué quelques achats et cela ne se produit pas pour ce compte. Je peux appeler RNIap.getAvailablePurchases() et RNIap.requestSubscription() par la suite.

Il semble que cela puisse être lié au montant des achats d'un utilisateur? Je n'ai pas encore effectué de tests sur la production.

Je vais essayer cela, mais la production est également un problème, en effet.

Pour mémoire, j'appelle également getAvailablePurchases() avant requestSubscription() .

Peut-être lié:

• https://developer.apple.com/forums/thread/669435

Je peux également confirmer qu'avec un tout nouveau compte, le problème n'est plus comme l' a déclaré

Correction: l'utilisation d'un tout nouveau compte avec le correctif suggéré par @andresordonezfm le fait fonctionner de mon côté. Sans le correctif, après le tout premier abonnement, le même comportement que je connaissais avant réapparaît et je ne peux plus m'abonner à nouveau. Une autre chose que j'ai remarquée après avoir appliqué le correctif est que les abonnements semblent ne plus se renouveler automatiquement, pas même une fois, bien qu'en utilisant le bac à sable, ils devraient se renouveler 5 fois.

@andresordonezfm seriez-vous prêt à créer un PR pour ces changements?

Salut, mec désolé pour le retard encore. J'ai créé une pull request pour réactiver l'iap natif

~ Je peux également confirmer qu'avec un tout nouveau compte, le problème n'est plus comme l' a déclaré # 1120 (commentaire) ). ~

Correction: l'utilisation d'un tout nouveau compte avec le correctif suggéré par @andresordonezfm le fait fonctionner de mon côté. Sans le correctif, après le tout premier abonnement, le même comportement que je connaissais avant réapparaît et je ne peux plus m'abonner à nouveau. Une autre chose que j'ai remarquée après avoir appliqué le correctif est que les abonnements semblent ne plus se renouveler automatiquement, pas même une fois, bien qu'en utilisant le bac à sable, ils devraient se renouveler 5 fois.

Salut mec, je pense que c'est un problème de bac à sable. Continuez-vous à donner ce comportement?

@andresordonezfm oui, je soupçonne moi aussi que c'est un problème avec le bac à sable d'Apple. Je n'ai plus effectué de tests depuis mon dernier commentaire et je n'ai pas encore vérifié la production. Cependant, à ce jour, je n'ai reçu aucune plainte de clients.

Le bac à sable semble être de retour sur la bonne voie de mon côté lors de l'utilisation d'un tout nouveau compte, comme indiqué précédemment par @Paduado , sans aucune modification du code. 🤷‍♂️ 😕

@andresordonezfm J'ai rencontré la même chose et vos coutures de patch pour le réparer. Cependant, je pense que je vois un bug subtil dans votre code qui pourrait potentiellement provoquer le blocage de cleartTransactionsIOS() . removeTransactions peut être appelé avec une ou plusieurs transactions à supprimer. Donc dans removeTransactions , je pense que nous voulons:

        countPendingTransaction -= [transactions count];

Dans la pratique, je n'ai vu que des appels de removedTransactions avec une seule transaction, mais les documents Apple indiquent qu'il peut s'agir d'une ou de plusieurs. Belle trouvaille au fait! J'étais coincé là-dessus pendant un moment.

@andresordonezfm J'ai rencontré la même chose et vos coutures de patch pour le réparer. Cependant, je pense que je vois un bug subtil dans votre code qui pourrait potentiellement provoquer le blocage de cleartTransactionsIOS() . removeTransactions peut être appelé avec une ou plusieurs transactions à supprimer. Donc dans removeTransactions , je pense que nous voulons:

        countPendingTransaction -= [transactions count];

Dans la pratique, je n'ai vu que des appels de removedTransactions avec une seule transaction, mais les documents Apple indiquent qu'il peut s'agir d'une ou de plusieurs. Belle trouvaille au fait! J'étais coincé là-dessus pendant un moment.

Salut mec, merci pour votre recommandation. J'ai testé votre proposition et cela fonctionne bien pour moi. J'ai fait une pull request avec ce changement.

Remarque: Oui, j'ai examiné cette documentation, mais comme elle n'est déclenchée que d'une transaction à l'autre, je ne l'ai pas implémentée. Mais c'est une très bonne recommandation. Merci!