Arquitectura de pagos e integración de pasarelas de pago

¿Qué es la arquitectura de pagos y cuándo necesita atención propia?

La arquitectura de pagos es la estructura de software que decide cómo se inicia un pago, cómo se autentica al titular de la tarjeta, cómo y con qué garantías se registra el resultado en su sistema y cómo se siguen las devoluciones y los asientos contables. Detrás de un solo botón de pago trabajan juntos los sistemas de pedidos, stock, facturación, notificaciones e informes.

El complemento de pago estándar de una plataforma de comercio electrónico basta para la mayoría de las tiendas sencillas. Diseñar el flujo de pago por separado se vuelve necesario cuando:

• Tiene un modelo de cobro recurrente, como suscripciones, membresías o facturación por uso.
• Gestiona un marketplace o una plataforma de servicios que vende productos de más de un vendedor.
• Cobra en la web, en la app móvil y a través del centro de atención telefónica sobre la misma cuenta de cliente.
• Trabaja con más de un banco o entidad de pago y quiere enrutar las operaciones según el coste y la tasa de aprobación.
• La conciliación se hace a mano, las devoluciones se siguen por correo y los registros contables no cuadran con los cobros.

¿Qué hace UNIT İstanbul en infraestructura de pagos y qué no hace?

Prestar servicios de pago, procesar datos de tarjetas y custodiar fondos de clientes son actividades reguladas que requieren licencia en Türkiye y en los demás mercados en los que trabajamos. UNIT İstanbul no es una entidad de pago, ni una entidad de dinero electrónico, ni un banco. Diseñamos y desarrollamos el software que se conecta con la infraestructura que ofrecen las entidades que tienen esas licencias.

No emitimos opiniones jurídicas sobre cómo se aplica a su negocio la normativa de pagos correspondiente; recomendamos aclarar esas cuestiones con su asesor jurídico y con la entidad autorizada con la que vaya a trabajar. En la parte de software, convertimos esas decisiones en requisitos técnicos.

¿TPV virtual de un banco o entidad de pago?

Un TPV virtual es el servicio que un banco ofrece a un comercio para aceptar tarjetas en internet. Las entidades de pago ponen una única interfaz delante de muchos bancos y métodos de pago; el alta y la integración son más rápidas, pero el equilibrio entre comisiones y control es distinto. Cuál le conviene depende de su volumen de operaciones, de su necesidad de pago a plazos y de la capacidad operativa de su equipo.

Empiece con la opción que empiece, construimos una capa de pagos que separa el código propio de cada proveedor de su lógica de negocio. Así, añadir o cambiar de proveedor más adelante no obliga a reescribir el código de pedidos y de contabilidad.

¿Cómo se construye el flujo de autenticación del titular (Three-Domain Secure)?

La autenticación del titular es el paso en el que el banco pide al titular de la tarjeta un código de un solo uso o una aprobación en la app bancaria antes de autorizar el pago, conocido como Three-Domain Secure. El usuario pasa un momento a la pantalla del banco; si el flujo no se construye con cuidado, un pedido puede quedar sin confirmar aunque el dinero ya se haya cobrado.

1. 1.Antes del pago, el pedido se guarda con un identificador único y en estado pendiente.
2. 2.La solicitud de pago se inicia desde el servidor; el importe y la moneda salen del registro del pedido, no de los datos que envía el navegador.
3. 3.El usuario se redirige a la pantalla de autenticación o esta se abre dentro de la página; en el móvil se diseña para completarse sin salir de la app.
4. 4.Al volver del banco, el resultado se procesa a partir de una consulta de verificación del servidor al proveedor o de una notificación firmada, no a partir del navegador del usuario.
5. 5.El pedido se confirma, se descuenta el stock y se envían las notificaciones; este paso se completa en el servidor aunque el usuario cierre la página de retorno.

¿Cómo se guardan las tarjetas y se reduce el alcance de PCI DSS?

PCI DSS es el estándar de seguridad del sector de tarjetas que debe cumplir toda organización que procese, transmita o almacene datos de tarjeta. La forma más eficaz de reducir la carga de cumplimiento es asegurarse de que los números de tarjeta nunca lleguen a sus servidores.

• Campos de pago alojados: Los datos de la tarjeta se introducen en campos seguros que el proveedor inserta en su página, o en su propia página de pago; su sistema solo recibe un token.
• Tokenización: Los pagos repetidos con tarjeta guardada y las suscripciones usan el token emitido por el proveedor en lugar del número de tarjeta.
• Sin guardar códigos de seguridad: El código del reverso de la tarjeta nunca se escribe en una base de datos, un registro ni un informe de errores.
• Enmascaramiento en los registros: Los datos de tarjeta, identidad y contacto se enmascaran automáticamente en los registros de solicitudes y respuestas.
• Separación de accesos: Las claves del servicio de pago se guardan en un almacén de secretos aparte, los permisos se conceden persona a persona y las claves se renuevan con regularidad.

Este enfoque también influye en qué cuestionario de autoevaluación de PCI DSS le corresponde; recomendamos hacer la valoración final con su proveedor y, cuando haga falta, con un evaluador cualificado. El tratamiento de datos personales y los plazos de conservación se configuran de acuerdo con su aviso de privacidad según la KVKK, la ley de protección de datos de Türkiye.

¿Cómo se diseñan las suscripciones, los marketplaces y los pagos divididos?

Suscripciones y pagos recurrentes

En las suscripciones, el verdadero trabajo empieza después del primer cobro. El calendario de renovación, cuándo y con qué frecuencia se reintenta un cobro fallido, cómo se avisa al cliente de que su tarjeta ha caducado y cómo se calcula el periodo restante al subir o bajar de plan necesitan reglas escritas. Cuando estas reglas se diseñan con independencia del código y pueden cambiarse desde el panel de administración, el equipo de producto puede probar precios sin esperar a un desarrollador.

Marketplace y pagos a subcomercios

En un marketplace el cliente paga una sola vez y el importe se divide en partidas como la parte de cada vendedor, la comisión de la plataforma y el envío. La división y los pagos a los vendedores los gestiona la infraestructura de subcomercios de la entidad de pago autorizada; en la parte de software construimos el alta de vendedores, las reglas de comisión, el calendario de pagos, el recálculo de la división tras devoluciones parciales y los informes para vendedores. Las configuraciones que podrían requerir licencia, como pagar a los vendedores desde la cuenta propia de la plataforma, deben aclararse con su asesor jurídico desde el principio.

¿Cómo se gestionan las devoluciones, las anulaciones y la conciliación?

Una anulación revierte una operación completa antes de la liquidación del final del día; una devolución reintegra a la tarjeta todo o parte de una operación ya liquidada. Un contracargo empieza con la reclamación del titular ante su banco y obliga a reunir pruebas. Estos tres casos deben modelarse en el software como estados distintos.

La conciliación es la comparación de los registros de pago de su sistema con los informes del proveedor y con los importes que llegan a su cuenta bancaria. Un servicio de conciliación que descarga automáticamente los informes del proveedor, señala los registros que no cuadran y genera los asientos en su sistema contable o ERP reduce mucho las comprobaciones manuales de su equipo financiero. Planificamos las integraciones contables y con el ERP más amplias junto con nuestro trabajo de software empresarial.

¿Cómo se integran los pagos dentro de la app y los flujos financieros?

Si vende contenido digital y suscripciones dentro de una app móvil, entran en juego las normas de las tiendas de aplicaciones sobre el uso de sus propios sistemas de compra; para bienes físicos y servicios puede usar pagos con tarjeta o monederos digitales. Hacer esta distinción al inicio del diseño del producto reduce el riesgo de rechazo en la revisión de la tienda. Describimos nuestro enfoque de las apps en su conjunto en la página de desarrollo de apps móviles.

Añadir funciones bancarias a su app, como información de cuentas, iniciación de pagos, transferencias internacionales o pago de recibos, es posible a través de las interfaces de banca abierta y de pagos que ofrecen las entidades autorizadas. En estas integraciones, el consentimiento del usuario, la duración de la sesión, la forma de mostrar los tipos de cambio y una indicación clara de qué entidad realiza la operación forman parte del diseño de pantallas.

¿Cómo se gestionan los errores de pago, los tiempos de espera y el fraude?

La situación más peligrosa en los pagos es una operación de resultado desconocido: la solicitud se envió y la respuesta no llegó a tiempo. Reintentar el pago a ciegas puede provocar un doble cargo. Una infraestructura de pagos sólida se apoya en estos principios:

• Cada solicitud de pago se envía con una clave de idempotencia, de modo que aunque la misma solicitud llegue dos veces solo se crea una operación.
• Los estados de pago se gestionan con una máquina de estados explícita; además de pendiente, aprobado, denegado, anulado y devuelto, no queda ningún estado intermedio sin definir.
• Las operaciones de resultado incierto se consultan con el proveedor en segundo plano y pasan automáticamente al estado correcto.
• Las notificaciones del proveedor solo se aceptan tras verificar su firma, y las notificaciones desordenadas o duplicadas se procesan de forma segura.
• Los controles antifraude combinan el motor de riesgo del proveedor con sus propias reglas de negocio, como límites a los intentos repetidos, la antigüedad de la cuenta o las discrepancias en la dirección de entrega.
• Se supervisan la tasa de aprobación, los códigos de denegación, los tiempos de respuesta y los retrasos de las notificaciones, y se avisa al equipo en cuanto se supera un umbral.

¿Cómo se mide y se mejora la conversión en el pago?

La pantalla de pago es el último paso de un embudo y merece su propia medición. Cuando se registran como eventos independientes la llegada a la página de pago, la introducción de los datos de la tarjeta, el paso a la pantalla de autenticación, la vuelta de la autenticación y la aprobación, puede ver dónde se produce el abandono. Traducir los códigos de denegación del banco a mensajes que el usuario entienda y ofrecer un método de pago alternativo puede recuperar parte de esa pérdida.

Aquí nos ayudan nuestras raíces de agencia de marketing: configuramos los eventos de pago en el mismo lenguaje que la medición de publicidad y analítica, y planificamos desde el principio cómo vuelven correctamente los datos de ingresos a las campañas. Llevamos las mejoras de todo el embudo junto con nuestro equipo de CRO y analítica; para la tienda online en su conjunto, consulte nuestro servicio de web y comercio electrónico.

¿De qué depende el coste de un proyecto de infraestructura de pagos?

El coste depende sobre todo del número de proveedores que hay que conectar, del modelo de pago (cobro único, suscripción, marketplace), del número de canales (web, móvil, centro de atención telefónica), de la profundidad de las integraciones contables y con el ERP y del estado del sistema actual. El acceso al entorno de pruebas del proveedor, el proceso de aprobación del comercio y las pruebas previas al lanzamiento que exige el proveedor también influyen en el calendario. Tras el análisis, recogemos en una propuesta escrita el alcance, los entregables y las condiciones de mantenimiento. Encontrará nuestros demás servicios de software y referencias en la página de Unit Software, o puede contactar con nosotros para hablar de su proyecto.