De Frágil a Preparado para el Futuro: Resolviendo el Caos de la Monetización Web con Sistemas de Pago que Escalan

Hola a todos. Gracias por venir a mi charla de JS Nation. Estoy realmente emocionado de presentar un tema que ha estado muy cerca de mi corazón en los últimos años, y se trata de la monetización y cómo llevar sistemas de pago que escalen a tus sistemas frontend. Y hoy, vamos a hablar un poco sobre cómo llevar eso al ámbito de React. Y la charla se llama específicamente De Frágil a a Prueba de Futuro, ¿Cómo Resuelves el Caos de la Monetización Web con Sistemas de Pago que Escalan?

Y la forma en que me gusta comenzar esto es un poco con una historia. Y así, trabajo en SmallPDF. Y SmallPDF es una plataforma donde tenemos decenas de millones de usuarios por mes y procesamos pagos en múltiples países alrededor del mundo. Y así, con uno de los proveedores de pago que tenemos, y uno de esos proveedores se llama Braintree, tuvimos una interrupción hace un par de meses. Y en esa interrupción, en realidad perdimos la integración con Braintree porque una de nuestras claves API fue eliminada por error.

Y cuando esas claves API fueron eliminadas, de repente comenzamos a recibir un montón de errores 401, y no sabíamos qué estaba pasando, y cada pago estaba fallando. Y Braintree esencialmente nos ayudaba a procesar todos nuestros pagos de PayPal y tarjetas de crédito en la mayoría de nuestros países. Así que eso significa que ningún usuario pudo procesar ningún pago, crear ninguna suscripción, porque dependíamos en gran medida de Braintree como sistema de procesamiento. Y eso es realmente caótico. Y este problema ocurrió muy, muy tarde en la noche, y tomó mucho tiempo resolverlo. Así que tomó mucho tiempo para que el sistema de alertas nos dijera que algo estaba pasando.

que está funcionando 24/7, y algo empieza a ir mal, las cosas empiezan a ponerse bastante mal rápidamente. Así que esto es en realidad una captura de pantalla de nuestros paneles de TrackJS. Este es el equivalente de tu panel de Sentry, que utiliza una plataforma diferente para eso. Y puedes ver que de repente, hay un pico masivo, un pico en estos errores de obtención de tokens de Braintree. Y esos son exactamente los errores que estamos enfrentando porque la clave API fue eliminada. Y eso duró por un largo período de tiempo. Y fue realmente difícil discernir anomalías, porque había tanto mar de errores y registros llegando, que era muy difícil poder determinar qué estaba pasando.

Avanzando, puedes ver aquí en nuestro panel de data doc, ahora hay un registro de la cantidad de suscripciones que creamos. Y ese mismo período de tiempo, ese mismo intervalo de tiempo, donde vimos todos esos errores subir con TrackJS, ahora puedes ver que todas las creaciones de suscripciones se detuvieron. Y así muestra la correlación directa donde los errores significaban que no podíamos procesar suscripciones. Eso tiene sentido. Ahora verás que todavía hay algunos pequeños picos allí. Eso aún muestra que pudimos procesar algunas suscripciones. Y te mostraré por qué ese es el caso. Porque Braintree no era la única pasarela que estábamos usando en ese momento, también estábamos usando Adyen y algunas otras pasarelas para procesar otros pagos. Pero aún no era la mayoría de nuestros volúmenes, vimos una caída masiva.

Ahora, ¿qué tan grave fue este incidente? Duró desde las 9pm hasta las 10am. Así que horas de trabajo, ¿verdad? En realidad, sí, claramente después de las horas de trabajo, todos trabajamos en horarios suizos en SmallPDF, la oficina principal está en Zúrich. Y así que la gente probablemente estaba en medio de su cena o preparándose para ir a la cama. Y quienquiera que recibió esa alerta no estaba teniendo una gran noche. Si eres bueno en matemáticas, eso se traduce en alrededor de 12 horas de inactividad, lo cual no es poco tiempo. Así que durante 12 horas, nadie pudo crear una suscripción. Y más allá de eso, eso se traduce en cinco a diez mil dólares en suscripciones perdidas. Eso no es poco dinero. Y vamos a explorar algo que va a cambiar eso.

Entonces, ¿quién soy yo? Mi nombre es Faris, soy ingeniero de software en small PDF. Así que hacemos todo en términos de cosas de PDF, en términos de fusionar PDFs, comprimir cosas con un conjunto de herramientas realmente genial, todo está en la web. Y tenemos como un montón de usuarios, como mencioné anteriormente. Así que cuando algo sale mal, sale mal muy, muy rápido. Parte de mi experiencia previa es en el mundo de la TV conectada, habiendo trabajado en aplicaciones como Eurosport, GCN, Discovery Plus, trabajé en equipos de crecimiento y FinTech, estoy realmente interesado en los sistemas de pago en particular, y también en el rendimiento web y liderazgo en ingeniería. De vez en cuando, trabajo en algunos proyectos de código abierto, incluyendo algunas extensiones de Raycast, actualmente estoy en medio de renovar la extensión de Stripe en Raycast, algo que disfruto mucho haciendo, porque Raycast es realmente increíble. Y también creo que recientemente han llegado a Windows y iOS. Así que estoy realmente feliz de haber visto eso expandirse más allá del ecosistema Mac.

Y también soy cofundador de Zurichess, que son los encuentros de JavaScript que organizamos en la región de Zúrich. Entonces, ¿cuáles son los desafíos con los sistemas de pago? Si estás construyendo cualquier plataforma SaaS, es muy probable que quieras cobrar a los usuarios ya sea de manera única o de manera suscripción. Y solo porque estoy trabajando en desarrollar mis aplicaciones en Suiza, eso no significa que no quiera procesar pagos en todo el mundo. En Suiza, usamos francos suizos, cada vez que viajo a otro lugar, cada vez que viajo a Francia o Alemania, uso euros. Así que muchos de nosotros, por ejemplo, tenemos tarjetas Revolut o tarjetas Monzo, porque el tipo de cambio es realmente favorable cuando usas esas en lugar de tus tarjetas de crédito que tienen muchas tarifas.

Sabes, esas son las cosas que empiezan a entrar en juego cuando quieres expandir tus oportunidades de pago para tu plataforma SaaS. Así que como mencioné, está ese problema de la moneda y las tarifas de FX, donde si estoy tratando de comprar, ya sabes, un producto en Suiza, o quiero mi suscripción a Netflix, esencialmente en Suiza, quiero pagar francos suizos por eso, no quiero estar pagando un tipo de cambio o además de eso tarifas de tarjeta de crédito para poder procesarlo. Y también hay una asociación con la confianza. Y un negocio dependiendo de si estás ofreciendo precios localizados o no. Y precios localizados no solo significa que te estoy dando una moneda que es local a donde sea que estés, como sabes, dólares estadounidenses en los EE.

Luego está también el tema de optimizar los métodos de pago por país. Ahora en Suiza, tenemos un método de pago llamado twint. Cualquiera que no esté en Suiza casi nunca habrá oído hablar de ese método de pago. Y si vas a China, está Alipay. Si vas a Tailandia, hay pagos basados en códigos QR. Y estos son los sistemas que se utilizan para procesar pagos a diario, lo que significa que son sistemas sin fricciones. Así que cada vez que pago por un servicio en Suiza, usar twint es 10 veces más rápido que ingresar los detalles de mi tarjeta de crédito. Y así tengo una probabilidad mucho mayor de convertir y suscribirme a un producto si estoy usando un método de pago local. Y lo realmente interesante de eso es que pueden tener un impacto realmente grande desde una perspectiva de conversión en tu producto si puedes soportar métodos de pago que son solo locales para la región en la que estás operando.

Como mencioné, tenemos twint en Suiza. En Brasil, hay Transferencias Bancarias PIX. En India, está UPI. Y sabes, la tarjeta de crédito se usa muy poco, el 80 al 90% de los pagos se realizan a través de UPI, es dominante allí. Para los Países Bajos, por ejemplo, son pagos ideales. Y así puedes ver que cada país y región tiene su propia forma única de pagar las cosas. Así que empieza a tener un poco de sentido en la historia si queremos que nuestro producto SaaS también pueda soportar cosas para las regiones locales en las que quieren operar.

Ahora a principios de este año, en small PDF, introdujimos Alipay en nuestro producto. Y Alipay permitió que los usuarios en China tuvieran mucho más fácil suscribirse a la plataforma en lugar de ingresar su información de tarjeta de crédito. Y eso en realidad llevó a un aumento de 3.5x en los ingresos recurrentes anuales. Solo al no cambiar los precios, sino solo cambiando el método de pago utilizado por las personas en China, fue mucho más fácil suscribirse a esa plataforma. Y así realmente te muestra el poder de introducir métodos de pago basados en la región que están optimizados para eso. Hay otra parte de la historia, que es también la regulación y el cumplimiento.

Por ejemplo, con los pagos UPI en India, generalmente necesitas una entidad allí. Y así, para muchos procesadores de pago, necesitas una entidad en la región en la que deseas operar. Así que si de repente tu negocio está en Suiza o tu negocio en el Reino Unido y quieres operar en otros países, no vas a empezar a abrir entidades por todas partes. Aquí es donde los merchant of records se convierten en una solución realmente interesante porque se encargan de la gestión de entidades como parte de la solución. Sin embargo, tienen tarifas mucho más altas asociadas con ellos, y a veces hay algunos factores limitantes allí. Pero no solo está el problema de la entidad, también hay países sancionados.

Así que si hay países y monedas que desde una perspectiva legal o política, están un poco políticamente tensos en ese momento, y ya no quieres poder operar en ellos. De lo contrario, digamos que no puedes operar en el país X, y Stripe va a cortar tus pagos como resultado de operar en el país X, o sabes, proporcionar el servicio Y, quieres poder tener una manera realmente fácil de poder redirigir los pagos fuera de ese país o deshabilitar eso. Así que tener configurabilidad ahora se convierte en algo realmente importante y parte de la responsabilidad de un negocio para poder operar de manera conforme.

Así que hablamos de esos países sancionados y transacciones sancionadas, y ningún negocio y ninguna entidad local para poder tener ciertos pagos en ciertos lugares como en India. Cuando se trata de regulación y cumplimiento, también está el tema de países sancionados y transacciones restringidas. Hay simplemente ciertas, ya sabes, transacciones que no puedes hacer desde una perspectiva financiera, y cada país y cada proveedor de pagos tiene su propio umbral de riesgo, ya sea por devoluciones de cargo, disputas, ya sea por, ya sabes, tipos particulares de transacciones basadas tal vez en tu tarjeta de crédito y ubicación, ya sabes, la tasa de fraude es particularmente alta, o simplemente para países políticamente tensos donde no quieres poder operar allí, porque entonces tu proveedor de pagos puede cortar tu capacidad de operar. Y eso significa que sufres en términos de tus ingresos en otros países.

Así que tener la capacidad de redirigir pagos o poder gestionar tus responsabilidades es realmente importante cuando estás operando en más de 100 países. Y luego, como también dijimos, el tema del merchant record es realmente interesante cuando se trata de no tener, ya sabes, entidades comerciales locales en todas partes. Así que a veces simplemente no puedes ni siquiera operar pagos en ciertos lugares. Y luego, por supuesto, está ese cumplimiento dependiente del país.

Un dato interesante es que en los EE. UU., hay 11,000 jurisdicciones fiscales separadas.

Así que los impuestos también son algo grande que necesitas poder a veces configurar por país. E incluso no por país, puede incluso ser diferente a nivel de calle en los EE. UU. Y eso es realmente, realmente complicado de manejar.

Si tu tasa de devoluciones de cargo y disputas se vuelve demasiado alta. Así que ya sabes, te suscribes a algo en una plataforma. Y luego más tarde llamas a tu banco como ya no quiero suscribirme a Netflix.

Y así el banco es el que, ya sabes, tiene la disputa o tu compañía de tarjeta de crédito tiene la disputa. Hay muchos cargos que vienen con disputas. Y si demasiados usuarios están solicitando reembolsos y disputas, un proveedor de pagos como Adgen o Stripe, tienen sus propios umbrales de riesgo y simplemente van a decir que ya no quieren procesar pagos contigo, el umbral de riesgo es demasiado alto.

Así que de nuevo, cuando las disputas se calientan demasiado, si dependes de un solo proveedor, a veces puedes encontrarte en una situación donde el proveedor simplemente desconecta, y has perdido toda la capacidad de poder, ya sabes, procesar dinero o recibir fondos. Luego también está finalmente la fiabilidad y el tiempo de actividad. Ahora muchos proveedores apuntan a los cinco nueves, que es 99.

cinco nueves, que es 99.999% de disponibilidad, lo que significa que se permite alrededor de cinco a seis minutos de inactividad por año si deseas cumplir con ese SLA. Incluso si miramos solo los tres nueves 99.9% de disponibilidad, eso significa alrededor de ocho horas y 45 minutos de fallos en un año de un sistema. Ahora, lo interesante de algunos de estos proveedores de pago es que, aunque la disponibilidad general del sistema puede ser los cinco nueves, los métodos de pago individuales pueden no tener esa disponibilidad de cinco nueves. Así que si alguna vez ves aquí, estos son los problemas pasados que han ocurrido, o el tiempo de actividad de ciertos servicios ofrecidos por Stripe. Así que esta es su página de estado. Y es la historia de interrupciones. Hubo, por ejemplo, horas elevadas de PayPal durante una hora y media. Así que eso ya, por ejemplo, en el escenario de PayPal mata la métrica de disponibilidad de cinco nueves, ya no estás cumpliendo con el SLA, hay 45 minutos de errores elevados de contacto bancario, y luego dos horas de errores elevados de API para otras cosas. Así que los métodos de pago individuales, ya sabes, tienen su propio tiempo de actividad.

No es solo que toda la pasarela esté disponible para métodos de pago individuales accesibles. Eso también es realmente importante. Miramos Braintree y PayPal, hubo una interrupción de ocho horas allí. Y así no habría nada que pudieras hacer. Incluso si es solo la pasarela en sí, o el método de pago, está indisponible ocho horas, mucho tiempo para no poder procesar pagos. Y aquí es donde entra en juego el tema de la orquestación de pagos. Y luego realmente me gusta pensar en esto como control de tráfico aéreo para pagos, podemos dirigir transacciones a la mejor ruta por costo, velocidad y fiabilidad. Y así, este sistema de orquestación de pagos es esta idea de tener un sistema que gestiona múltiples proveedores de pago. Stripe es un proveedor de pago, Revolut es un proveedor de pago, Adgen es un proveedor de pago. Así que orquestar estos juntos se vuelve realmente, realmente poderoso. Y así puedes, de nuevo, enrutar transacciones basadas en costo, éxito o región. Por ejemplo, Stripe optimiza automáticamente el orden de tus métodos de pago si usas su UI de Stripe elements. Pero eso no significa que la optimización predeterminada sea la optimización correcta para ti.

Por ejemplo, si en China, están mostrando Google Pay como la opción principal, pero en los otros siete u ocho métodos de pago disponibles, hay Alipay, y has determinado a través de una prueba A/B que Alipay es el mejor método de pago, puedes querer cambiar el orden tú mismo y tener tu propia optimización que sea mejor para tu SaaS y tu caso de uso. El predeterminado no siempre funciona para todos. Esto también naturalmente nos lleva a un lugar donde estamos reduciendo la dependencia de un solo proveedor para evitar el tiempo de inactividad, lo que significa que si tenemos eso, por ejemplo, una interrupción de ocho horas con PayPal, podemos redirigir a otra pasarela para poder apoyarnos durante ese tiempo. Incluso si esa pasarela tiene una tasa de conversión más baja, aún puedes operar. Y una gran parte de eso es poder optimizar los métodos de pago por país para una tasa de éxito más alta. Y no todas las pasarelas te proporcionan todos los métodos de pago, mezclar y combinar pasarelas te da mucha flexibilidad y poder proporcionar una gama mucho más amplia de métodos. Y si miramos este ejemplo aquí, si estamos comparando Revolut Pay y Stripe Pay, así que estas dos pasarelas, si miramos países superpuestos como el Reino Unido y Francia, puedes ver que las tarifas de Stripe son en realidad 1.5% y dos peniques 2.5% y 2.2 euros.

Entonces, ¿por qué elegirías Stripe cuando en este caso, las tarifas son más bajas, puedes optar por Revolut. En el ejemplo de Chipre y Estonia, Stripe no opera en esas dos jurisdicciones. Así que simplemente no puedes expandir tu plataforma a esas dos jurisdicciones, si estás operando solo con Stripe. Si tuvieras Revolut, podrías aprovechar el hecho de que Revolut sí opera en esos dos países, y podrías expandirte a ellos, lo que significa que podrías llegar a más clientes. En el caso de Stripe, Revolut no opera en EE.UU. o Canadá.

Así que aunque hay tarifas ligeramente más altas, no tienes más remedio que seguir esa ruta para poder expandirte a esos países de alto ARR. Así que entonces puedes ver dónde diferentes pasarelas comienzan a proporcionar diferentes ventajas de una forma u otra. Entonces, ¿cuál es la arquitectura del front end de cómo se ve esto? Ahora, la orquestación de pagos es predominantemente un concepto de back end, algo que se hace en el back end. Así que el front end solo dice que quiero hacer un pago y el back end decide qué hacer. Pero lo que puede ser realmente interesante es poder reaccionar a los estados que desarrollamos en el lado del front end. Y explicaré lo que esto significa en un segundo, y poder mostrar la orquestación correcta, la pasarela correcta, dependiendo del usuario y su contexto. Así que un usuario puede abrir un checkout en nuestra plataforma de front end. Y lo que hacemos es inicializar una capa de orquestación.

Y esta capa de orquestación tendrá su propio conjunto de reglas para decidir qué renderizar en qué momento. Consumirá un estado global, el estado global, ya sea tu estado de Redux, o tus proveedores de contexto, lo que sea, y luego una configuración de reglas. Así que qué hacer en qué escenarios. Y lo que quise decir con consumir el estado global anteriormente es que tu front end conoce el país en el que están los usuarios, el front end puede estar rastreando el estado de las pruebas A/B, tal vez estás ejecutando una prueba en Japón, tal vez estás ejecutando una prueba en Alemania, probando dos diferentes métodos de pago, y luego una lista de monedas que deseas soportar. Y así tal vez elijas una pasarela que coincida con una que ya usas, o elijas pasarelas basadas en experimentos, otros países, todo este tipo de cosas. Lo que harás con esa información es que ahora la llevarás a un árbol de decisiones. Y una vez que se lleva a un árbol de decisiones, sale con una priorización de proveedores de pago. ¿Y por qué optamos por la priorización y no una selección singular? Porque si la pasarela uno está caída, quieres poder recurrir a la pasarela dos. Y así, si miramos cómo puede surgir esta priorización, tenemos tres métodos de pago, pasarelas de pago. En este ejemplo, tenemos Stripe, que soporta Alipay y Yuan chino. Y vamos a tomar el ejemplo de China en este caso, tenemos Revolut que soporta tarjeta de crédito y USD y tenemos Agilent que soporta tarjeta de crédito y Yuan chino. Así que la mejor opción en China es Stripe naturalmente. Pero, ¿qué pasa si Stripe está teniendo tiempo de inactividad ahora mismo? La segunda mejor opción es una que todavía soporta la moneda local. Así que vamos a optar por Agilent como una opción secundaria si Stripe está caído.

Y luego renderizamos ese array y decidimos qué mostrar al usuario. Ahora, en términos de perspectiva de codificación, ¿cómo se ve esto cuando estás manejando múltiples pasarelas de pago, generalmente estás tratando con un SDK de JavaScript diferente? Así que Stripe viene con su antiguo Stripe.js, Agilent viene con uno, Recurly viene con uno. Y lo que termina sucediendo es que recibes muchos componentes de checkout, y recibes muchos proveedores de contexto, tienes tu proveedor de Stripe, tienes tu proveedor de Agilent, proveedor de Revolu, terminas apilando todos esos para pasar todo ese contexto a tu checkout. Y eso puede ser muy abrumador desde una perspectiva de paquete, desde una perspectiva de gestión de estado, no quieres tener que apilar todo eso.

Y así, cuando estás manejando un sistema de orquestación de pagos, idealmente, basado en el estado del usuario en este ejemplo de estar en China y haber seleccionado una moneda de yuan chino, quieres poder simplemente renderizar el proveedor que sea necesario basado en el estado que adquirimos. Así que bien, descubrimos que Stripe era el mejor en los escenarios bajo el capó, estamos renderizando solo el proveedor de contexto de Stripe. Eso es lo que está haciendo. Está minimizando y cargando el código mínimo viable solo para ejecutar el trabajo de checkout. Y veremos que esto ha tenido un cambio realmente significativo en el tamaño de nuestro paquete.

En términos de luego procesar realmente el checkout que recibes de estos SDKs, nuevamente, un montón de diferentes hooks, tal vez hayas usado Stripe, usado Agilent o hayas creado tus propios hooks para procesar pagos, y todos tendrán su propia forma de procesar pagos, hay diferentes claves y parámetros que aceptan. Así que tal vez Stripe acepte una cantidad y una moneda, mientras que Agilent acepte un valor y un código de moneda. Semánticamente, todos significan lo mismo. Pero sintácticamente, están representados de manera diferente. Y tu front end, nuevamente, solo debería preocuparse de que necesita procesar el pago, no cómo está procesando esa pasarela que está usando bajo el capó.

Así que nuevamente, esa capa de abstracción que la capa de orquestación está proporcionando, solo se preocupa de que necesita procesar el pago, va a usar un adaptador bajo el capó para adaptar la pasarela correcta. Cuando se trata de esa configuración de reglas de la que hablamos, podemos ver en realidad aquí cómo se ve una configuración de reglas para una pasarela de pago de Stripe. Así que puedes ver que Stripe está definido, y tenemos algo llamado un criterio de habilitación. Y esto tiene una sintaxis de tipo SQL, o, ya sabes, en términos de entender cómo opera, donde puedes tener operadores or y and para decidir qué incluir y excluir y cómo definir tus condiciones para lo que debería funcionar, lo que debería renderizarse en tu capa de orquestación. Y así puedes ver, para el criterio de habilitación del país, tienes solo en China, así que solo renderiza este método de pago en China, y solo en la pasarela de prueba de Stripe, que es una bandera de característica. Así que si quiero poder habilitar esto en los EE. UU., puedo habilitar una bandera de característica en los EE. UU.

Y también se habilitará a través de un experimento, no solo tengo que depender del país solo. Y luego no hay límites de moneda, ponemos null para las monedas. También hemos definido AliPay como un método de pago. Así que solo porque hayas seleccionado una pasarela en China, como Stripe, eso no significa que todos los métodos de pago sean compatibles en ese país en particular. Así que hemos definido AliPay. Y hemos dicho que, oye, solo renderiza esto en China.

Y luego, como explicamos un poco antes, en términos de los proveedores de contexto, estás pasando ese proveedor de Stripe que es proporcionado por el SDK de Stripe como el proveedor de contexto de la pasarela de pago para que sepa qué proveedor renderizar para que podamos renderizar ese checkout y proporcionarle el estado correcto. Si quisiéramos agregar un nuevo método de pago, como PayPal, solo necesitamos definir PayPal como un método de pago, decir que está habilitado en los EE. UU., por ejemplo, agregar EE. UU. como un país a nuestro criterio de habilitación. Y en siete líneas de código, has agregado un método de pago. Ahora, si miramos un poco en términos de números, si tienes un negocio de 10 millones de ARR y estás operando 24/7, por ejemplo, puedes estimar aunque tengas picos y bajas que estás haciendo alrededor de $1,140 por hora. Y si estás operando con una disponibilidad del 99.9% o SLA, eso es alrededor de ocho horas, 41 minutos como tiempo de inactividad, como hemos visto antes que podrías tener como una pérdida potencial, lo que se traduce en casi $10,000 al año, no es una cantidad pequeña nuevamente. No solo poder cambiar a diferentes pasarelas te da esa ventaja de poder redirigir durante el tiempo de inactividad, sino que también obtienes un aumento de los métodos de pago. Así que usar, por ejemplo, pagos PICS en Brasil frente a la tarjeta de crédito puede aumentar la conversión en un 5 a 15%. Pero no solo eso, las tarjetas de crédito tienen tarifas. Y así puedes reducir la cantidad que tienes que pagar en términos de tarifas, porque ya no estás usando tarjeta de crédito usando pagos PICS en su lugar, y no pagas las tarifas del 2 al 4% además de eso. Así que estás optimizando en múltiples niveles diferentes. No es solo la disponibilidad.

Y lo que vamos a ver inicialmente es que tenemos Braintree y Recurly cargados como una opción principal en el Reino Unido, en Gran Bretaña. Podemos ver que todo está en libras esterlinas aquí, tenemos PayPal y tarjeta de crédito como opciones. Pero lo que voy a hacer a continuación, voy a cambiar el país a China, voy a actualizar todo, y China no tiene soporte para PayPal. Así que solo estoy mostrando tarjeta de crédito aquí. Pero también queremos ejecutar una prueba A-B para probar si Stripe funciona mejor con Alipay. Así que al hacer clic en esa pasarela de Stripe, automáticamente comienza a mostrar ahora Alipay y puedo probar eso aquí. Nuevamente, si cambiamos eso a otro país como EE. UU.

, tenemos diferentes métodos de pago disponibles, Alipay ya no es compatible. Así que ahora mostramos Google Pay y un montón de opciones diferentes. Y luego podemos desactivar esa bandera para volver a nuestra configuración recurrente de Braintree con tarjeta de crédito y PayPal. Y luego en Alemania, los pagos SEPA son realmente populares, por lo que tienes débito directo como una opción. Así que puedes ver que cada pequeña configuración cambia completamente la experiencia del usuario y la optimiza para el país y para la prueba A-B que queremos probar.

Por ejemplo, en India, aunque quieras procesar con pagos con tarjeta de crédito, en realidad usamos Adjin bajo el capó en lugar de Braintree porque diferentes, aunque estés procesando a través de tarjeta de crédito, diferentes pasarelas tienen diferentes tasas de éxito, aunque sea el mismo método de pago. Así que incluso eso puede hacer una diferencia significativa. Ahora, con todas esas cosas cargando, viste que actualizamos cada vez lo que hace la capa de orquestación es que determina cuáles son las pasarelas correctas para cargar y luego comienza a cargar de manera perezosa ese código en preparación para el checkout. Así que lo que esto realmente hizo en la realidad fue reducir nuestro tamaño de paquete en un 70% al cargar dinámicamente solo lo que necesitábamos para procesar el pago. Así que tomemos un ejemplo de qué pasa cuando las cosas salen mal, comenzamos esta conversación con, ya sabes, una gran interrupción que ocurrió durante 12 horas, lo cual es francamente inaceptable. Entonces, ¿qué nos ofrece esta capa de orquestación? Lo que podemos comenzar a hacer ahora es también detección de anomalías. Y puedes configurarlo con Datadog o la mayoría de tus plataformas de observabilidad hoy en día.

Así que si sé específicamente, que para la rupia india en India, los agentes están trabajando, sé las tres piezas de información que necesito para poder reconfigurar la pasarela para cambiar a procesar a través de Stripe. Y de hecho tuvimos que hacer esto hace dos semanas, los pagos en India no estaban funcionando. Así que tuvimos que cambiar a dos pasarelas diferentes al mismo tiempo. Y realizamos un experimento de prueba A-B 50-50. Y eso se hizo increíblemente rápido.

Así que estás a 15 minutos de detectar cualquier desviación métrica. Y entonces, ¿por qué esta segregación también es realmente interesante? Porque cuando segregas todos estos registros y estas métricas, los picos y anomalías se vuelven mucho más claros para poder detectar en lugar de si fueras a combinar todo esto, no verías esos picos tanto. Y así, 15 minutos es mucho mejor que las 12 horas que vimos anteriormente.

Y creo que fueron cuatro horas para que detectáramos si algo había salido mal. Así que tomemos un ejemplo. Recibimos una alerta, tenemos pagos fallidos en brain con brain tree en Suiza. Así que redirijamos las cosas a Stripe. Abriendo el sitio web de SmallPDF, tenemos brain tree apareciendo ahora mismo, estamos en Suiza. Lo que voy a hacer es moverme al código, voy a ir y agregar Suiza como un país compatible para Stripe. Así que ahora voy a volver a renderizar todo.