Cuando un cliente registra una tarjeta para una suscripción, guarda un medio de pago para compras futuras o añade una nueva credencial a su cuenta, surge una pregunta importante antes del primer cobro: ¿está activa esta tarjeta y puede utilizarse?
Realizar un cobro real solo para averiguarlo mezcla dos intenciones diferentes. Verificar una credencial es una cosa. Cobrar una compra es otra.
Zero Auth es un mecanismo de verificación de tarjetas sin un cobro financiero convencional. En la documentación de AZPay, la operación se describe como una preautorización no monetaria que se utiliza para confirmar que la tarjeta existe, está activa y puede aceptar cobros, sin mover fondos.
El concepto también existe en las redes de tarjetas. Visa describe Account Verification como una autorización de importe cero que se utiliza para comprobar el estado de una cuenta antes de una transacción financiera.
Pero hay una distinción fundamental: una verificación correcta no garantiza que una compra futura vaya a aprobarse. Zero Auth es una herramienta dentro del ciclo de vida de la credencial, no una promesa de ingresos futuros.
¿Qué es Zero Auth?
Zero Auth es una operación que se utiliza para verificar una credencial de tarjeta sin realizar una compra convencional.
En AZPay, el flujo documentado envía una preautorización no monetaria a través de la cadena de pagos. La respuesta permite al comercio interpretar el resultado de la verificación antes de decidir cómo continuar el recorrido.
Esto resulta especialmente útil cuando existe una distancia entre el momento en que se facilita la tarjeta y aquel en que se utilizará realmente.
Una suscripción puede empezar después de un periodo gratuito. Un marketplace puede permitir al cliente guardar una tarjeta antes de su primera compra. Una plataforma B2B puede registrar el medio de pago durante el onboarding y cobrar solo cuando se utilice un servicio determinado.
En estos casos, limitarse a almacenar la credencial pospone el descubrimiento de algunos problemas. Zero Auth crea un estado intermedio entre recibir la credencial e intentar un cobro financiero.
¿Cómo funciona Zero Auth en AZPay?
La documentación técnica de AZPay explica el flujo operativo que hay detrás de la abstracción. El comercio envía la solicitud de Zero Auth a AZPay; la operación sigue como una preautorización a través de la adquirencia hasta el emisor; el emisor valida la credencial y devuelve un código de respuesta; la respuesta recorre la cadena de vuelta hasta AZPay y después hasta el comercio.
La documentación también contempla la reversión automática de la preautorización, sin captura. En otras palabras, el objetivo del flujo no es completar una compra, sino obtener una señal sobre la credencial antes de una transacción financiera posterior.
Este detalle importa porque muestra el valor de la abstracción. Para la aplicación, la intención puede expresarse como «verifica esta credencial». Detrás de esa llamada hay una cadena formada por plataforma, adquirencia, red y emisor, y cada participante contribuye al resultado final.
La implementación documentada por AZPay incluye un endpoint de sandbox, campos de solicitud, ejemplos de respuesta, códigos de retorno y rutas de prueba. Para implementar el flujo, la documentación técnica debe considerarse la fuente de referencia, no este artículo editorial.
¿Zero Auth cobra algo al cliente?
La finalidad de Zero Auth es realizar una verificación sin un cobro convencional.
La documentación de AZPay describe el mecanismo como una preautorización de importe cero y también señala que determinadas redes pueden exigir un importe nominal. En esos casos, el flujo documentado contempla una reversión automática sin captura de fondos.
Este matiz es importante. No debemos convertir «Zero Auth» en una promesa universal de que todas las redes y rutas se comportan exactamente igual. El comportamiento concreto depende de la infraestructura participante y de las reglas aplicables al flujo.
Desde el punto de vista del producto, la intención sigue siendo clara: separar la verificación de la credencial de la compra que el cliente realmente quiere realizar.
¿Zero Auth garantiza que se aprobará la siguiente compra?
No.
Una verificación correcta informa sobre la credencial en el momento y el contexto de esa verificación. No convierte una transacción futura en una aprobación garantizada.
Entre la verificación y una compra posterior, la tarjeta puede caducar, bloquearse o sustituirse. El crédito disponible puede cambiar. El emisor puede evaluar la transacción futura de otra manera. El contexto de riesgo puede cambiar. Puede ser necesaria una autenticación. Incluso la ruta de procesamiento puede ser distinta.
Por eso, la interpretación correcta no es «Zero Auth aprobado significa pago futuro aprobado».
La interpretación más precisa es que la credencial superó la verificación realizada en ese momento.
¿Dónde encaja Zero Auth en la arquitectura de pagos?
Zero Auth tiene más sentido cuando se analiza como parte del ciclo de vida de una credencial.
Una tarjeta puede entrar en la plataforma, protegerse o tokenizarse, pasar una verificación, asociarse a un cliente y utilizarse después en una o varias transacciones futuras.
Esta secuencia acerca Zero Auth a temas como la tokenización, card-on-file y los pagos recurrentes, pero los conceptos no son equivalentes.
La tokenización se ocupa de la representación y el tratamiento seguro de la credencial. Card-on-file describe el contexto en que se conserva una credencial para su uso posterior. La recurrencia organiza los cobros a lo largo del tiempo. Zero Auth añade una posible fase de verificación.
Esta separación ayuda a construir sistemas más claros, porque cada operación pasa a responder a una pregunta concreta.
¿Son lo mismo Zero Auth y la tokenización?
No.
La tokenización y Zero Auth resuelven problemas distintos.
La tokenización está relacionada con representar la credencial de forma que el sistema no tenga que tratar el PAN original en todos los flujos posteriores. Zero Auth está relacionado con verificar la credencial sin un cobro convencional.
Una tarjeta puede tokenizarse sin que eso signifique automáticamente que ha superado una verificación de importe cero. Del mismo modo, verificar una credencial no elimina la necesidad de decidir cómo se almacenará y utilizará de forma segura.
La documentación de AZPay recomienda combinar ambos conceptos en determinados flujos: validar primero y tokenizar después, evitando almacenar tokens de tarjetas que no hayan superado la verificación prevista.
Es una decisión de arquitectura, no una equivalencia entre las operaciones.
Zero Auth y card-on-file
Card-on-file aparece en experiencias en las que el usuario no necesita volver a introducir los datos de su tarjeta en cada compra.
Las suscripciones, la movilidad, los servicios de reparto, SaaS, los marketplaces y los servicios bajo demanda son ejemplos habituales.
El reto es que almacenar una referencia no indica, por sí solo, si la credencial se encuentra en condiciones adecuadas para el flujo previsto.
Imagina una plataforma que ofrece un periodo gratuito. El primer día, el cliente crea su cuenta y facilita la tarjeta. El cobro no se realiza hasta varias semanas después.
Descubrir solo en el primer ciclo que la credencial tiene un problema significa convertir una cuestión de onboarding en un problema de cobro futuro.
Zero Auth no elimina los rechazos futuros, pero permite que la plataforma obtenga información sobre la credencial antes de ese momento.
Zero Auth en suscripciones
Los pagos recurrentes hacen aún más evidente esta separación temporal.
Una suscripción puede empezar inmediatamente o después de una prueba gratuita. Puede ser mensual o anual. Puede cambiar de plan. Puede utilizar una credencial durante un periodo largo.
En este escenario, la primera verificación es solo una parte del ciclo.
Una arquitectura madura separa el registro de la credencial, la verificación, el inicio de la suscripción, el cobro, los eventos asíncronos, los reintentos y los cobros posteriores.
Esto también mejora la observabilidad. Cuando algo falla, el equipo puede preguntarse si el problema se produjo en el registro, la verificación, la autorización financiera, la autenticación, la ruta o la comunicación con algún participante.
Cuanto más explícitamente se modelan estos estados, más fácil resulta diagnosticar el comportamiento del sistema.
¿Qué no resuelve Zero Auth?
Zero Auth no sustituye la autorización financiera, la autenticación, la prevención del fraude, la tokenización ni una estrategia de pagos recurrentes.
Tampoco garantiza saldo o crédito futuro, elimina rechazos ni convierte una credencial verificada en una credencial permanentemente válida.
Este punto importa porque las tecnologías de pago suelen presentarse como soluciones aisladas a problemas que pertenecen a sistemas.
La tasa de aprobación no depende de una única función. La conversión no depende solo del checkout. La resiliencia no depende solo del failover. La calidad de card-on-file no depende solo de Zero Auth.
La infraestructura de pagos es un sistema de decisiones interdependientes.
¿Qué diferencia hay entre Zero Auth y un cobro de pequeño importe?
La principal diferencia es la intención y el tipo de operación.
Un cobro financiero, aunque sea pequeño, sigue siendo una operación financiera. Account Verification y Zero Auth existen para verificar la cuenta o la credencial antes de la transacción financiera propiamente dicha.
Visa documenta Account Verification como una autorización de importe cero. La documentación de AZPay también separa la verificación del cobro y contempla el tratamiento de las particularidades de las redes que exigen un importe nominal.
Esta distinción mejora el modelo mental de la integración: verificar no debería tratarse como sinónimo de comprar.
¿Qué ocurre cuando se rechaza un Zero Auth?
El resultado debe interpretarse según el código de respuesta y el contexto de la operación.
La documentación de AZPay distingue, por ejemplo, tarjeta no válida, tarjeta caducada, transacción no permitida, tarjeta restringida, discrepancia de CVV, indisponibilidad del emisor, fallo del sistema y sospecha de fraude.
Esto muestra por qué reducir todos los resultados a «ha funcionado» o «ha fallado» empobrece la operación.
La pregunta más útil es: ¿qué significa exactamente este resultado y qué acción permite?
Una indisponibilidad temporal no representa lo mismo que una credencial no válida. Una condición de seguridad no debería recibir el mismo tratamiento que un fallo técnico transitorio.
La documentación concreta esta diferencia. Una tarjeta caducada requiere actualizar la credencial. La indisponibilidad del emisor puede justificar un nuevo intento. Determinados fallos del sistema pueden admitir un reintento con backoff. La sospecha de fraude no debe tratarse como una simple indisponibilidad técnica.
Esta granularidad es una de las partes más útiles de Zero Auth para la operación: la respuesta no solo sirve para clasificar la credencial; también puede orientar la siguiente acción del sistema.
¿Debería Zero Auth desencadenar un reintento?
No existe una regla única para todas las respuestas.
Reintentar tiene sentido cuando hay un motivo técnico y semántico para creer que repetir la operación puede producir un resultado útil y seguro.
La propia documentación de AZPay asocia acciones distintas a los códigos devueltos. Para la indisponibilidad del emisor, por ejemplo, documenta un nuevo intento posterior. Para ciertos errores del sistema, recomienda reintentar con backoff. Otros resultados requieren corregir la credencial o no deben repetirse sin más.
Este principio se aplica a los pagos en general: repetir una operación solo porque ha fallado no es una estrategia de resiliencia.
Antes de reintentar, el sistema necesita comprender el tipo de fallo y la acción apropiada.
¿Puede Zero Auth mejorar la conversión?
Zero Auth puede contribuir a una operación mejor preparada al identificar determinados problemas antes de un cobro futuro. Eso no significa que su implementación, por sí sola, produzca un aumento garantizado de la conversión o la aprobación.
La conversión depende de muchos factores: experiencia de checkout, autenticación, riesgo, emisor, adquirencia, credencial, latencia, disponibilidad y contexto de la transacción, entre otros.
La forma responsable de evaluar el impacto es medir el flujo real.
¿Cuántas credenciales pasan por la verificación? ¿Qué respuestas aparecen? ¿Cuántas credenciales verificadas llegan al primer cobro? ¿Cuál es el comportamiento posterior de esos cobros? ¿Dónde surgen fallos técnicos?
Sin ese contexto, atribuir un porcentaje de mejora a Zero Auth sería una promesa sin pruebas.
¿Sustituye Zero Auth a 3DS?
No.
3DS y Zero Auth tienen propósitos distintos.
3DS está relacionado con la autenticación en transacciones con tarjeta y tiene sus propios flujos. Zero Auth está relacionado con verificar la credencial sin un cobro convencional.
Una arquitectura puede utilizar mecanismos distintos en diferentes momentos del recorrido. Mezclarlos genera una comprensión errónea de la pila de pagos.
¿Cómo se plantea Zero Auth en una arquitectura multi-PSP?
Cuando una infraestructura trabaja con múltiples proveedores, la pregunta deja de ser solo «adónde enviarlo» e incluye «qué ruta admite esta operación y con qué comportamiento».
Las capacidades pueden variar entre adquirentes, procesadores, redes e integraciones. Una capa de orquestación debe conocer esas capacidades sin fingir que todos los caminos son idénticos.
Este principio va más allá de Zero Auth.
Una ruta de pagos tiene capacidades, restricciones, respuestas y características operativas. Una buena abstracción ofrece coherencia al comercio sin ocultar información necesaria para el diagnóstico y la toma de decisiones.
Es en este punto donde la orquestación deja de significar simplemente tener más de un PSP.
¿Por qué importa esto a los desarrolladores?
Porque una API de pagos debería permitir al desarrollador expresar una intención de negocio sin obligarle a reconstruir toda la complejidad de cada participante de la cadena.
La intención aquí es sencilla: verificar esta credencial.
La infraestructura traduce esa intención al mecanismo disponible, pero debe conservar suficiente trazabilidad para que el desarrollador entienda el resultado.
Este equilibrio es importante: simplificar el camino sin incidencias sin ocultar el problemático.
Las API que exponen toda la complejidad del procesador dificultan la integración. Las API que ocultan demasiada información dificultan el diagnóstico de incidentes.
La abstracción útil se encuentra entre estos dos extremos.
¿Qué debería observarse?
Zero Auth también puede tratarse como un evento observable dentro del ciclo de la credencial.
Una operación puede seguir el volumen de verificaciones, la distribución de resultados, los fallos técnicos, la latencia, los timeouts y el comportamiento por ruta cuando esos datos estén disponibles y puedan utilizarse adecuadamente.
También es posible relacionar la verificación inicial con eventos posteriores del ciclo, sin confundir correlación con causalidad.
La observabilidad transforma Zero Auth de una llamada aislada de API en una fase comprensible de la infraestructura.
¿Cuándo tiene sentido considerar Zero Auth?
Zero Auth suele ser relevante cuando se necesita verificar una credencial antes de un uso financiero posterior.
Esto aparece en onboarding, card-on-file, pruebas gratuitas, suscripciones, marketplaces y servicios en los que el registro del medio de pago y el cobro ocurren en momentos distintos.
Sin embargo, la decisión debe partir del problema y no de la tecnología.
Si la pregunta es «¿necesitamos verificar esta credencial antes de utilizarla en el futuro?», Zero Auth puede formar parte de la solución.
Si se necesita autenticar al titular, evaluar el fraude, proteger los datos o aumentar la resiliencia, hay otras capas que deben considerarse.
Elegir la tecnología adecuada empieza por nombrar correctamente el problema.
¿Es obligatorio Zero Auth para guardar una tarjeta?
No debemos convertir Zero Auth en un requisito universal para cualquier arquitectura de card-on-file.
La implementación depende del producto, de la arquitectura, de los participantes y de las capacidades disponibles.
Lo importante es separar los conceptos. Guardar una representación de una credencial y verificar una credencial son operaciones distintas. Un recorrido puede combinarlas; otro puede tener necesidades diferentes.
La documentación técnica debe ser la referencia para el comportamiento concreto de la implementación.
De la verificación al cobro: piensa en estados, no solo en API
La principal lección de Zero Auth no está en el importe cero. Está en la separación de estados.
Una credencial registrada no es necesariamente una credencial verificada. Una credencial verificada no es una compra autorizada. Una compra autorizada no está necesariamente capturada. Una captura no está necesariamente liquidada. Un fallo técnico no es necesariamente una decisión financiera.
Cuando estos estados se tratan como equivalentes, los sistemas se vuelven más frágiles.
Cuando se modelan de forma explícita, la operación gana capacidad de diagnóstico, automatización y evolución.
En AZPay, Zero Auth es una función documentada de la plataforma. La documentación describe el endpoint de sandbox, los campos de solicitud, los ejemplos de respuesta, los códigos de retorno, el flujo de verificación y los siguientes pasos relacionados con tokenización, suscripciones y prevención del fraude.
Por tanto, la pregunta arquitectónica más interesante no es solo si existe una API de Zero Auth.
Es: ¿en qué estado del ciclo de la credencial debe realizarse esta verificación y qué hará nuestro sistema con el resultado?
Esa es la diferencia entre añadir una llamada de API y diseñar una infraestructura de pagos.
Documentación y referencias
AZPay — Zero Auth: https://docs.azpay.com.br/pt-BR/docs/features/zero-auth
Es la principal referencia de implementación utilizada en este artículo. La documentación describe Zero Auth como una preautorización no monetaria, presenta el flujo entre comercio, AZPay, adquirente y emisor, y documenta el endpoint de sandbox, los campos de solicitud, los ejemplos de respuesta y los códigos de retorno. También contextualiza su uso con tokenización, suscripciones y prevención del fraude. Los apartados de este artículo sobre el funcionamiento en AZPay, la reversión, la interpretación de respuestas y la estrategia de reintentos se elaboraron a partir de esa documentación.
AZPay — documentación técnica: https://docs.azpay.com.br/pt-BR/
Es el punto de entrada a la documentación actual de la plataforma. Utiliza la documentación técnica vigente como fuente de referencia para autenticación, endpoints, payloads, pruebas y comportamiento de implementación, ya que las API y sus capacidades pueden evolucionar después de la publicación de este artículo.
Visa — Payment Account Validation: https://developer.visa.com/docs/pav
Visa documenta Account Verification como uno de los métodos de Payment Account Validation y lo describe también como una autorización de importe cero. La referencia aporta contexto de red al concepto tratado en este artículo y muestra que verificar una cuenta antes de ofrecer servicios, añadirla a una wallet o almacenarla como card-on-file es un caso de uso reconocido en la infraestructura de tarjetas.
Visa — How to Use Payment Account Validation: https://developer.visa.com/capabilities/pav/docs-how-to
Esta referencia detalla Account Verification como una solicitud de autorización de importe cero utilizada para comprobar el estado de una cuenta. Respalda la distinción central de este artículo entre verificar una credencial y ejecutar un cobro financiero.
Visa — Account Verification with a Zero Amount Authorization: https://developer.visaacceptance.com/docs/vas/en-us/payments/developer/ctv/rest/payments/payments-processing-basic-intro/payments-processing-basic-zero-auth-intro.html
La documentación de Visa Acceptance describe zero amount authorization como una práctica de account verification y explicita que una autorización de importe cero no puede capturarse. La referencia ayuda a contextualizar por qué la verificación y la captura deben tratarse como estados e intenciones diferentes.
Este artículo es educativo. Las reglas de red, el soporte por ruta, los requisitos y los comportamientos de las API pueden evolucionar; para la implementación, valida siempre la documentación técnica vigente y las reglas aplicables a tu entorno.