El vocabulario de los pagos puede resultar confuso porque las empresas agrupan las responsabilidades de distintas formas. Gateway, PSP, adquirente y subadquirente aparecen a menudo en la misma conversación, pero no representan necesariamente la misma función.
Entender esas responsabilidades es más útil que memorizar categorías comerciales. Cuando una empresa sabe quién transporta la solicitud, quién mantiene la relación de procesamiento y dónde se toma cada decisión, resulta más sencillo diseñar integraciones, investigar fallos y evaluar proveedores.
¿Por qué hay tantos nombres?
Los pagos forman una cadena con múltiples participantes. Con el tiempo, las empresas han empezado a ofrecer distintas combinaciones de tecnología, procesamiento, servicios financieros, riesgo y experiencia de checkout.
Por ello, dos plataformas denominadas PSP pueden tener alcances distintos, mientras que un producto llamado gateway puede ofrecer capacidades adicionales a las de su definición histórica.
Las fronteras comerciales cambian. Las responsabilidades arquitectónicas siguen siendo una forma más estable de comprender el sistema.
¿Qué es un gateway de pagos?
Un gateway es la capa tecnológica que conecta la aplicación de una empresa con la infraestructura necesaria para enviar y recibir información de pagos.
Puede ofrecer una API común, componentes de checkout, tokenización, integraciones y otras funciones, según el producto.
El gateway no debe definirse únicamente por la interfaz visible. Es importante entender a qué participantes remite la operación y qué responsabilidades asume durante el ciclo de vida del pago.
¿Qué es un PSP?
PSP son las siglas de Payment Service Provider. En términos generales, describen a un proveedor de servicios de pago que facilita a las empresas el acceso a las capacidades necesarias para aceptar pagos.
Su alcance varía considerablemente. Un PSP puede combinar gateway, integraciones con adquirentes, métodos alternativos, gestión operativa y otros servicios.
Por eso, preguntar solo si una empresa es un PSP rara vez basta. La pregunta útil es qué funciones realiza y qué relaciones siguen siendo responsabilidad del comercio.
¿Qué es un adquirente?
En el ecosistema de tarjetas, el adquirente participa en el procesamiento de transacciones y conecta al establecimiento con la infraestructura necesaria para remitir autorizaciones y otras operaciones del flujo.
El diseño regulatorio y operativo varía según el mercado, pero la adquirencia cumple una función distinta de la capa de software que simplemente transporta llamadas de API.
Una integración puede llegar al adquirente directamente o a través de otros participantes.
¿Qué es un subadquirente?
En una explicación simplificada, un subadquirente actúa como intermediario que permite a los establecimientos acceder a capacidades de aceptación y procesamiento mediante su propia relación con otros participantes de la cadena.
La terminología y las responsabilidades concretas dependen del mercado y del modelo de negocio.
Una vez más, la clasificación comercial debe complementarse con el análisis del flujo real: quién contrata a quién, quién procesa, quién liquida y quién mantiene cada responsabilidad.
¿Compiten un gateway y un PSP?
No necesariamente. Un PSP puede incluir un gateway en su oferta. Un gateway puede conectarse a varios PSP o adquirentes. Una plataforma puede reunir funciones tradicionalmente atribuidas a categorías distintas.
Esto significa que comparar proveedores solo por su etiqueta puede dar lugar a una comparación injusta.
La evaluación debería desglosar capacidades y responsabilidades.
¿Un PSP y un adquirente son lo mismo?
Tampoco necesariamente. PSP es una categoría amplia de proveedor de servicios. La adquirencia representa una función específica en el ecosistema de tarjetas.
Una plataforma puede facilitar el acceso a adquirentes sin ser ella misma el adquirente de ese flujo.
Para comprender la arquitectura, hay que identificar quién desempeña cada papel en la transacción concreta.
¿Dónde encaja el checkout?
El checkout es la experiencia en la que el cliente introduce o selecciona los datos necesarios para pagar. Puede estar alojado, integrado o construido de otras formas.
El checkout no debe confundirse con el procesamiento. Es una capa de la experiencia que se conecta a la infraestructura de pagos.
Una misma experiencia de checkout puede trabajar con distintas rutas por detrás, según la arquitectura.
¿Dónde encaja la tokenización?
La tokenización sustituye datos sensibles por una representación que puede utilizarse dentro de un contexto determinado.
Pueden ofrecerla distintos participantes. La ubicación del vault y la portabilidad del token son cuestiones arquitectónicas importantes, especialmente en estrategias multi-PSP.
Si una credencial tokenizada solo puede utilizarse en un proveedor, cambiar la ruta de procesamiento puede no ser tan sencillo como parece.
¿Dónde encaja el antifraude?
El antifraude evalúa el riesgo y puede intervenir antes o durante distintas etapas del flujo, según la arquitectura.
Puede ser un producto independiente, una capacidad integrada en un PSP o parte de una solución más amplia.
La posición del antifraude influye en los datos disponibles y en el momento en que una decisión puede impedir o permitir que avance la transacción.
¿Dónde encaja 3DS?
3DS es un protocolo de autenticación relacionado con los pagos con tarjeta. Introduce interacción e intercambio de información adicional entre los participantes del ecosistema.
Autenticación no es sinónimo de autorización. Una transacción puede pasar por la autenticación y continuar después por otras etapas de procesamiento.
En arquitecturas multi-PSP, también hay que tener en cuenta el contexto de autenticación cuando la ruta puede cambiar.
¿Dónde encaja la orquestación?
La orquestación añade una capa de coordinación entre la intención de pago y los posibles caminos de ejecución.
Puede centralizar el enrutamiento, la normalización, el estado, la observabilidad y las políticas de tratamiento de fallos, según la implementación.
En lugar de vincular rígidamente el checkout a un único proveedor, la capa de orquestación puede permitir gestionar distintas rutas de forma común.
¿Un orquestador sustituye al PSP o al adquirente?
No. La orquestación coordina caminos; no elimina la necesidad de los participantes que ejecutan las funciones del ecosistema.
Una analogía útil consiste en pensar que el orquestador decide y coordina, mientras los conectores y proveedores ejecutan capacidades específicas.
La frontera exacta varía según la plataforma, pero la existencia de coordinación no hace desaparecer los componentes coordinados.
¿Qué significa integración directa?
Una integración directa suele significar que la aplicación se conecta a la API de un proveedor sin una capa intermedia de abstracción u orquestación para esa responsabilidad.
Esto puede ser sencillo y eficiente cuando solo existe un camino.
Sin embargo, a medida que aumentan las integraciones, la aplicación puede acumular reglas específicas, distintos modelos de error, webhooks diferentes y lógica propia para cada proveedor.
El coste oculto de múltiples integraciones
El trabajo no termina cuando funciona la primera autorización. Las API cambian, los certificados caducan, las versiones dejan de mantenerse, los webhooks deben procesarse y los comportamientos deben supervisarse.
Cada nueva integración amplía la superficie operativa.
Una capa común puede reducir parte de ese acoplamiento, pero también necesita mantenimiento. No existe abstracción sin coste.
¿Cómo comparar dos proveedores?
Empieza por las capacidades que necesita el negocio. Métodos, mercados, monedas, modelo de integración, tokenización, autenticación, observabilidad y requisitos operativos pueden formar parte del análisis.
Después, identifica qué responsabilidades asume cada proveedor y cuáles siguen correspondiendo a tu equipo.
El precio importa, pero compararlo sin comparar el alcance puede situar productos diferentes en la misma fila de una hoja de cálculo.
¿Quién controla los datos y el estado?
Esta pregunta es especialmente importante para la portabilidad. Si el estado del pago, los tokens o la información esencial solo están disponibles dentro de un proveedor, cambiar de arquitectura puede exigir trabajo adicional.
Una integración bien diseñada deja claro qué identificadores pertenecen al dominio interno y cuáles a cada proveedor.
Esto también facilita la conciliación y la investigación cuando intervienen varios participantes.
¿Quién recibe los webhooks?
Los eventos asíncronos forman parte del ciclo de vida de los pagos. En una integración directa, la aplicación puede recibir eventos específicos de cada proveedor.
Con una capa intermedia, esos eventos pueden normalizarse antes de llegar al dominio de la aplicación.
Lo importante es conservar suficiente información para rastrear el origen y evitar que la normalización oculte detalles necesarios para el diagnóstico.
¿Cómo funciona en una arquitectura multi-PSP?
Una aplicación puede utilizar una capa común que conoce distintos conectores. Cada conector traduce las operaciones para un PSP o adquirente concreto.
Un motor de enrutamiento decide qué ruta elegible recibirá el intento. El estado y la observabilidad registran lo ocurrido, con independencia del camino.
Esta arquitectura separa el dominio del pago de las particularidades de cada integración, sin fingir que todos los proveedores son idénticos.
¿Qué modelo es mejor?
No existe una respuesta universal. Una integración directa puede ser mejor para una operación sencilla. Un PSP completo puede reducir el número de relaciones e integraciones. Una estrategia multi-PSP puede ser importante para operaciones con requisitos específicos de resiliencia, mercado o control.
La arquitectura debe ser proporcional al problema.
Añadir participantes innecesarios también añade costes, puntos de fallo y complejidad operativa.
Preguntas que conviene hacer antes de contratar
En lugar de preguntar únicamente qué categoría describe al proveedor, investiga el flujo. ¿Quién procesa la autorización? ¿Quién conserva el token? ¿Cómo funciona la portabilidad? ¿Qué métodos y mercados se admiten? ¿Cómo se representan los errores? ¿Cómo funcionan los webhooks y la conciliación? ¿Es posible utilizar más de una ruta?
Estas respuestas revelan más sobre la arquitectura que la etiqueta de la página comercial.
¿Qué tiene que ver AZPay con este mapa?
AZPay aborda los pagos como una infraestructura que debe ser comprensible, integrable y capaz de evolucionar. Esto hace especialmente importante la separación de responsabilidades.
Los papeles descritos en este artículo representan conceptos generales del ecosistema y no deben interpretarse como una afirmación de que AZPay desempeñe necesariamente todas las funciones mencionadas.
Las funcionalidades y responsabilidades del producto deben evaluarse a partir de la implementación y la documentación concretas.
Entiende las responsabilidades, no solo las siglas
Gateway, PSP, adquirente y subadquirente ayudan a organizar la conversación, pero no sustituyen al diseño del flujo.
Cuando evaluamos quién recibe la intención, quién decide la ruta, quién procesa, quién autentica, quién conserva las credenciales y quién observa el estado, la arquitectura resulta mucho más clara.
En definitiva, comprender los pagos consiste en comprender las responsabilidades y las conexiones entre sus participantes.