android ios in-app-purchase in-app-billing soomla

android - InAppPurchase verificación y servidor separado para la lógica del juego



ios in-app-purchase (5)

Estoy desarrollando una aplicación usando Unity (para Android e iOS). Estoy usando el complemento SOOMLA para permitir a los usuarios comprar gemas (moneda virtual) con la compra en la aplicación.

Los usuarios, las gemas y toda la lógica del juego pasan por mi servidor en Azure.

Quiero que el siguiente procedimiento se lleve a cabo como una sola transacción de alguna manera:

  1. El usuario compra gemas con IAP
  2. La aplicación notifica al servidor
  3. El servidor valida la compra y actualiza los datos.

Pero si la conexión a Internet se rompe entre el paso 1 y el paso 2, el usuario pagó por las gemas que no recibió (¡no es bueno!)

Así que mi enfoque actual es este:

  1. El usuario inicia una compra.
  2. La aplicación notifica al servidor
  3. El servidor actualiza ciegamente los datos en consecuencia
  4. El usuario compra gemas con IAP
  5. Si la compra es cancelada, notifique al servidor para deshacerla.

De esa manera, se garantiza al usuario que obtenga sus gemas compradas, pero no se me garantiza que me paguen (no es genial ...)

Nota: No quiero administrar las gemas de los usuarios en la propia tienda. Quiero todo en mi propio servidor. Entonces el balance de SOOMLA no tiene sentido para mí. No me importa.

Estaba pensando que tal vez la aplicación pueda almacenar los datos de compra en un almacenamiento persistente hasta que logre notificarlo al servidor y luego eliminarlo. Pero también estaba pensando que esto podría ser una mala solución. De ahí esta pregunta.

Me imagino la mejor solución como algo que manejará adecuadamente este escenario:

  1. El usuario compra gemas con IAP
  2. IAP tiene éxito
  3. Internet se rompe
  4. Mi propio servidor no es notificado
  5. El usuario desinstala la aplicación de su dispositivo

  6. El usuario puede instalar la aplicación en otros dispositivos:

    • O bien fue acusado y consiguió las gemas por algo de magia.
    • O fue devuelto automáticamente, ya que las gemas no fueron recibidas.

Hasta ahora parece que esto es imposible por cualquier medio, lo que me decepciona con la tecnología de los IAP. Esperando respuestas que me demuestren que estoy equivocado.

Parece que todo lo que necesitaría es la posibilidad de obtener el historial de compras de un usuario de mi servidor, con una solicitud segura a Google Play o Apple Store. Pero eso no es parte del marco.

Entonces, ¿qué están haciendo los demás? ¿Cuál es el mejor enfoque?

Algún consejo:

  1. El usuario compra gemas con IAP
  2. IAP tiene éxito
  3. Internet se rompe
  4. Mi propio servidor no es notificado
  5. El usuario desinstala la aplicación de su dispositivo

  6. El usuario puede instalar la aplicación en otros dispositivos:

    O bien fue acusado y consiguió algunas gemas con algo de magia, o se le reembolsó automáticamente, ya que las gemas no fueron recibidas.

  1. En el paso 3, la información del recibo se almacena en el dispositivo del usuario. Si el usuario desinstala y vuelve a instalar su aplicación, la información del recibo se perderá. Pero puedes restaurarlo; Apple habla de eso here . Puede reenviar un recibo restaurado a su servidor. En tu servidor, verificas eso más Gemas para el usuario para que pueda recibir lo que debería ser.

  2. Fue devuelto automáticamente, ya que las gemas no fueron recibidas.

    Esto parece imposible con IAP porque Apple no permite que un usuario cancele su compra. (Con Google IAB, se permite el reembolso, más sobre eso here )

En general, parece que sufres del problema de los dos generales, que era

El primer problema de comunicación de la computadora que se demostró que no puede resolverse.

Como en todas partes de su protocolo de comunicación se puede perder un mensaje (incluso el reconocimiento o el reconocimiento del acuse de recibo o el ...) no puede estar 100% seguro de que ambas partes de la comunicación (el dispositivo del usuario y su servidor) han acordado lo mismo estado. Solo puede decir que, con cierta probabilidad, la información de estado se ha intercambiado con éxito.

Enviaría un par de ACK de ida y vuelta y almacenaría la compra si se consiguiera un número suficiente. Cita de Wikipedia:

Además, el primer general puede enviar una marca en cada mensaje diciendo que es el mensaje 1, 2, 3 ... de n. Este método permitirá al segundo general saber qué tan confiable es el canal y devolver un número apropiado de mensajes para garantizar una alta probabilidad de que se reciba al menos un mensaje.

Para la satisfacción del cliente, tomaría las probabilidades a su favor: el 1% de los productos no entregados le causarán muchos problemas, pero la pérdida del 1% de su lado es aceptable.

No tengo mucho conocimiento sobre Android, pero después de leer tu publicación, me interesó mucho la búsqueda detallada y más detallada sobre cómo funcionan los juegos como la lucha de clanes en la lógica de compra de aplicaciones y cómo evitar la libertad .

Después de investigar un poco, me gustaría compartir mis pensamientos sobre su problema. Puede implementarlo siguiendo este enfoque :

Haga su verificación de compra en aplicación completamente en línea. Por ejemplo, puedes considerar el choque de clanes del juego.

Cómo funciona:

1) Cargas de juego, sincronizadas con el servidor. Se requiere conexión a la red, ya que la conexión a la red interrumpe la recarga del juego desde el servidor.

2) El usuario tiene 10 gemas, el servidor también tiene 10 gemas.

3) Las gemas compradas por el usuario, el servidor verifica la compra por separado para los consumibles comprados, gemas acreditadas en la cuenta del usuario.

4) Si falla la red, entonces el servidor también puede verificar la compra y luego actualizarla en la cuenta del usuario, ya sea en cualquier dispositivo.

5) Esto también te ayudará a evitar muchos trucos falsos en la compra de aplicaciones, como la freedom ( prevention ) y la suerte .

Google proporciona una API para el lado del servidor para verificar u obtener detalles de la compra y cuando la compra del lado de la aplicación y el servidor coinciden, entonces solo acreditará gemas o artículos consumibles en la cuenta de los usuarios.

Para obtener más información acerca de las compras en la aplicación y sus prevención de piratería, puede visitar estos enlaces:

1) Verificación del lado del servidor de la aplicación comprada parte 1 y parte 2 .

2) ¿Cómo verificarías en el lado del servidor de facturación de compras de aplicaciones ?

3) Verificar la compra a través de PHP .

4) Seguro en el escenario de compra de aplicaciones en el servidor web .

Espero que esto te guíe en la dirección que quieres ir, también me encantaría escuchar tus pensamientos sobre el mismo.

Puedes intentar restaurar las compras en la aplicación realizadas con una cuenta en particular.

La función se proporciona solo para este caso cuando se realizó el pago y el usuario no recibió los artículos que le prometieron o cuando cambió de dispositivo.

Al restaurar la compra, recibirá nuevamente el producto comprado del servidor de iTunes y, por lo tanto, podrá notificar a su servidor.

Teniendo en cuenta que las gemas son una moneda virtual, entonces el tipo de producto natural en la aplicación debe ser consumible , es decir, no son compras recuperables.

Para consumir una compra con una compra de Google Play, llamará consumePurchase . En iOS, llamará finishTransaction en SKPaymentQueue . En ambos mercados, la compra de consumibles permanecerá en un estado activo hasta que se hayan consumido. Si el usuario elimina la aplicación de su dispositivo antes de que se consuma la compra, podrá volver a instalarla y restaurar sus compras anteriores no consumidas.

Entre la compra inicial y el consumo es donde desea colocar la validación del lado del servidor. Cuando se realice una compra, envíe el recibo o el token a su servidor, realice la validación y responda en consecuencia. La aplicación debe esperar una respuesta válida del servidor antes de consumir la compra.

(Tenga en cuenta que las compras consumidas no aparecerán en la colección in_app en un recibo de iTunes. Sólo están presentes si la compra aún no se ha consumido).

Si se agota el tiempo de espera del servidor o se pierde la conectividad de la red, las compras permanecerán en un estado activo y la aplicación debería continuar intentando enviar los detalles periódicamente hasta que reciba una respuesta que está esperando.

Las compras tanto para Google Play como para iOS se almacenan localmente, por lo que solo tendrá que ejecutar un proceso que busque las compras no realizadas una vez que se restablezca la conectividad de la red.

Puede tratar el aprovisionamiento de gemas de la misma manera que un banco maneja los depósitos de cheques; el nuevo saldo se actualizará de inmediato, pero la cantidad que se puede gastar no coincidirá hasta que se borre el cheque (o en su caso, una validación).

Algún pseudo código para aclarar el proceso:

Purchase product or Restore purchases While consumable purchases > 0 Send purchase receipt to API If response is ok If purchase is valid Consume product Allocate gems Break Else Remove retroactive gem allocation Discipline the naughty user Break Else Retroactively allocate un-spendable gems Pause process until network is re-established Re-send receipt to API