Resumen de backends resilientes
Un backend resiliente es tu propia copia de la API de un proveedor. Responde en las mismas rutas que la de él, devuelve las mismas formas de respuesta y los mismos códigos de estado, y se comporta como se comporta el proveedor. Tu integración cambia su URL base y nada más.
La palabra resiliente es sobre la propiedad. El backend es solo tuyo, sigue en pie cuando el sandbox del proveedor está caído, y produce las fallas que el de él no te da.
Dos formas de correr uno
Un backend corre de una de dos formas:
- Alojado: nosotros corremos el backend por ti, y responde en una dirección propia. Tus backends alojados aparecen en Simulaciones.
- Self-hosted: descargas el backend como imagen y lo corres en tu propia red. Tus backends self-hosted aparecen en Self-hosted.
Por debajo, los dos son el mismo backend, así que los tipos y los disparadores de más abajo funcionan igual en ambos. Los proveedores se compran en la Tienda de backends, en la barra lateral, y su selector de arriba a la derecha define para qué clase compras. Cada clase se compra por separado: un proveedor que tienes para backends alojados no cubre uno self-hosted, ni al revés.
Consulta Resumen de backends self-hosted.
Por qué los equipos corren uno
- El sandbox de un proveedor queda fuera del SLA de producción. Cuando se cae, tu release espera, y no hay a quién llamar.
- Toda tu empresa suele compartir una sola cuenta del proveedor. Lo que hace otro equipo ahí adentro aparece en tu build.
- Algunos proveedores solo entregan credenciales de sandbox después de una llamada comercial, y unos pocos nunca para la API que necesitas.
- Los casos que vale la pena probar son justo los que el sandbox de un proveedor no produce cuando se lo pides: una tarjeta robada, un impacto en listas de sanciones, un emisor que se pasa de tiempo.
- Los flujos que mandan a una persona a una página y esperan ahí no se pueden automatizar contra el original.
Tipos
Un tipo es una familia de proveedores con un motor detrás. Estos están disponibles hoy.
Pagos. Proveedores de tarjeta y de billetera. Autorizar, capturar, capturar parcialmente, reembolsar, cancelar, ajustar una autorización, más 3D Secure y claves de idempotencia.
Consulta Resumen del backend de pagos.
Identidad. Verificación de personas y de empresas, KYC y KYB juntos, porque los proveedores los tratan como una sola cosa. Revisión de documentos y de selfies, cruce con listas de vigilancia, registro y titularidad de empresas, y los flujos alojados que normalmente necesitan a una persona.
Consulta Resumen del backend de identidad.
Tú decides qué vuelve
Nombra al sujeto de una solicitud según el resultado que quieras y eso es lo que recibes. Llama insufficient_funds al titular de la tarjeta y el pago se rechaza por ese motivo. Llama sanctions_match al solicitante y la revisión vuelve con el impacto en el informe que lo habría encontrado.
Los disparadores son las mismas palabras en todos los proveedores, y cada uno responde en su propio formato. Escribes el test una vez, y agregar un segundo proveedor no significa aprender otro juego de valores mágicos. Cada proveedor también conserva sus datos de prueba publicados, así que los números de tarjeta y los nombres reservados de su documentación también funcionan acá.
Cuando los disparadores incluidos no cubren un caso, escribe el tuyo. Un escenario dice cómo se ve una solicitud y qué debería volver, y se apoya sobre lo que traemos en lugar de reemplazarlo.
Consulta Escribe tus propios escenarios.
Cómo encaja un backend alojado
Los proveedores pertenecen a tu organización. Agregas las marcas que quieras una vez, y cada backend alojado que corras puede servirlas.
Consulta Agregar proveedores.
Un backend alojado es una simulación con dirección propia, y tú eliges cuáles de los proveedores de tu organización sirve. Puedes correr más de uno, y cada uno guarda sus propios registros. Apunta CI a uno y quédate con otro para probar a mano.
Consulta Crear un backend alojado.
Cada backend alojado responde en su propio host:
https://<hostname>.pay.mockz.io # pagos
https://<hostname>.kyx.mockz.io # identidadEn ese host, cada versión de un proveedor responde bajo una ruta que la nombra:
https://shop-payments.pay.mockz.io/adyen/checkout/v71/payments
https://kyc-checks.kyx.mockz.io/onfido/v3.6/applicantsTodo lo que va después de esa ruta es la ruta propia del proveedor. Si el SDK de un proveedor solo acepta una dirección raíz, su versión puede responder en la raíz.
Como es una simulación, el resto de la app funciona sobre él como siempre: historial de solicitudes, replays, control de acceso y enlaces para compartir. Encima de eso guarda un registro de lo que ha hecho, como los pagos tomados, o los casos, los sujetos y los documentos presentados.
Consulta Actividad del backend.
Publicamos builds nuevos de cada tipo, que agregan proveedores y corrigen comportamientos. Un backend alojado sigue el último build salvo que lo fijes a uno, y un backend fijado se queda ahí hasta que tú lo muevas.
Consulta Fijar una versión de build.
Qué necesitas
Un backend alojado corre en un plan que incluye backends, y necesita cierta cantidad de memoria para siquiera arrancar. La Tienda de backends te dice dónde estás antes de que compres nada, y te señala los planes si el tuyo no puede alojar uno. Los backends self-hosted no dependen de tu plan.
Los proveedores se cobran aparte de tu plan:
- Alojado: una suscripción por tipo, que pagas cada mes o cada año con la tarjeta de tu plan. Tu primer pedido de cada tipo corre gratis durante un período de prueba. No se cobra nada por la prueba, y para conservar los proveedores después los vuelves a pedir.
- Self-hosted: se paga cada mes con tarjeta o cada año por factura.
Solo los owners de la organización compran proveedores, y los cancelan en Facturación, en Suscripciones. El resto puede usar lo que la organización tiene.
Consulta Suscripciones.