Hier gilt das gleiche. Kann jemand helfen?

Nicht hängen, sondern []

Für uns wird der Kaufdialog angezeigt und der Kauf-Listener wird korrekt angerufen, aber der Aufruf von requestSubscription gibt ein Versprechen zurück, das niemals gelöst wird.

Dies scheint hier behoben worden zu sein: https://github.com/dooboolab/react-native-iap/pull/1064

Ich habe dieses Versprechen bereits angewendet, daher ist das hier nicht das Problem.

Funktioniert für mich mit iOS14. So habe ich es gemacht:
// request purchase, listener registered above will receive notification when processing done RNIap.requestSubscription(this.productIds[0]).catch(err => { console.log(err.code, err.message); });

Ich habe die Methode mit dem booleschen Parameter false aufgerufen, was meiner Meinung nach die Empfehlung ist. Ich habe das entfernt und sehe immer noch ein sehr seltsames Verhalten unter iOS14, egal wie ich die Methode aufrufe, und es funktioniert gut auf einem iPhone und iPad, auf dem iOS 13 über TestFlight ausgeführt wird. Ich habe requestSubscription mit und ohne Booleschen Wert getestet und erhalte unter iOS 14 nie die Kaufdialoge. Jetzt wird RequestUpdatedListener meistens sofort mit einer ungültigen Quittung aufgerufen.

Gibt es andere, die keine Probleme mit ihren Abonnements in iOS14 und xCode 12 mit TestFlight haben?

Hey, benutzt einer von euch getPurchaseHistory() oder getAvailablePurchases() kurz vor requestSubscription() ? Wenn ja, scheint dies das Problem unter iOS 14 zu sein.

Ich bekomme getAvailablePurchases () früher im Ablauf - beim Laden der App den Bildschirm direkt vor meinem Abonnementbildschirm.

Ja, leider scheint dies ein Fehler in iOS 14 zu sein. Kein Fehler dieses Plugins. Ich habe nativen Code eingecheckt und es ist das gleiche Problem.

Das war das Problem. Ich habe den Aufruf von getAvailablePurchases () entfernt und die Kauf-Popups sind aufgetreten und der Kauf war erfolgreich. Leider muss ich diesen Anruf bei getAvailablePurchases tätigen, da ich den Status ihres Abonnements beim Laden der App überprüfe. Sieht also so aus, als müssten wir auf einen iOS 14-Patch warten, um dies zu beheben? Nichts anderes kann jemand tun? Übrigens, vielen Dank theDev23!

Gern geschehen, the-dut. Ihre beste Wette ist wahrscheinlich eine serverbasierte Prüfung.

Ich hatte gehofft, dies nicht von einem Server ausführen zu lassen. Ist es so einfach wie das Kopieren des Codes aus meiner Reaktion in eine Firebase Cloud-Funktion? Oder muss das neu strukturiert werden? Wahrscheinlich eine dumme Frage, aber hey ... wir haben alle angefangen, dumme Fragen zu stellen. :) :)

@ the-dut Mit iaphub können Sie die

Getränk Ihrer Wahl, wenn Sie jemals im Mittleren Westen der USA sind. :) :)

Das gleiche Problem betrifft hier Live-Benutzer. @ theDev23 Haben Sie zufällig einen Link zu Diskussionen über das Problem in iOS? Gibt es Zeitpläne für eine Korrektur?

@nicknjpconsultingllc kein Link, sorry. Ich habe selbst gegraben.

@ the-dut Ich verwende auch Firebase Cloud-Funktionen. Schauen Sie sich dieses Repo an .

Beim erfolgreichen Kauf im purchaseUpdatedListener habe ich die Quittung in einer Datenbank gespeichert. Beim Laden der App ziehe ich die Quittung aus der Datenbank, validiere sie erneut und überprüfe, ob sie abgelaufen ist oder nicht. Dadurch konnte ich den Aufruf von getAvailablePurchases () loswerden, da er in iOS14 hervorragend funktioniert. Es hat bisher sehr gut funktioniert und ist viel schneller. Nun eine Frage, wie weit ich das bringen muss. Wenn dies alles ist, wird der UpdatedPurchaseListener bei allen Aktualisierungen des Abonnements (im Grunde die automatische Verlängerung) aufgerufen, bis ich die Transaktionen abgeschlossen habe? Oder muss ich die Server-zu-Server-Benachrichtigungen implementieren, um über die automatische Verlängerung informiert zu werden? Es scheint fast so, als wäre die Verwendung des UpdatedPurchaseListener eine bessere (und einfachere) Lösung, da ich gelesen habe, dass die Server-zu-Server-Integration nicht perfekt ist.

Dieses Problem tritt immer noch auf, nachdem getPurchaseHistory entfernt und das Versprechen behoben wurde. Der Kaufdialog wird nicht angezeigt. Kann jemand helfen?

Ich würde sagen, werfen Sie einen Blick auf alle Anrufe, die Sie bei AIP tätigen, bevor Sie die Kaufanfrage stellen. Rufen Sie auch getAvailablePurchases () auf?

Ich kann die Aufrufe von getAvailablePurchases () und getPurchaseHistory () nicht ausschließen. Gibt es eine Möglichkeit, requestSubscription () mit diesen Aufrufen im Kaufmenü aufzurufen?

Hallo @ HamzaIkram2727 , wenn ich mich nicht irre, können Sie einfach ein neues Sandbox-Konto erstellen, um das alte zu verwenden und zu löschen. Es sollte funktionieren.

@ the-dut Auch wenn ich keine getAvailablePurchases () - und getPurchaseHistory () -Aufrufe verwende, stehe ich immer noch vor dem gleichen Problem. Es wird kein Kaufdialog angezeigt, aber der Erfolg wurde automatisch gekauft.

Ich rufe auch die Funktionen finishTrsanactionIOS und finishTransation auf

Ich habe es geschafft, den nativen Kaufdialog für iOS durch Beenden der App zu erhalten. Das sieht für mich so aus, als wären einige Versprechen endgültig gelöst. Ich bin mir nicht sicher, ob es in react-native-iap Versprechensabhängigkeiten gibt, aber das Verhalten scheint seltsam. Das Aufrufen von requestSubscription in der App aufgelöst, aber es gibt keinen Dialog, bis ich die App beende.

Ich habe das gleiche Problem mit getAvailblePruchases (). Meistens wird das Versprechen nicht gelöst oder abgelehnt. Dies begann beim Testen auf iOS 14-Geräten.

Ich habe das gleiche Problem

1. Ich rufe getAvailablePurchases () auf
2. requestSubscription ()

Ich habe getAvailablePurchase entfernt und anscheinend funktioniert es gut

Irgendwelche Updates?

Wirklich seltsames Verhalten und für das, was ich bemerke, passiert es nicht nur auf dem ios 14 ... Ich kontaktiere Apple, um zu verstehen, was los ist, denn ich glaube nicht, dass es ein Problem im Zusammenhang mit dem Paket ist selbst.

Hier nur um zu sagen, dass ich vor dem gleichen Problem stehe. Ich habe bereits auf iOS 12 getestet und es funktioniert gut ... iOS 14 ist fehlerhaft.

Mein Aufruf von requestSubscription dauert nur ewig ... Und es nervt in der Produktion!

Nun, nach einem Tag "Spaß haben" ist dies das, was ich bisher festgestellt habe ... Ich habe verschiedene Geräte auf verschiedenen Betriebssystemversionen und ich habe dieses Problem auf jedem von ihnen. Ich habe diesbezüglich Apple kontaktiert und wir verfolgen den Fall jedoch immer noch ohne solide Schlussfolgerungen. Ich glaube nicht, dass es ein Problem mit dem Paket ist, es muss etwas auf der Seite von Apple sein. Ich habe alles versucht, was die Leute in diesem Thread und in anderen Threads erwähnen, die ein ähnliches Problem gemeldet haben. Das Dialogfeld "In-App-Kauf" ist beim Anzeigen nur inkonsistent. Bis jetzt kann ich keinen gültigen Grund dafür finden, da die Ergebnisse immer unterschiedlich sind. Manchmal erhalte ich einen E_UNKNOWN-Fehler, manchmal erhalte ich kein Feedback, manchmal wird das Popup nach 10 Minuten Wartezeit angezeigt und manchmal funktioniert es einfach ... Ich habe es mit Sandbox-Benutzern versucht, Nicht-Sandbox-Benutzern, ich hatte das Es werden dieselben unterschiedlichen Ergebnisse für denselben Benutzer und dasselbe Gerät angezeigt, und es wird nicht einmal ein Fehler oder ein schlüssiges / aufschlussreiches Protokoll angezeigt. Das Debuggen ist nur frustrierend, weil Sie so ziemlich nichts finden können ... Nun, wenn Sie Ratschläge oder Einsichten haben, höre ich zu ... In der Zwischenzeit, wenn ich Neuigkeiten von Apple habe, Ich werde euch auf dem Laufenden halten...
PS EDIT. Nach dem Lesen des letzten Kommentars ist eines konsistent und ich kann es bestätigen. Unter iOS 14 scheint das Ding inkonsistenter zu sein, obwohl es auf jeder Betriebssystemversion passiert, die ich getestet habe (12, 13.7, 14). Ich habe jedoch immer noch den Eindruck, dass das Problem nicht nur mit der Betriebssystemversion zusammenhängt, und deshalb denke ich, dass es etwas mit dem Sandbox-Server oder irgendetwas anderem am Ende von Apple zu tun haben muss.

Wir haben unser App-Paket mit einem vom App Store genehmigten Build getestet und es sieht so aus, als ob die Inkonsistenz bei iOS Version 14+ stärker auftritt

Unser Fazit ist, dass die Art und Weise, wie Apple den Beleg unter iOS 14+ überprüft, etwas anders ist.

Dies geschieht mit Konten, die bereits Einkäufe getätigt haben

1. Erstellen Sie ein neues Konto in Sandbox
2. Machen Sie einen Kauf (es funktioniert gut, weil die restorePurchases keine Käufe hat)
3. Warten Sie, bis es abläuft.
4. Noch einmal kaufen. (Jetzt antwortet der Wiederherstellungskauf auf ein Objekt und das Popup, um zu bestätigen, dass der Kauf nicht mehr funktioniert.)

Es ist komisch. Ich habe den Bibliothekscode überprüft und einige Protokolle zum Testen hinzugefügt. Und ich habe folgendes

1. Wenn restorePurchases aufgerufen wird. Es wird der Listener "paymentQueueRestoreCompletedTransactionsFinished" ausgeführt.

-(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];
}

Hier drucke ich im Protokoll die Transaktionsgröße aus und habe 23 Artikel erhalten

1. Die Funktion paymentQueue wird ausgeführt, um die Wiederherstellungstransaktionen abzuschließen

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

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

1. resolvePromisesForKey schließt den restorePurchase ab

2. requestSubscription ruft die Funktion buyProduct auf

3. Hier habe ich Protokolle hinzugefügt, um das Protokoll zu sehen

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

  SKMutablePayment *payment = [SKMutablePayment paymentWithProduct:product];

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

  [[SKPaymentQueue defaultQueue] addPayment:payment];

1. Ich habe folgendes Protokoll erhalten:
   a) RestorePurchases-Protokoll

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

Daher verstehe ich nicht, warum die ZahlungQueue-Methode mit einem SKPaymentTransactionStateRestored vom 5. Oktober ausgeführt wird

@andresordonezfm Haben Sie nach dem Kauf finishTransaction angerufen?

Auch in Bezug auf die Popups finden Sie hier großartige Versuche in # 863. Ich hoffe es hilft.

@andresordonezfm Haben Sie nach dem Kauf finishTransaction angerufen?

Sicher! Außerdem habe ich clearTransactionIOS () trotzdem aufgerufen, wenn es das Problem sein könnte, aber nichts.

Auch in Bezug auf die Popups finden Sie hier großartige Versuche in # 863. Ich hoffe es hilft.

Dankeschön. Ich werde es überprüfen

Irgendwelche Lösungen / Updates?

Noch nichts. Ich habe es überprüft und Apple hat neue Funktionen in StoreKit und Benachrichtigungstypen hinzugefügt.
Ich bin mir nicht sicher, ob das das Problem sein könnte

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

Ich habe das Paket auf 4.5.2 heruntergestuft, was für mich funktioniert hat
Überprüfen Sie, ob Sie anrufen
await RNIap.initConnection();
vor RNIap.requestSubscription

Scheint, als hätte ich dieses Problem gelöst:
https://github.com/dooboolab/react-native-iap/issues/1146

Als ich die Quittung validierte, übergab ich zunächst true als isTest -Parameter (selbst wenn es sich um einen Produktions-Build handelte).
Dann habe ich RNIap.clearTransactionIOS(); zu purchaseUpdatedListener hinzugefügt, bevor ich die Quittung validiert habe, und RNIap.finishTransaction(purchase, false) nach RNIap.finishTransactionIOS(purchase.transactionId);

Ich habe in TestFlight getestet und konnte zum ersten Mal einen Kauf abschließen (mit einem Sandbox-Konto). Jetzt werde ich ihn in der Produktion testen 🤞

Scheint, als hätte ich dieses Problem gelöst:

1146

Als ich die Quittung validierte, übergab ich zunächst true als isTest -Parameter (selbst wenn es sich um einen Produktions-Build handelte).
Dann habe ich RNIap.clearTransactionIOS(); zu purchaseUpdatedListener hinzugefügt, bevor ich die Quittung validiert habe, und RNIap.finishTransaction(purchase, false) nach RNIap.finishTransactionIOS(purchase.transactionId);

Ich habe in TestFlight getestet und konnte zum ersten Mal einen Kauf abschließen (mit einem Sandbox-Konto). Jetzt werde ich ihn in der Produktion testen 🤞

Hallo Mann, ich habe diese Lösung ausprobiert, aber bei mir nicht funktioniert.

Ich habe das gleiche Problem. Dies passiert, wenn Sie nach dem Wiederherstellen des Kaufs versuchen, ein Abonnement zu kaufen.

Ich kann Protokolle von @andresordonezfm bestätigen, wo es scheint , dass SKPaymentQueue erhält Transaktion des SKPaymentTransactionStateRestored Typs anstelle der SKPaymentTransactionStatePurchasing Art, die der Grund für die „Wiederherstellung“ ist Zeichenfolge, die beim Kauf protokolliert wird.

Hallo Leute, entschuldige die Verzögerung.

Ich habe nachgeprüft und eine Lösung für dieses Problem gefunden. Das Problem besteht darin, dass vor dem Aufrufen der Wiederherstellungskäufe die neu geöffneten Transaktionen derselben Wiederherstellungskäufe nicht ordnungsgemäß geschlossen werden. Dann schließe ich sie gewaltsam.

Bei der Funktion clearTransactionIOS der Bibliothek muss das Versprechen hinzugefügt werden, um zu warten, bis die Transaktionen mit der Funktion removeTransactions geschlossen werden

Hier ist mein Code:

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

1. Ersetzen Sie die Funktion RCT_EXPORT_METHOD (clearTransaction) durch den folgenden 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. Fügen Sie die folgende neue Funktion hinzu (ich habe diese Funktion am Ende der Datei RNIapIos.m hinzugefügt. Vor der Zeile "@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;
        }
    }
}

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

1. Unter dem Code "SKProduct * savedProduct;" Fügen Sie die folgende Zeile hinzu

  NSInteger countPendingTransaction;

Zum Schluss vor dem Aufruf der Funktion "RNIap.requestSubscription (productId, false)".
Die Funktion clearTransactionIOS muss aufgerufen werden, zum Beispiel:

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

Ich hoffe, es hilft. Das seltsame Verhalten von Wiederherstellungskäufen konnte ich nicht herausfinden. Aber das löste sich für mich beim Testen in Sandbox.

Wenn Sie Vorschläge haben, lassen Sie es mich bitte wissen.

Ich habe auch dieses Problem ， bitte Autor, hilf mir, danke deiner Familie

Ich habe auch dieses Problem ， bitte Autor, hilf mir, danke deiner Familie

Hallo Mann, im vorherigen Kommentar wurden die Schritte erklärt, die ich zur Lösung unternommen habe

Wenn Sie Kommentare haben, lassen Sie es mich wissen

@andresordonezfm Würdest du bereit sein, eine PR für diese Änderungen zu erstellen?

Für die Ausgabe von Einkäufen, die nach dem Wiederherstellen als SKPaymentTransactionStateRestored eingehen, habe ich ein neues Konto erstellt und einige Einkäufe getätigt, und dies geschieht nicht für dieses Konto. Ich kann danach RNIap.getAvailablePurchases() und RNIap.requestSubscription() anrufen.

Es scheint, dass es mit der Anzahl der Einkäufe eines Benutzers zusammenhängt? Ich habe noch keine Produktionstests durchgeführt.

Nun, nach einem Tag "Spaß haben" ist dies das, was ich bisher festgestellt habe ... Ich habe verschiedene Geräte auf verschiedenen Betriebssystemversionen und ich habe dieses Problem auf jedem von ihnen. Ich habe diesbezüglich Apple kontaktiert und wir verfolgen den Fall jedoch immer noch ohne solide Schlussfolgerungen. Ich glaube nicht, dass es ein Problem mit dem Paket ist, es muss etwas auf der Seite von Apple sein. Ich habe alles versucht, was die Leute in diesem Thread und in anderen Threads erwähnen, die ein ähnliches Problem gemeldet haben. Das Dialogfeld "In-App-Kauf" ist beim Anzeigen nur inkonsistent. Bis jetzt kann ich keinen gültigen Grund dafür finden, da die Ergebnisse immer unterschiedlich sind. Manchmal erhalte ich einen E_UNKNOWN-Fehler, manchmal erhalte ich kein Feedback, manchmal wird das Popup nach 10 Minuten Wartezeit angezeigt und manchmal funktioniert es einfach ... Ich habe es mit Sandbox-Benutzern versucht, Nicht-Sandbox-Benutzern, ich hatte das Es werden dieselben unterschiedlichen Ergebnisse für denselben Benutzer und dasselbe Gerät angezeigt, und es wird nicht einmal ein Fehler oder ein schlüssiges / aufschlussreiches Protokoll angezeigt. Das Debuggen ist nur frustrierend, weil Sie so ziemlich nichts finden können ... Nun, wenn Sie Ratschläge oder Einsichten haben, höre ich zu ... In der Zwischenzeit, wenn ich Neuigkeiten von Apple habe, Ich werde euch auf dem Laufenden halten...
PS EDIT. Nach dem Lesen des letzten Kommentars ist eines konsistent und ich kann es bestätigen. Unter iOS 14 scheint das Ding inkonsistenter zu sein, obwohl es auf jeder Betriebssystemversion passiert, die ich getestet habe (12, 13.7, 14). Ich habe jedoch immer noch den Eindruck, dass das Problem nicht nur mit der Betriebssystemversion zusammenhängt, und deshalb denke ich, dass es etwas mit dem Sandbox-Server oder irgendetwas anderem am Ende von Apple zu tun haben muss.

Genau das, was ich am Ende erlebe, auch nach dem von @andresordonezfm vorgeschlagenen @ 106firestarter , hat Apple jemals

Ich werde sehen, was ich in der Zwischenzeit in den Entwicklerforen finden kann.

Für die Ausgabe von Einkäufen, die nach dem Wiederherstellen als SKPaymentTransactionStateRestored eingehen, habe ich ein neues Konto erstellt und einige Einkäufe getätigt, und dies geschieht nicht für dieses Konto. Ich kann danach RNIap.getAvailablePurchases() und RNIap.requestSubscription() anrufen.

Es scheint, dass es mit der Anzahl der Einkäufe eines Benutzers zusammenhängt? Ich habe noch keine Produktionstests durchgeführt.

Ich werde das versuchen, aber die Produktion ist in der Tat auch ein Problem.

Für die Aufzeichnung rufe ich auch getAvailablePurchases() vor requestSubscription() .

Möglicherweise verwandt:

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

Ich kann auch bestätigen, dass mit einem brandneuen Konto das Problem nicht mehr wie von @Paduado angegeben ist (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-742685043).

Korrektur: Wenn ich ein brandneues Konto zusammen mit dem von funktioniert es auf meiner Seite. Ohne das Update tritt nach dem ersten Abonnement wieder dasselbe Verhalten auf, das ich zuvor hatte, und ich kann es nicht mehr abonnieren. Eine weitere Sache, die mir nach dem Anwenden des Fixes aufgefallen ist, ist, dass Abonnements nicht mehr automatisch automatisch erneuert werden, auch nicht einmal, obwohl die Verwendung der Sandbox voraussichtlich fünfmal verlängert wird.

@andresordonezfm Würdest du bereit sein, eine PR für diese Änderungen zu erstellen?

Hallo, Alter, entschuldige die Verzögerung noch einmal. Ich habe eine Pull-Anfrage erstellt, um auf native iap zu reagieren

~ Ich kann auch bestätigen, dass mit einem brandneuen Konto das Problem nicht mehr wie von @Paduado angegeben ist ( # 1120 (Kommentar) ). ~

Korrektur: Wenn ich ein brandneues Konto zusammen mit dem von funktioniert es auf meiner Seite. Ohne das Update tritt nach dem ersten Abonnement wieder dasselbe Verhalten auf, das ich zuvor hatte, und ich kann es nicht mehr abonnieren. Eine weitere Sache, die mir nach dem Anwenden des Fixes aufgefallen ist, ist, dass Abonnements nicht mehr automatisch automatisch erneuert werden, auch nicht einmal, obwohl die Verwendung der Sandbox voraussichtlich fünfmal verlängert wird.

Hallo Mann, ich denke es ist ein Sandkastenproblem. Geben Sie dieses Verhalten weiter?

@andresordonezfm Ja, ich vermute auch, dass es ein Problem mit Apples Sandbox ist. Ich habe seit meinem letzten Kommentar keine Tests mehr durchgeführt und muss die Produktion noch überprüfen. Bisher habe ich jedoch keine Beschwerden von Kunden erhalten.

Die Sandbox scheint bei Verwendung eines brandneuen Kontos, wie zuvor von @Paduado gemeldet, wieder auf dem

@andresordonezfm Ich bin auf dasselbe gestoßen und deine Patch-Nähte, um es zu reparieren. Ich glaube jedoch, dass ich einen subtilen Fehler in Ihrem Code sehe, der möglicherweise dazu führen kann, dass cleartTransactionsIOS() hängen bleibt. removeTransactions kann mit einer oder mehreren zu entfernenden Transaktionen aufgerufen werden. Ich denke, wir wollen in removeTransactions :

        countPendingTransaction -= [transactions count];

In der Praxis habe ich nur removedTransactions die mit einer Transaktion aufgerufen wurden, aber Apple-Dokumente sagen, dass es eine oder mehrere sein könnten. Schöner Fund übrigens! Ich war eine Weile dabei.

@andresordonezfm Ich bin auf dasselbe gestoßen und deine Patch-Nähte, um es zu reparieren. Ich glaube jedoch, dass ich einen subtilen Fehler in Ihrem Code sehe, der möglicherweise dazu führen kann, dass cleartTransactionsIOS() hängen bleibt. removeTransactions kann mit einer oder mehreren zu entfernenden Transaktionen aufgerufen werden. Ich denke, wir wollen in removeTransactions :

        countPendingTransaction -= [transactions count];

In der Praxis habe ich nur removedTransactions die mit einer Transaktion aufgerufen wurden, aber Apple-Dokumente sagen, dass es eine oder mehrere sein könnten. Schöner Fund übrigens! Ich war eine Weile dabei.

Hallo Mann, danke für deine Empfehlung. Ich habe Ihren Vorschlag getestet und er funktioniert gut für mich. Mit dieser Änderung habe ich eine Pull-Anfrage gestellt.

Hinweis: Ja, ich habe diese Dokumentation überprüft, aber da sie nur von Transaktion zu Transaktion ausgelöst wird, habe ich sie nicht implementiert. Aber es ist eine sehr gute Empfehlung. Danke!