React-native-iap: iOS 14: problemas de requestSubscription ()

Creado en 20 sept. 2020  ·  57Comentarios  ·  Fuente: dooboolab/react-native-iap

Versión de react-native-iap

4.4.9

Versión de react-native

.62.2

Plataformas a las que se enfrentó el error (¿IOS o Android o ambos?)

solo iOS. Aún no probamos en Android.

Comportamiento esperado

Aparece el cuadro de diálogo de compra para completar la compra y luego se llama a purchaseUpdatedListener.

Comportamiento real

llamar requestSubscription (). Sin diálogos de compra. PurchaseUpdatedListener llamó inmediatamente sin diálogos de compra ni recibo válido.

Entorno probado (¿Emulador? ¿Dispositivo real?)

Dispositivo iOS 14 real usando TestFlight.

Pasos para reproducir el comportamiento

llamar a RNIap.requestSubscription ().

Notas:

  • XCode 12
  • mediante Iniciar sesión con ID de Apple.
  • prueba en sandbox con ID real de Apple (no prueba de usuario)
  • funciona bien en iPad con iOS 13.7.
  • han aplicado la solución de promesa de iOS 14.
🍚 need contribution 📱 iOS 🙏 help wanted

Comentario más útil

Aquí solo para decir que estoy enfrentando el mismo problema. Ya probé en iOS 12 y está funcionando bien ... iOS 14 tiene errores.

Mi llamada de solicitud La suscripción dura para siempre ... ¡Y está fallando en la producción!

Todos 57 comentarios

Igual que aquí. ¿Alguien puede ayudar?

No se cuelga, pero devuelve []

Para nosotros, se muestra el cuadro de diálogo de compra y el oyente de compra se llama correctamente, pero la llamada requestSubscription devuelve una promesa que nunca se resuelve.

Parece que esto podría haberse resuelto aquí https://github.com/dooboolab/react-native-iap/pull/1064

Apliqué esa solución de promesa anteriormente, por lo que ese no es el problema aquí.

Funciona para mí con iOS14, así es como lo hice:
// request purchase, listener registered above will receive notification when processing done RNIap.requestSubscription(this.productIds[0]).catch(err => { console.log(err.code, err.message); });

Estaba llamando al método con el parámetro booleano falso, que creo que es la recomendación. Eliminé eso y sigo viendo un comportamiento muy extraño en iOS14 sin importar cómo llame al método, y funciona bien en un iPhone y iPad que ejecutan iOS 13 a través de TestFlight. Probé requestSubscription con y sin el booleano y nunca obtengo los cuadros de diálogo de compra en iOS 14. Ahora, la mayoría de las veces llama RequestUpdatedListener inmediatamente con lo que parece un recibo no válido.

¿Hay otros que no tienen problemas con sus suscripciones en iOS14 y xCode 12 usando TestFlight?

Oye, ¿alguno de ustedes usa getPurchaseHistory() o getAvailablePurchases() justo antes de requestSubscription() ? Si es así, este parece ser el problema en iOS 14.

ObtengoAvailablePurchases () anteriormente en el flujo: al cargar la aplicación, la pantalla justo antes de mi pantalla de suscripción.

sí, desafortunadamente esto parece ser un error en iOS 14. No es culpa de este complemento. Revisé el código nativo y es el mismo problema.

Ese era el problema. Eliminé la llamada a getAvailablePurchases () y aparecieron las ventanas emergentes de compra y la compra se realizó correctamente. Lamentablemente, necesito hacer esa llamada para getAvailablePurchases, ya que verifico el estado de su suscripción en App Load. Entonces, ¿parece que debemos esperar a que un parche de iOS 14 solucione esto? ¿Nada más que nadie pueda hacer? Por cierto, muchas gracias theDev23!

De nada, holandés. Probablemente su mejor apuesta sea confiar en un cheque basado en servidor.

Esperaba evitar que un servidor hiciera esto. ¿Es tan fácil como copiar el código de mi reacción en algo como una función de nube de Firebase? ¿O es esto algo que necesita ser rediseñado? Probablemente una pregunta tonta, pero bueno ... todos comenzamos haciendo preguntas tontas. :)

@ the-dut Puede usar iaphub para encargarse de la validación del recibo del servidor

Bebida de su elección si alguna vez se encuentra en el medio oeste de EE. UU. :)

El mismo problema aquí afecta a los usuarios en vivo. @ theDev23 , ¿tiene un enlace a alguna discusión sobre el tema en iOS? ¿Hay plazos para una solución?

@nicknjpconsultingllc sin enlace, lo siento. Yo mismo hice la excavación.

@ the-dut También estoy usando Firebase Cloud Functions. Echa un vistazo a este repositorio .

Terminé guardando el recibo en una base de datos en la compra exitosa en el purchaseUpdatedListener, luego, al cargar la aplicación, extraigo el recibo de la base de datos, lo valido nuevamente y verifico si está vencido o no. Eso me permitió deshacerme de la llamada a getAvailablePurchases () si funciona muy bien en iOS14. Ha funcionado muy bien hasta ahora y es mucho más rápido. Ahora una pregunta sobre qué tan lejos debo llevar esto. Si esto es todo lo que hago, ¿se llamará al UpdatedPurchaseListener sobre todas las actualizaciones de la suscripción (básicamente, las renovaciones automáticas) hasta que termine las transacciones? ¿O necesito implementar las notificaciones de servidor a servidor para estar informado de las renovaciones automáticas? Casi parece que usar el UpdatedPurchaseListener es una solución mejor (y más simple) ya que he estado leyendo que la integración de servidor a servidor no es perfecta.

Sigo teniendo este problema después de eliminar getPurchaseHistory y aplicar la solución de promesa. No puedo hacer que aparezca el cuadro de diálogo de compra. ¿Alguien puede ayudar?

Yo diría que eche un vistazo a todas y cada una de las llamadas que está haciendo a AIP antes de realizar la solicitud de compra. ¿También llamas a getAvailablePurchases ()?

No puedo excluir las llamadas a getAvailablePurchases () y getPurchaseHistory (), ¿hay alguna forma de hacer que requestSubscription () aparezca en el menú de compra con estas llamadas?

Hola @ HamzaIkram2727 , si no me equivoco, puedes crear una nueva cuenta de sandbox para usar y eliminar la anterior. Debería funcionar.

@ the-dut Incluso yo no estoy usando ninguna llamada getAvailablePurchases () y getPurchaseHistory (), todavía estoy enfrentando el mismo problema. No muestra el diálogo de compra, pero el éxito de la compra se realiza automáticamente.

También estoy llamando a las funciones finishTrsanactionIOS y finishTransation

Logré obtener el cuadro de diálogo de compra nativo de iOS al salir de la aplicación. Esto me parece que algunas promesas finalmente se resolvieron. No estoy seguro de si hay dependencias de promesa en react-native-iap pero el comportamiento parece extraño. Llamar a requestSubscription resuelve en la aplicación, pero no hay diálogo hasta que salgo de la aplicación.

Tengo el mismo problema con getAvailblePruchases (), la mayoría de las veces la promesa no se resuelve o rechaza. Comenzó a suceder al realizar pruebas en dispositivos iOS 14.

Estoy teniendo el mismo problema

  1. Llamo getAvailablePurchases ()
  2. requestSubscription ()

Eliminé getAvailablePurchase y aparentemente funciona bien

¿Alguna actualización?

Comportamiento realmente extraño y por lo que estoy notando, no es solo en el ios 14 que sucede ... Me estoy comunicando con Apple para tratar de entender qué está pasando porque no creo que sea un problema relacionado con el paquete. uno mismo.

Aquí solo para decir que estoy enfrentando el mismo problema. Ya probé en iOS 12 y está funcionando bien ... iOS 14 tiene errores.

Mi llamada de solicitud La suscripción dura para siempre ... ¡Y está fallando en la producción!

Bueno, después de un día de "divertirme" esto es lo que he concluido hasta ahora ... Tengo varios dispositivos en diferentes versiones de SO y tengo este problema en cada uno de ellos. Me puse en contacto con Apple con respecto a esto y todavía estamos siguiendo el caso, sin embargo, sin ninguna conclusión sólida. No creo que sea un problema con el paquete, debe ser algo del lado de Apple. Probé todo lo que la gente menciona en este hilo y en otros hilos que han informado de un problema similar. El cuadro de diálogo de compra en la aplicación es inconsistente al aparecer y, hasta ahora, no puedo encontrar una razón válida porque el resultado siempre es diferente. A veces recibo un error E_UNKNOWN, otras veces no recibo comentarios, a veces la ventana emergente se muestra después de 10 minutos de espera y otras veces simplemente funciona ... Lo intenté con usuarios de sandbox, no usuarios de sandbox, he tenido los mismos resultados diferentes para el mismo usuario y dispositivo y ni siquiera se muestra un error o un registro concluyente / perspicaz. Esto es frustrante de depurar porque no se puede encontrar prácticamente nada ... Bueno, si tienen algún tipo de consejo o información, estoy escuchando ... Mientras tanto, si tengo noticias de Apple, Te mantendré informado...
PS EDIT. después de leer el último comentario, una cosa es consistente y puedo confirmarla, en iOS 14 la cosa parece más inconsistente a pesar de que sucede en todas las versiones del sistema operativo que he probado (12, 13.7, 14). Sin embargo, todavía tengo la impresión de que el problema no está únicamente relacionado con la versión del sistema operativo y por eso estoy pensando que debe ser algo con el servidor Sandbox o cualquier otra cosa al final de Apple.

Hemos probado nuestro paquete de aplicaciones con una compilación aprobada por la App Store y parece que la inconsistencia es más destacada en la versión 14+ de iOS

Nuestra conclusión es que la forma en que Apple verifica el recibo en iOS 14+ es un poco diferente.

Ocurre con cuentas que ya han realizado compras

  1. Crea una nueva cuenta en Sandbox
  2. Haga una compra (funciona bien porque restorePurchases no tiene compras)
  3. Espere hasta que expire.
  4. Compra otra vez. (Ahora la restauración de compras responde un objeto y la ventana emergente para confirmar que la compra ya no funciona)

Es raro. Estaba revisando el código de la biblioteca y agregué algunos registros para probar. Y tengo lo siguiente

  1. Cuando se llama a restorePurchases. Ejecuta el oyente "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];
}

Aquí imprimo en log el tamaño de las transacciones y obtuve 23 artículos

  1. Se ejecuta la función
case SKPaymentTransactionStateRestored: {
          NSLog(@"Restored ");

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

  2. requestSubscription comienza a llamar a la función buyProduct

  3. Aquí agregué registros para ver el registro
 NSLog(@"\n  produc purchase : %@", product);

  SKMutablePayment *payment = [SKMutablePayment paymentWithProduct:product];

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

  [[SKPaymentQueue defaultQueue] addPayment:payment];
  1. Tengo el siguiente registro:
    a) Restaurar registro de compras
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] 

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

Entonces no entiendo por qué el método paymentQueue se ejecuta con un SKPaymentTransactionStateRestored con fecha del 5 de octubre

@andresordonezfm ¿Ha llamado finishTransaction después de la compra?

También con respecto a las ventanas emergentes, aquí hay grandes pruebas en el n. ° 863. Espero eso ayude.

@andresordonezfm ¿Ha llamado finishTransaction después de la compra?

¡Por supuesto! también llamé clearTransactionIOS () de todos modos si podría ser el problema, pero nada.

También con respecto a las ventanas emergentes, aquí hay grandes pruebas en el n. ° 863. Espero eso ayude.

Gracias. Lo voy a revisar

¿Alguna solución / actualización?

Nada aún. Estaba revisando y Apple agregó nuevas funciones en StoreKit y tipos de notificación.
No estoy seguro si ese podría ser el problema

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

Bajé el paquete a 4.5.2 funcionó para mí
comprueba si estás llamando
await RNIap.initConnection();
antes de RNIap.requestSubscription

Parece que lo resolví siguiendo este problema:
https://github.com/dooboolab/react-native-iap/issues/1146

En primer lugar, cuando validaba el recibo, pasaba true como parámetro isTest (incluso cuando era una compilación de producción).
Luego agregué RNIap.clearTransactionIOS(); en purchaseUpdatedListener antes de validar el recibo y RNIap.finishTransaction(purchase, false) después de RNIap.finishTransactionIOS(purchase.transactionId);

Probé en TestFlight y pude completar una compra por primera vez (con una cuenta de sandbox), ahora voy a probarlo en producción 🤞

Parece que lo resolví siguiendo este problema:

1146

En primer lugar, cuando validaba el recibo, pasaba true como parámetro isTest (incluso cuando era una compilación de producción).
Luego agregué RNIap.clearTransactionIOS(); en purchaseUpdatedListener antes de validar el recibo y RNIap.finishTransaction(purchase, false) después de RNIap.finishTransactionIOS(purchase.transactionId);

Probé en TestFlight y pude completar una compra por primera vez (con una cuenta de sandbox), ahora voy a probarlo en producción 🤞

Hola amigo, probé esta solución pero no funcionó para mí.

Me encuentro con el mismo problema. Sucede cuando intentas comprar una suscripción después de restaurar la compra.

Puedo confirmar los registros de @andresordonezfm , donde parece que SKPaymentQueue recibe la transacción del tipo SKPaymentTransactionStateRestored , en lugar del tipo SKPaymentTransactionStatePurchasing , que es el motivo de la "Restauración" cadena que se registra en la compra.

Hola chicos, perdon por el retraso.

Estaba revisando y encontré una solución para este problema. El problema es que antes de llamar a las compras de restauración, las transacciones recién abiertas de las mismas compras de restauración no se cierran correctamente. Luego los cierro a la fuerza.

Luego, la función clearTransactionIOS de la biblioteca, se debe agregar la promesa de esperar a que las transacciones se cierren usando la función removida

Aquí está mi código:

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

  1. Reemplace la función RCT_EXPORT_METHOD (clearTransaction) con el siguiente código
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. Agregue la siguiente función nueva (agregué esta función al final del archivo RNIapIos.m. Antes de la línea "@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;
        }
    }
}

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

  1. Bajo el código "SKProduct * protectedProduct;" agregue la siguiente línea
  NSInteger countPendingTransaction;

Finalmente antes de llamar a la función "RNIap.requestSubscription (productId, false)".
Se debe llamar a la función clearTransactionIOS, por ejemplo:

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

Espero que ayude. El extraño comportamiento de restaurar compras no he podido encontrar el motivo. Pero esto me resolvió probando en Sandbox.

Sí tiene alguna sugerencia, por favor hágamelo saber.

Yo también tengo este problema, por favor autor, ayúdame, gracias a tu familia

Yo también tengo este problema, por favor autor, ayúdame, gracias a tu familia

Hola amigo, en el comentario anterior se explican los pasos que hice para solucionarlo

Si tiene algún comentario, hágamelo saber.

@andresordonezfm , ¿estaría dispuesto a crear un PR para estos cambios?

Para el problema de las compras que vienen como SKPaymentTransactionStateRestored que ocurren después de la restauración, creé una nueva cuenta e hice algunas compras y no está sucediendo para esa cuenta. Puedo llamar a RNIap.getAvailablePurchases() y RNIap.requestSubscription() después.

¿Parece que puede estar relacionado con la cantidad de compras que tiene un usuario? Todavía no he realizado ninguna prueba en producción.

Bueno, después de un día de "divertirme" esto es lo que he concluido hasta ahora ... Tengo varios dispositivos en diferentes versiones de SO y tengo este problema en cada uno de ellos. Me puse en contacto con Apple con respecto a esto y todavía estamos siguiendo el caso, sin embargo, sin ninguna conclusión sólida. No creo que sea un problema con el paquete, debe ser algo del lado de Apple. Probé todo lo que la gente menciona en este hilo y en otros hilos que han informado de un problema similar. El cuadro de diálogo de compra en la aplicación es inconsistente al aparecer y, hasta ahora, no puedo encontrar una razón válida porque el resultado siempre es diferente. A veces recibo un error E_UNKNOWN, otras veces no recibo comentarios, a veces la ventana emergente se muestra después de 10 minutos de espera y otras veces simplemente funciona ... Lo intenté con usuarios de sandbox, no usuarios de sandbox, he tenido los mismos resultados diferentes para el mismo usuario y dispositivo y ni siquiera se muestra un error o un registro concluyente / perspicaz. Esto es frustrante de depurar porque no se puede encontrar prácticamente nada ... Bueno, si tienen algún tipo de consejo o información, estoy escuchando ... Mientras tanto, si tengo noticias de Apple, Te mantendré informado...
PS EDIT. después de leer el último comentario, una cosa es consistente y puedo confirmarla, en iOS 14 la cosa parece más inconsistente a pesar de que sucede en todas las versiones del sistema operativo que he probado (12, 13.7, 14). Sin embargo, todavía tengo la impresión de que el problema no está únicamente relacionado con la versión del sistema operativo y por eso estoy pensando que debe ser algo con el servidor Sandbox o cualquier otra cosa al final de Apple.

Exactamente lo que estoy experimentando por mi parte, incluso después de la solución sugerida por @andresordonezfm (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-734805587). @ 106firestarter , ¿respondió Apple alguna vez?

Mientras tanto, veré qué puedo encontrar en los foros de desarrolladores.

Para el problema de las compras que vienen como SKPaymentTransactionStateRestored que ocurren después de la restauración, creé una nueva cuenta e hice algunas compras y no está sucediendo para esa cuenta. Puedo llamar a RNIap.getAvailablePurchases() y RNIap.requestSubscription() después.

¿Parece que puede estar relacionado con la cantidad de compras que tiene un usuario? Todavía no he realizado ninguna prueba en producción.

Lo intentaré, pero la producción también es una preocupación.

Para que conste, también estoy llamando a getAvailablePurchases() antes de requestSubscription() .

También puedo confirmar que con una cuenta nueva, el problema ya no es el que dijo @Paduado (https://github.com/dooboolab/react-native-iap/issues/1120#issuecomment-742685043).

Corrección: usar una cuenta nueva junto con la solución sugerida por @andresordonezfm hace que funcione por mi parte. Sin la solución, después de la primera suscripción, el mismo comportamiento que estaba experimentando antes vuelve a aparecer y ya no puedo suscribirme de nuevo. Una cosa más que noté después de aplicar la corrección es que las suscripciones ya no parecen renovarse automáticamente, ni siquiera una vez, aunque al usar sandbox se espera que se renueven 5 veces.

@andresordonezfm , ¿estaría dispuesto a crear un PR para estos cambios?

Hola amigo, perdón por el retraso de nuevo. Creé una solicitud de extracción para react-native iap

~ También puedo confirmar que con una cuenta nueva el problema ya no es como lo dijo # 1120 (comentario) ).

Corrección: usar una cuenta nueva junto con la solución sugerida por @andresordonezfm hace que funcione por mi parte. Sin la solución, después de la primera suscripción, el mismo comportamiento que estaba experimentando antes vuelve a aparecer y ya no puedo suscribirme de nuevo. Una cosa más que noté después de aplicar la corrección es que las suscripciones ya no parecen renovarse automáticamente, ni siquiera una vez, aunque al usar sandbox se espera que se renueven 5 veces.

Hola amigo, creo que es un problema de caja de arena. ¿Sigues dando ese comportamiento?

@andresordonezfm sí, yo también sospecho que es un problema con la caja de arena de Apple. No realicé más pruebas desde mi último comentario y todavía tengo que verificar la producción. Sin embargo, hasta la fecha, no he recibido ninguna queja de los clientes.

La caja de arena parece estar de nuevo en marcha por mi parte cuando uso una cuenta nueva, como informó anteriormente @Paduado , sin realizar ningún cambio en el código. 🤷‍♂️ 😕

@andresordonezfm Encontré lo mismo y tus costuras de parche para arreglarlo. Sin embargo, creo que veo un error sutil en su código que podría hacer que cleartTransactionsIOS() cuelgue. removeTransactions se puede llamar con 1 o más transacciones para eliminar. Entonces, en removeTransactions , creo que queremos:

        countPendingTransaction -= [transactions count];

En la práctica, solo he visto removedTransactions llamados con una transacción, pero los documentos de Apple dicen que podría ser una o más. ¡Buen descubrimiento por cierto! Estuve atrapado en esto por un tiempo.

@andresordonezfm Encontré lo mismo y tus costuras de parche para arreglarlo. Sin embargo, creo que veo un error sutil en su código que podría hacer que cleartTransactionsIOS() cuelgue. removeTransactions se puede llamar con 1 o más transacciones para eliminar. Entonces, en removeTransactions , creo que queremos:

        countPendingTransaction -= [transactions count];

En la práctica, solo he visto removedTransactions llamados con una transacción, pero los documentos de Apple dicen que podría ser una o más. ¡Buen descubrimiento por cierto! Estuve atrapado en esto por un tiempo.

Hola amigo, gracias por tu recomendación. Probé tu propuesta y me funciona bien. Hice una solicitud de extracción con ese cambio.

Nota: Sí, revisé esa documentación, pero como solo se activa de una transacción a otra, no la implementé. Pero es una muy buena recomendación. ¡Gracias!

¿Fue útil esta página
0 / 5 - 0 calificaciones