Cómo no perder dinero en la caja negra: métodos de prueba de facturación

La validación de los servicios pagos es uno de los principales problemas de ingeniería en las pruebas de Badoo. Nuestra aplicación está integrada con 70 proveedores de pago en 250 países del mundo, y un error en al menos uno de ellos puede tener consecuencias impredecibles.

En este artículo, hablaré sobre los métodos de prueba que usamos en Badoo y los límites de aplicabilidad de estos métodos, las etapas de prueba en las que son más efectivos.

Este artículo será útil para probadores, desarrolladores y gerentes de productos, cuyos proyectos ya están integrados con proveedores de pagos, o el proceso de integración recién comienza. Si en su trabajo se enfrenta con el problema de elegir métodos de prueba para tales integraciones, ¡bienvenido a cat!




Mi nombre es Vladimir Solodov, soy ingeniero de control de calidad de facturación en Badoo: me encargo de verificar las integraciones de prueba y el procesamiento de pagos. Mi colega Viktor Koronevich me ayudó a preparar el texto: junto con él elaboramos un informe en la conferencia de Heisenbug ( video ). En el artículo, ampliamos el área de descripción a todas las integraciones con proveedores de pago que se usan en Badoo, clasificamos y describimos la práctica de eliminar dependencias externas con más detalle.

Utilizando los estudios de casos de negocios como ejemplo, le diré por qué debería prestar más atención a probar los servicios pagos y cómo no agravar los problemas si, sin embargo, surgen. Y luego describiremos los problemas técnicos de probar la integración y las formas de resolverlos.

La segunda parte del artículo, en la que hablamos más sobre la automatización de probar servicios pagos en aplicaciones iOS, está aquí .

Vamos!

Datos específicos de la prueba de facturación

Por lo general, el objetivo de un negocio es generar ingresos. En Badoo, una red social para citas, los ingresos se obtienen mediante préstamos y suscripciones premium. Los préstamos son la moneda interna de Badoo. Con su ayuda, por ejemplo, puede elevar su perfil en los resultados de búsqueda en primer lugar, hacer un regalo a otro usuario y más. La suscripción premium es válida por un cierto período de tiempo y le brinda varias opciones a la vez: active el modo "invisible", vea a las personas que han mostrado interés en usted, confirme la autenticidad de su cuenta y mucho más.

Para que estos servicios pagos funcionen, utilizamos integraciones con más de 70 proveedores de pago. La elección del proveedor depende de la plataforma, el país, el dispositivo, el operador móvil y otros factores. Por lo tanto, la cuestión de probar los servicios pagos es muy urgente.

Para comenzar, considere por qué las pruebas de servicios pagados deben abordarse con especial atención. Hay dos razones

1. Los errores de facturación son críticos para los negocios.

El primer problema es de reputación. El usuario que pagó por el servicio se vuelve más sensible (y menos tolerante) a los errores en la aplicación. Cualquier comentario en el espacio público, ya sea una revisión de una aplicación de blog o un comentario en la App Store o Google Play, de un usuario que encuentra un error en un servicio pago, será más emotivo: este es un factor que conduce a la pérdida de reputación.

El segundo problema es que, tan pronto como comienza a recibir dinero de un usuario para un servicio, se convierte en objeto de una ley que protege al consumidor del servicio. Y las pérdidas de reputación pueden convertirse fácilmente en financieras.

Las empresas pierden dinero de tres maneras.

La primera forma es reembolsos . Supongamos que un usuario descubre que le ha vendido un servicio que no cumple con sus expectativas. En este caso, se pondrá en contacto con su equipo de soporte. Sus empleados realizan una investigación y descubren que las expectativas del usuario realmente no se materializaron debido a un error en la aplicación. Usted inicia un reembolso. En este caso, hay un reembolso: como resultado, la empresa se enfrenta a la pérdida de beneficios, y esta es la forma más inofensiva de perder dinero.

La segunda forma es contracargos . Supongamos que ocurre la misma situación, solo el usuario no se comunicó con su servicio de soporte, sino con el banco que le emitió la tarjeta o el proveedor de pagos. El banco / proveedor inicia un reembolso. En este caso, estamos lidiando con un contracargo. El peligro para los negocios aquí no es solo la pérdida de ganancias. Después de un cierto número de contracargos, la empresa recibe una multa y su calificación de riesgo disminuye. La rebaja, a su vez, conduce a un aumento en el costo de los servicios de los proveedores de pagos.

La tercera vía: demandas (reclamos) . En los casos más descuidados, pueden llevarse a cabo demandas (incluidas las colectivas), lo que lleva a las consecuencias más graves. Entonces, en 2015, después de una demanda por parte del regulador de Ofgem, British Gas se vio obligado a pagar una compensación multimillonaria a los usuarios que cobraron una tarifa más alta debido a un error en el sistema de carga. Lea más sobre esto aquí .

2. Para probar integraciones, se necesitan conocimientos y experiencia.

Los equipos que recién comienzan el proceso de integración con los proveedores de pagos a menudo enfrentan este problema. Sin conocer todos los posibles casos de facturación, pierden matices importantes cuando se dan cuenta de la reacción del sistema a las notificaciones de los proveedores de pagos.

Esto puede llevar a consecuencias impredecibles, desde ganancias perdidas hasta usuarios insatisfechos.

Veamos el esquema que enumera los tipos de servicios pagos y consideremos el problema con más cuidado.


Figura 1. Posibles casos de facturación

Hay tres casos principales: un error, un pago exitoso y un reembolso al usuario. Pero cada caso tiene detalles, cada caso que su sistema tiene que manejar de manera diferente.

Los errores pueden ser críticos y no críticos. El error de notificación se puede atribuir a no crítico, cuando el proveedor de pagos informa sobre la falta de fondos en la cuenta del usuario, y crítico, el bloqueo del método de pago del usuario. Y si en el primer caso puede intentar pagar más tarde, en el segundo, sería bueno saber por qué el método está bloqueado. Quizás el usuario fue notado en fraude y usted debería ser más cuidadoso con sus transacciones.

Reembolsos Ya sabe que hay dos tipos de devoluciones: reembolsos y devoluciones de cargo. Su sistema debe responder de manera diferente a ellos. Por ejemplo, después de una devolución de cargo, tiene sentido pensar en bloquear algunas funciones de su aplicación para el usuario, porque la devolución de cargo es uno de los métodos de fraude más populares.

Un pago exitoso puede ser un pago único o puede ser una suscripción.

Los pagos únicos pueden ser consumibles y no consumibles. Un ejemplo de un pago gastado, lo examinamos al comienzo del artículo: estos son préstamos en Badoo. Se puede dar un ejemplo de un pago no prescindible de los juegos. Supongamos que tienes un personaje que juegas. Desea comprar para él superpoderes que han existido durante algún tiempo. En este caso, la compra pertenece a la clase de pagos no prescindibles.

Suscripciones Aquí está la mayor variedad de casos. Además de la compra inicial de una suscripción, puede tener:

• renovación de una suscripción (renovar);
  
• cerrar suscripción (cancelar suscripción);
  
• suscripción de prueba (prueba);
  
• suscripción al período de gracia: cuando no podemos renovar la suscripción e intentamos pagar nuevamente por un período de tiempo llamado período de gracia. Para el usuario, el período de gracia se ve así. Suponga que compró una suscripción mensual al periódico. La compañía que le envía periódicos está tratando de cancelar el pago para el próximo mes de suscripción después del final del primer mes, pero no puede hacerlo (debido a un bloqueo de tarjeta, falta de fondos en la cuenta, etc.). Si el período de validez del período de gracia es de diez días, durante este tiempo la compañía intenta cancelar el pago, mientras que la suscripción sigue siendo válida. Si la empresa no puede cancelar el dinero, la suscripción se cancela. Si es así, la suscripción se renueva a partir de la fecha del último pago;
  
• pago parcial (facturación parcial). Por ejemplo, PayPal le permite realizar pagos parciales si la cuenta del usuario no tiene fondos suficientes (pago parcial) o dividir el pago en partes (factura parcial).
  

También debe tener en cuenta dos características que dependen completamente del proveedor de pagos: la suscripción puede ser controlada por su aplicación o administrada externamente.

• Una suscripción administrada internamente es, por ejemplo, una suscripción que utiliza tarjetas de crédito o PayPal, cuando después del primer pago se le entrega un token con el que vuelve a presentar una solicitud al proveedor, sin tener los detalles de pago del usuario.
  
• Una suscripción administrada externamente es cuando el agregador de pagos toma el control total de sus suscripciones y simplemente le envía notificaciones sobre sus estados actuales.
  

En la figura, las áreas más obvias, cuya reacción generalmente se realiza en primer lugar, están resaltadas en púrpura. Todos los demás comienzan a tenerse en cuenta mucho más tarde, como la acumulación de experiencia. Esto se ve facilitado en gran medida por la aplicación incorrecta de metodologías de desarrollo iterativo en el campo de la facturación.


Figura 2. Casos de facturación que se implementan principalmente en sistemas

Tal implementación por etapas puede conducir a consecuencias impredecibles. Por ejemplo, en uno de los proyectos en los que trabajé antes de Badoo, no se tuvo en cuenta la posibilidad de hacer un reembolso. Como resultado, todos los retornos se realizaron no a través de reembolsos, sino a través de devoluciones de cargo, lo que afectó negativamente la calificación de riesgo de la compañía y condujo a fallas en la recolección de estadísticas de ingresos. La ignorancia de toda la variedad de casos de facturación puede conducir a la pérdida de ganancias o a la vulnerabilidad de la empresa a los usuarios que se sienten engañados.

Por lo tanto, por un lado, los errores en el procesamiento de pagos deben encontrarse antes del lanzamiento, ya que pueden tener las consecuencias más negativas. Si esto no fuera posible, es importante comprender lo más rápido posible que el error entró en la versión de lanzamiento de la aplicación, solucionarlo y, lo más importante, lo que muchas personas olvidan, "tranquilizar" a los usuarios que se encuentran con este error.

Por otro lado, la situación se complica por el hecho de que la integración con los proveedores de pagos es siempre una interacción con el recuadro negro, que agrega muchas variables al proceso de prueba.

Problemas técnicos durante las pruebas de facturación

Consideremos el ejemplo de la integración de Badoo con la App Store.

Las suscripciones en la App Store pertenecen a la clase de administración externa, es decir, se administran completamente del lado del proveedor, y nuestro sistema solo puede solicitar el estado actual o recibir una notificación de su cambio.

Elegimos específicamente esta integración, ya que es la más compleja y contiene toda la variedad de casos que se pueden encontrar en el proceso de integración del servicio con otros proveedores de pagos.

Para empezar, recurrimos a una compra desechable por única vez.


Figura 3. El proceso de hacer un pago prescindible por única vez

En el paso 1, el usuario realiza una solicitud para comprar el servicio. La aplicación decide que se debe realizar el pago y, en el paso 2, el control se transfiere al proveedor de pagos (App Store). Paso 3: se le presenta al usuario un formulario para realizar un pago. Paso 4: el usuario proporciona datos para el pago. Paso 5: el proveedor completa la transacción e informa el resultado a la aplicación, devolviendo un recibo que contiene información completa sobre la compra (fecha, servicio, estado, etc.). Paso 6: el cheque, complementado con los datos del usuario, se envía al servidor para su procesamiento. El servidor procesa los datos de verificación y genera una notificación push para la aplicación en el séptimo paso. En el octavo paso, la notificación se muestra al usuario.

El problema es que los pasos 3, 4 y 5 se realizan del lado del proveedor de pagos, prácticamente no están controlados por nosotros y pueden tener varias variaciones. Por lo tanto, el proceso en realidad no tiene una estructura lineal, como se muestra en la Figura 2, sino una ramificación (ver Figura 4), y cada rama debe ser manejada de manera diferente por la aplicación.


Figura 4. Ramificación de un diagrama de estado de pago único

La compra de suscripciones comienza de la misma manera que un pago único, pero el control adicional del proceso es bastante difícil de controlar.


Figura 5. Estados de suscripción gestionados externamente

Permítame recordarle que la suscripción de Apple, que consideramos como un ejemplo, se administra de forma externa. Esto significa que el usuario después de la compra puede administrarlo de forma asíncrona: cerrar, cambiar la fecha de vencimiento, solicitar un reembolso. Vemos esto en el paso 9. Dado que la acción se lleva a cabo fuera de nuestro sistema, en la figura la marqué con una línea de puntos.

En el paso 10, App Store puede cambiar el estado de la suscripción: renovar, cerrar, ingresar el período de gracia en la ventana.

Para que podamos averiguar en qué estado se encuentra la suscripción, hay un paso 11, que es específico para los agregadores como App Store y Google Wallet. En este paso, el sistema envía un token, que se utiliza como un recibo recibido al principio al comprar una suscripción o después de su renovación anterior.

El paso 12 es la respuesta del proveedor. Recibimos un cheque con el estado actual de la suscripción. El resultado en este paso depende de los pasos asincrónicos 9 y 10.

En el otoño de 2018, Apple implementó un mecanismo de notificaciones de servidor a servidor , que le permite notificar los cambios que se han producido con una suscripción. La recepción de dicha notificación se muestra en el paso 13. Para la mayoría de los otros proveedores, el mecanismo de notificación de servidor a servidor es el único, por lo que se puede argumentar que el ejemplo de Apple cubre toda la variedad de casos. En el caso de otros proveedores, el paso 13 le permite excluir los pasos 11 y 12 del esquema.

En el paso 14, el servidor genera una respuesta para que la aplicación cambie el estado de la suscripción.

Por lo tanto, obtuvimos un gráfico completo de los estados que se deben aprobar para verificar los servicios pagados.


Figura 6. El proceso completo de cambio de estados de pago (usando un ejemplo de suscripción administrado externamente)

Las partes que no controlamos en nuestro sistema están coloreadas en naranja y son cajas negras para nosotros.

Métodos de prueba de facturación

Por lo tanto, el principal problema técnico al probar servicios pagos es la presencia de "cajas negras", cuyos estados tenemos muy poco control. Esto define un conjunto de métodos que pueden cubrir toda la variedad de casos.

No hay muchos de estos métodos, y los dividimos en tres categorías: pagos reales, cajas de arena y eliminación de dependencias externas de las "cajas negras".

Pagos reales

Los pagos reales como método de prueba son buenos porque dan una idea clara del estado de integración. Un error al hacer un pago real es una evidencia incondicional de un error.

De lo contrario, los pagos reales son malos. En primer lugar, es costoso: es obvio que para realizar un pago real, debe gastar dinero real. Se equivoca si cree que al final se devolverá el monto total a la empresa: en primer lugar, los proveedores cobran una tarifa por cada transacción, cuyo tamaño, como se describe anteriormente, depende de la calificación de riesgo de la organización y puede alcanzar el 40% (e incluso más) ; en segundo lugar, puede perder dinero al probar pagos en otros países debido al diferencial de divisas: la diferencia entre las tasas de compra y venta de la moneda (realizará la compra a la tasa de venta de moneda extranjera del banco, y la devolución se realizará a la tasa de compra).

Además, este método puede llevar mucho tiempo, ya que debe esperar hasta el final del período de renovación de la suscripción, la finalización de los períodos de gracia y estos pueden ser meses.

Cajones de arena

Las cajas de arena son hermosas. De hecho, esta es la misma funcionalidad que nos brinda un proveedor de pagos en el caso de un pago real, pero sin gastar dinero real. Es totalmente compatible con el proveedor, lo que significa que la integración con el sandbox es barata.

El problema de la duración de las pruebas a lo largo del tiempo se resuelve, por regla general, utilizando varios trucos. Por ejemplo, el sandbox de App Store usa la siguiente conversión de caducidad de suscripción.

Tabla 1. La relación del período de validez de una suscripción real y una suscripción en el sandbox de Apple

Las suscripciones de sandbox predeterminadas de Google Wallet se enumeran en la tabla 2 y se pueden configurar en la consola del vendedor.

Tabla 2. Configuración de la duración de una suscripción en el sandbox de Google

A diferencia del sandbox de Apple, también puede verificar la versión de prueba, el período de gracia, etc., en el sandbox de Google, utilizando la proporción de la Tabla 3.

Tabla 3. Validez de las características de suscripción adicionales en el entorno limitado de Google

El cierre de una suscripción también se puede implementar de diferentes maneras: en el sandbox de App Store, el cierre se realiza después de la quinta renovación, y en Google Wallet se realiza desde la consola del vendedor o en el dispositivo desde Play Store.

El problema con los sandboxes es que los proveedores tienen una actitud diferente con respecto a su calidad. Nuestra experiencia muestra que de los más de 70 proveedores de pagos que están integrados en Badoo, solo dos sandboxes cuentan con funcionalidad completa y operación estable. Estas son las cajas de arena de Adyen y PayPal. Otros proveedores tienen funciones estables, pero truncadas en términos de funcionalidades (como Google Wallet), o inestables y muy truncadas en funcionalidad (como App Store y Fortumo). Y hay proveedores que no tienen ni van a tener una caja de arena.


Figura 7. Clasificación de sandboxes por estabilidad y funcionalidad.

Eliminar dependencias externas

Si lo convencimos de que las pruebas con pagos reales son costosas e ineficientes, y los proveedores de pagos no proporcionan cajas de arena de calidad adecuada, entonces queda por recurrir a varias formas de eliminar las dependencias externas. Solo hay tres de ellos: moki, falsificaciones y trozos.

Moki en la facturación es la formación de las reacciones de su sistema a las solicitudes con parámetros predeterminados sin una llamada real al proveedor de pagos (ver Fig. 8). Por ejemplo, una solicitud a un proveedor de pagos por SMS al número + 7111-111-11-11 se intercepta en la etapa de enviar una solicitud al proveedor y genera una respuesta del sistema en forma de un pago exitoso. La solicitud al número + 7111-111-11-12 también se intercepta, pero provoca una reacción a un error con el código "No hay suficiente dinero para completar la transacción".


Figura 8. Diagrama simulado

Las falsificaciones en la facturación son falsificaciones de notificaciones (como si vinieran de un proveedor real) (ver. Fig. 9). La integración con cada proveedor implica un conjunto limitado de reacciones del sistema a un conjunto limitado de tipos de notificaciones o restablecimientos. ( ), .


9.

— (. . 10), .


10.

, , . (, , ) . , , , , .

. 3, 4, 5 : , . - : , — , — . « ».


11. ( App Store)

, (, ). — , . . , , , . , . , .

. , ? :

• — ?
  
• end-to-end — : - ?
  
• — : , .
  

.


4.

. . . , . : , .

. , , Apple Google, . ( ). end-to-end : . , , .

, , — . . . : .

, , .

, . .

: . , , — .

, : — , , ; — : .


12.

, , , , .

, 12, Badoo.

. . QA- . , . , - , , . , .

: .

, , — . , Apple . . , . : - .

— , . -, . -, , -, , .

— : , Apple . 1 — , .

. , . , - .

, ( ).

Conclusiones

1. , .
   
2. ( ) . , .
   
3. « » , . - — . , : , — , — .
   
4. Al utilizar falsificaciones, mokas y talones, es importante recordar que estos son modelos de pago reales y, como cualquier modelo, tienen un grado de aproximación a la realidad y los riesgos. Estos riesgos deben evaluarse y cubrirse mediante pagos reales o mediante controles adicionales.
   

Sobre cómo logramos lograr una automatización estable y económica de probar servicios pagados en una aplicación iOS, hablamos en el próximo artículo .

Gracias por su atencion! ¡Todas las grandes ganancias y menos errores!