Los PSP de pagos transfronterizos evolucionan en la era de múltiples vías

Artículo escrito por A Wang, Web3 Little Lawyer

Los pagos digitales ya han entrado en la corriente principal, pero los asentamientos aún no.

Esta es la evaluación de Dan Mottice, ex ejecutivo de Visa y fundador de Beam. Las transacciones de Visa se autorizan en cualquier comercio del mundo, pero el asentamiento subyacente aún se realiza a través de SWIFT: agrupando transacciones por lotes, transfiriendo fondos mediante transferencias internacionales, atravesando regulaciones locales, feriados y múltiples bancos intermediarios, mientras el comerciante espera recibir el pago. Esto no es un problema de Visa, sino una deuda estructural de toda la industria. Y los PSP son el punto donde esta deuda se concentra más.

Este artículo se centra en los proveedores de servicios de pago (PSP), que han evolucionado de simples herramientas de cobro a convertirse en la capa de infraestructura central para la gestión del flujo de fondos, la liquidación y la contabilidad. Originalmente fueron diseñados para una era más sencilla: sistemas de una sola vía, procesos de transacción lineales e infraestructura altamente integrada.

En el entorno de pagos moderno, un "pago" ya no es una sola transacción, sino una serie de cambios de estado que involucran múltiples partes interesadas y vías de pago. Hoy en día, un pago puede incluir: aplicaciones de extremo cliente, PSP, proveedores de prevención de fraude y verificación de identidad, bancos custodios, una o más vías de pago, y sistemas contables internos de la empresa.

Las empresas deben admitir simultáneamente tarjetas bancarias, ACH, transferencias electrónicas, RTP, FedNow, y cada vez más liquidaciones basadas en stablecoins. Cada vía tiene distintos tiempos de liquidación, modos de fallo, formatos de datos y requisitos operativos.

Este artículo compila la guía de Modern Treasury, que explorará cómo han evolucionado los PSP, qué adaptaciones requiere su arquitectura subyacente para los sistemas de pago modernos, y qué estrategias deben seguir los equipos que desarrollan productos de pago al elegir su próximo PSP.

Juicio clave

01｜Los pagos digitales han entrado en la corriente principal, pero los asentamientos no. Visa te permite autorizar pagos en cualquier comerciante del mundo, pero los asentamientos subyacentes aún operan sobre SWIFT. La interfaz se resolvió, pero la base no.

02｜PSP realiza el pago, pero no explica el flujo de fondos. Stripe te dice qué ocurrió en su segmento, pero no puede decirte cuál es el estado real del dinero ahora. La capa de ejecución y la capa de registro son dos cosas distintas.

03｜Cada vía de pago es un sistema operativo independiente, no una variante del mismo modelo. ACH puede ser revertido, RTP no; las redes de tarjetas pueden ser disputadas, las stablecoins tienen confirmación final en la cadena. La capa de abstracción de los PSP oculta estas diferencias, pero solo hasta que surge un problema.

04｜Los pagos en tiempo real eliminaron los amortiguadores; el control debe avanzar. La lógica de gestión de riesgos, aprobación y conciliación de los PSP tradicionales asumía que «si ocurre un error, aún hay tiempo para corregirlo». RTP y FedNow hacen que esta suposición ya no sea válida. Las decisiones deben tomarse antes de que se muevan los fondos, no después.

05 | Las stablecoins son una vía de liquidación, no un nuevo método de pago. No resuelven el problema de la interfaz de pago, sino el retraso entre la «finalización de la contabilidad» y el «llegada real de los fondos». La ruta de implementación más práctica es la estructura de sándwich: entrada de moneda fiduciaria, circulación en la cadena, salida de moneda fiduciaria; los usuarios en ambos extremos no necesitan entender las stablecoins.

06｜Los fondos en tránsito pueden generar rendimientos, algo que casi no existe en los sistemas tradicionales. En los pagos transfronterizos, los fondos permanecen bloqueados entre 24 y 72 horas antes de la liquidación, generando ningún rendimiento y ocupando capital de trabajo. Las stablecoins permiten por primera vez que los fondos en movimiento también generen valor.

07｜El mayor fracaso en la operación de pagos es no poder responder a una pregunta simple: ¿adónde fue ese dinero? La conciliación, el manejo de anomalías y la gestión de liquidez: estos problemas no surgen en el momento del inicio del pago, sino después. Sin una capa de coordinación unificada, cada proveedor solo puede contarte su propia parte de la historia.

08｜El verdadero riesgo estratégico no es si usas o no stablecoins. Es que tus competidores hayan reestructurado sus costos de liquidación y eficiencia de capital con stablecoins, mientras tú aún esperas el momento perfecto para entrar.

I. Evolución histórica del PSP

Durante los últimos veinte años, el papel de PSP ha experimentado un cambio fundamental.

En los inicios del comercio electrónico, los PSP funcionaban principalmente como pasarelas de pago. Sus responsabilidades eran sencillas: conectar a los comerciantes con las redes de tarjetas y los bancos adquirentes para autorizar y liquidar las transacciones.

Estos sistemas PSP están diseñados para un mundo muy específico. Los pagos se basan principalmente en tarjetas, fluyen a través de una sola cuenta de comerciante y siguen un ciclo de vida lineal desde la autorización hasta el asentamiento. Los PSP están optimizados para procesar transacciones eficientemente dentro de este modelo.

Durante la década de 2010, Marketplace, plataformas SaaS y productos de fintech comenzaron a integrar directamente los pagos en sus productos. Las plataformas necesitaban completar la inscripción de usuarios, dividir los pagos entre múltiples partes y gestionar los pagos. Los PSP ampliaron sus servicios, incorporando inscripción de comerciantes, infraestructura de pagos y herramientas de prevención de fraude.

Sin embargo, a pesar de que las capacidades del PSP continúan ampliándose, su arquitectura subyacente sigue basada en un modelo diseñado para procesos de pago lineales, optimizados principalmente para el procesamiento de transacciones, y no para coordinar movimientos de fondos complejos y multietapa entre proveedores y vías distintas.

A principios de la década de 2020, las empresas comenzaron a operar a través de múltiples vías, regiones y escenarios. Los PSP tradicionales continuaron agrupando numerosos componentes, permitiendo que las empresas interactúen con una sola plataforma. Sin embargo, a medida que los procesos de pago se volvieron más complejos, un proceso de pago puede abarcar varios pasos: verificación de identidad, análisis de riesgos, toma de decisiones sobre fondos, ejecución de vías y seguimiento interno.

Este cambio hizo que el rol del PSP evolucionara de «conectores» a «coordinadores», pero su arquitectura no ha evolucionado al mismo ritmo.

The result is: PSP still handles fund transfers, but operates within a more complex, full transaction payment lifecycle.

II. Pila tecnológica de pago PSP moderna

Para comprender las limitaciones de PSP, primero se debe entender el entorno de pago más amplio en el que se encuentra.

2.1 Pila tecnológica PSP

El entorno de pagos moderno no es una sola plataforma o proveedor, sino un conjunto de componentes de infraestructura jerárquicos que respaldan conjuntamente el movimiento, la liquidación y la contabilidad de los fondos.

Capa de aplicación: plataformas de comercio electrónico que inician pagos, Marketplace, aplicaciones de tecnología financiera, productos SaaS con pagos integrados.

Capa PSP: se encarga de ejecutar instrucciones de pago, como enrutar transacciones a redes de tarjetas, iniciar transferencias bancarias o conectarse a vías de pago. En la mayoría de los casos, esta complejidad subyacente se abstracta detrás de la interfaz del PSP, permitiendo que el usuario interactúe con un solo sistema en lugar de enfrentarse directamente a múltiples proveedores involucrados.

Capa de cumplimiento: Los procesos de pago modernos también dependen de proveedores de verificación de identidad, herramientas de detección de fraude e infraestructura de cumplimiento, que determinan si se debe permitir avanzar con el pago.

Nivel bancario: Los bancos custodios mantienen los fondos, proporcionan cuentas reguladas y ofrecen acceso a redes de pago como ACH, transferencias electrónicas, RTP y FedNow.

Internal reconciliation layer: System used by enterprises to track balances, indicate transaction status, and maintain consistent records of financial activities.

Cada una de las capas anteriores desempeña un papel en el movimiento de fondos, pero ninguna proporciona una imagen completa de lo que realmente ocurre después del inicio del pago. Es por eso que la capa de conciliación interna se vuelve indispensable.

2.2 Sincronización y asincronización

Los PSP tradicionales tienen un defecto de diseño fundamental: solo se encargan de enviar el dinero, pero no controlan qué sucede después de que se envía.

El problema está en que "después de enviarlo" es precisamente la parte más compleja del pago.

La lógica de la API de PSP es sincrónica: envías un comando y recibes un resultado. Pero el flujo real de fondos es asincrónico: los asentamientos se completan después, los fallos se manifiestan con retraso, y los reembolsos y ajustes pueden regresar en cualquier momento. Este desajuste crea un agujero de información persistente.

La manifestación concreta del agujero negro es la fragmentación del estado:

Ningún nodo puede decirte cuál es el estado real de este dinero en este momento.

Tomando como ejemplo el retiro de un vendedor en la plataforma del mercado, todo el proceso es una cadena larga: verificación de elegibilidad → cumplimiento y control de riesgos → confirmación de fondos → emisión de instrucciones → ejecución del canal → retorno de confirmación → liquidación posterior → actualización del libro mayor. El PSP solo cubre algunos de los pasos intermedios; las decisiones iniciales y la conciliación final no están dentro de su ámbito de responsabilidad. Si este pago falla o es rechazado, ningún sistema puede proporcionar una respuesta completa.

Este es el propósito de la capa de conciliación interna: no reemplaza al PSP en la ejecución de pagos, sino que establece una capa unificada de observación por encima de toda la cadena, traduciendo continuamente eventos asincrónicos provenientes de diferentes proveedores, en distintos momentos y formatos, en un único estado confiable dentro de la empresa. Sin importar cuántos intermediarios atraviese el dinero, siempre existe un lugar que puede responder la pregunta más básica: ¿dónde está exactamente este dinero ahora?

Tres. Limitaciones de pago de los PSP tradicionales

La capa de abstracción de los PSP tradicionales se construye en torno al pago con tarjetas bancarias: autorización, captura y liquidación, con un ciclo de vida predecible. Aunque existen excepciones (como disputas y rechazos), la estructura general es predecible y bien comprendida. Este modelo ha moldeado la forma en que se diseñan los PSP.

Con la aparición de nuevos métodos de pago, los PSP amplían su soporte a más vías, pero estas vías se comportan de manera diferente a las tarjetas bancarias y no cumplen con las mismas suposiciones:

• Transferencias ACH: Se ha introducido un retraso, así como la posibilidad de que la transacción sea rechazada varios días después de que se inicie el pago.
• Wire transfer: Faster settlement, but typically requires manual processes and higher costs.
• Redes de pagos en tiempo real como RTP y FedNow: permiten la transferencia inmediata de fondos, pero las transacciones suelen ser irreversibles una vez completadas.
• Transferencias de stablecoins: operan sobre infraestructuras completamente diferentes, con mecanismos de garantía y consideraciones operativas distintas.

Por ejemplo, con un pago de una empresa estadounidense a un proveedor filipino:

• ACH, llega en T+2, pero los bancos de Filipinas no reciben ACH directamente; se requiere una conversión adicional a una red local, por lo que el depósito real puede tardar T+4, y en cualquier momento puede rechazarse debido a incompatibilidades en la información de la cuenta.
• Use transferencia bancaria; es más rápida, pero debe enviarse antes del corte de transferencias a las 3 p.m., y en caso de feriados, se pospondrá. La comisión SWIFT es de $25 a $45, y el banco receptor puede cobrar adicionalmente una tarifa de banco intermedio, por lo que el monto final recibido puede no coincidir con el monto enviado.
• Utiliza el sandwich de stablecoin: USDC se envía desde una cuenta estadounidense, se confirma en la cadena en segundos, y tras recibirlo, tu socio en Filipinas lo convierte a pesos y lo deposita en tu cuenta local, todo en menos de una hora y con un costo inferior al 1% del monto transferido.

Tres caminos, el mismo dinero, tiempos de liquidación que difieren en 96 horas, costos que varían en decenas de dólares y niveles de rastreabilidad completamente distintos. Esto no es una diferencia en la experiencia del producto, sino una diferencia entre tres sistemas operativos distintos. La capa de abstracción del PSP no puede ocultar estas diferencias; solo las transmite a los desarrolladores y equipos operativos para que las asuman.

These are not variants of the same payment model, but fundamentally different operational models.

La forma en que los PSP tradicionales abordan esto es proporcionar APIs y definiciones de estado diferentes para cada pista: no se unifican realmente las diferencias, sino que se elevan hacia los desarrolladores. Los equipos de ingeniería comenzaron a escribir lógica especial para cada pista, los equipos de operaciones comenzaron a manejar manualmente distintos modos de fallo, y los equipos financieros comenzaron a reconciliar transacciones similares que siguieron rutas completamente diferentes.

Esto es una fuga de abstracción: la complejidad de la pista, que debería haberse ocultado, comienza a filtrarse hacia la capa de aplicación.

A medida que se añaden más vías, el entorno de pago se convierte en una serie de integraciones sueltamente conectadas en lugar de una capa abstracta unificada. En las vías más lentas, la latencia proporciona una ventana de tiempo para detectar problemas. En la vía en tiempo real, esta ventana desaparece: los pagos se liquidan en cuestión de segundos, los errores no se pueden revertir fácilmente y las decisiones deben tomarse antes de que se muevan los fondos, no después.

Cuatro: Los pagos en tiempo real obligan a los PSP a adelantar el control

La transición a una red de pagos en tiempo real no solo acelera la velocidad de flujo de fondos, sino que transforma fundamentalmente los requisitos de diseño de la infraestructura de pagos.

En la era de ACH y transferencias bancarias, el tiempo es un amortiguador.

ACH puede tardar varios días en liquidarse, las transacciones con tarjeta bancaria pueden disputarse tras la autorización, y las transferencias electrónicas suelen implicar pasos de revisión manual. Estos retrasos, aunque generan pérdida de eficiencia, ofrecen la oportunidad de detectar errores, intervenir en actividades sospechosas y realizar la conciliación antes de que la liquidación se finalice.

El modelo PSP tradicional se construye precisamente en torno a este buffer.

Sin embargo, redes de pagos en tiempo real como RTP y FedNow han desafiado por completo este supuesto. Los fondos fluyen directamente entre cuentas en cuestión de segundos, y los pagos suelen ser irreversibles una vez completados.

• La detección de fraude debe completarse más temprano
• La revisión de cumplimiento debe realizarse en tiempo real
• Las decisiones de fondos deben completarse con precisión en el momento de la liberación del pago.
• La oportunidad de corregir errores después del hecho ya no existe

Las plataformas que ofrecen pagos inmediatos no pueden depender de flujos de trabajo diseñados para liquidación diferida. Los sistemas internos de empresas que gestionan fondos de pago en múltiples cuentas no pueden determinar la liquidez en el momento de la ejecución. El equipo de servicio al cliente no puede garantizar la reversibilidad cuando la infraestructura subyacente no lo permite.

El resultado es la transferencia de responsabilidad: los PSP deben evolucionar para admitir los sistemas internos que deciden cuándo se debe ejecutar el pago. En otras palabras, el control debe avanzar.

La infraestructura de pago debe diseñarse de modo que la aprobación, la lógica de fondos, la verificación de riesgos y la validación del estado se completen antes del flujo de fondos, no después. Esto requiere una visión más coordinada de los saldos, el estado de las transacciones y las condiciones entre proveedores que la que ofrecen las arquitecturas tradicionales de PSP.

La pista en tiempo real no es un estado final, sino solo un punto de inflexión. Después de que entren las monedas estables, el problema se elevará a un nivel superior.

V. Stablecoins: un nuevo rumbo, no un nuevo método de pago

La parte más mal entendida de las criptomonedas estables es considerarlas un nuevo producto de pago. No lo son. Son una nueva vía de liquidación que resuelve el retraso entre el momento en que la contabilidad se completa y el momento en que los fondos se reciben realmente.

A diferencia de las tarjetas, ACH y transferencias bancarias, las transacciones en stablecoins se ejecutan en redes blockchain:

• The settlement is ongoing, not batched.
• Confirmación final casi instantánea (depende de la red)
• Funciona 24/7, sin restricciones de horarios de cierre bancario ni feriados
• No depende de sistemas de pago nacionales específicos
• Los primitivos para rastrear saldos, propiedad e historial de transacciones son completamente diferentes

La arquitectura tradicional de PSP se construyó en torno a la integración con bancos y redes de pago, pero las stablecoins introdujeron redes que no dependen de estos intermediarios. El origen, el asentamiento y la contabilidad ocurren fuera del diseño original. Una empresa puede necesitar coordinar simultáneamente vías bancarias, redes en tiempo real y asentamiento en cadena, donde cada tipo asume diferentes condiciones sobre finalidad, temporización y control: estas diferencias no pueden unificarse mediante una sola API, lo que hace cada vez más difícil mantener la posición del PSP como una capa de abstracción única.

Al igual que los sistemas de pago en tiempo real desafían las suposiciones sobre la secuencia y la revocabilidad, las monedas estables desafían las suposiciones sobre el lugar y la forma en que ocurren los pagos.

During this process, they introduced a new layer of complexity.

El sándwich de stablecoins es la ruta de implementación más práctica actual: entrada de fiat → circulación en la cadena → salida de fiat.

Los clientes y proveedores en ambos extremos no necesitan entender las stablecoins; las stablecoins son simplemente un canal intermedio diseñado específicamente para resolver la lentitud, el alto costo y la inestabilidad del proceso de liquidación transfronteriza tradicional. Las aplicaciones más valiosas se centran en los «canales difíciles», es decir, escenarios transfronterizos donde los métodos tradicionales son lentos, costosos o simplemente inalcanzables.

Las empresas no deberán ni deberían hacer All-in en stablecoins; el camino realista es seleccionar uno o dos casos de uso específicos para reemplazos parciales, establecer reconocimiento y luego ampliar.

Las stablecoins también aportan una dimensión adicional: los rendimientos sobre fondos en tránsito, algo casi inexistente en los sistemas tradicionales. En los procesos de pago tradicionales, los fondos permanecen bloqueados entre 24 y 72 horas desde su envío hasta su recepción, generando ningún rendimiento y ocupando capital de trabajo. Las stablecoins en cadena pueden generar rendimientos mientras están en movimiento—esto no es una ligera optimización del costo de pago, sino una reestructuración de toda la lógica de eficiencia de fondos.

Seis: El ecosistema actual: Diez niveles de especialización y la capa que falta

A medida que la infraestructura de pagos abarca más vías, más proveedores y más tipos de infraestructura, se vuelve cada vez más difícil definir el papel de los PSP.

Las responsabilidades de movimiento de fondos que anteriormente estaban agrupadas dentro de un único PSP ahora se han distribuido como una serie de responsabilidades en múltiples niveles de la pila tecnológica.

El trabajo de PSP ya no es solo mover fondos, sino explicar el flujo de fondos.

Este cambio refleja un cambio más profundo: ya no basta con simplemente ejecutar. Los PSP ahora deben respaldar los sistemas internos de las empresas para que puedan representar, contabilizar y conciliar cómo fluyen los fondos a través de diferentes entornos.

① Plataforma de capa de producto: Integrar pagos en el software

Plataformas de software verticales como Shopify, Square, Toast, Mindbody, ServiceTitan y Housecall Pro integran directamente los pagos en sus productos.

En estos escenarios, el pago se integra en la experiencia de la aplicación, en lugar de tratarse como un sistema de pago independiente. Estas plataformas suelen depender de PSP subyacentes, socios bancarios y proveedores de infraestructura, añadiendo otra capa de abstracción entre la aplicación y el flujo de fondos.

② Capa de ejecución: Transferencia de fondos entre órbitas

La columna vertebral de la pila tecnológica es el proveedor de servicios de pago encargado de ejecutar los pagos. Incluye PSP tradicionales como Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei y dLocal, cuyo rol es conectar a las empresas con las vías de pago y facilitar la transferencia de fondos.

Aún son componentes clave de la pila de tecnología de pagos, pero operan principalmente en la capa de ejecución: inician pagos, informan sobre el estado y exponen API, pero no proporcionan por sí mismas un modelo completo de cómo fluyen los fondos entre proveedores y sistemas internos.

Le preguntas a Stripe «¿Dónde está exactamente este dinero ahora?», y solo puede decirte qué ocurrió en su propia parte. Stripe es solo uno de los nodos; esta transacción puede incluir también PSP, bancos, vías, libros internos y otros cuatro o cinco pasos, pero lo que ve es siempre parcial, no global.

③ Capa de orquestación y enrutamiento: Conexión con proveedores de ejecución

A medida que las empresas adoptan múltiples PSP y métodos de pago, han surgido plataformas de orquestación encargadas de gestionar el enrutamiento entre proveedores. Empresas como Primer, Gr4vy, Spreedly, Paydock y CellPoint Digital permiten a las empresas dirigir transacciones según la región, el costo o el rendimiento. Estos sistemas mejoran la flexibilidad en la capa de ejecución, pero no ofrecen un modelo unificado para el comportamiento tras el inicio del pago.

④ Capa de gestión de riesgos y cumplimiento: determina si los fondos deben moverse

Un conjunto de proveedores independientes se encarga de determinar si se debe permitir el avance del pago. Los sistemas de verificación de identidad, detección de fraude y cumplimiento de proveedores como Persona, Sardine, Alloy, Unit21, Sift y Sumsub evalúan a los usuarios y las transacciones antes de su ejecución. En entornos en tiempo real, estas decisiones deben completarse antes de que se muevan los fondos, por lo que la lógica de control clave se ha trasladado fuera del PSP.

⑤ Capa de infraestructura bancaria: posee fondos y admite el acceso

Bancos custodios como Cross River Bank, Lead Bank, Column y Sutton Bank ofrecen cuentas reguladas y acceso a redes de pagos. Mantienen los fondos de los clientes, gestionan la liquidez y actúan como puertas de acceso a canales como ACH, transferencias electrónicas, RTP y FedNow. Esta capa es esencial para el acceso al sistema financiero, pero opera independientemente de la lógica de la aplicación y las API de PSP.

⑥ Capa de emisión de tarjetas: ampliación de funciones de pago

Plataformas de emisión de tarjetas como Marqeta, Lithic y Rain permiten a las empresas emitir tarjetas de débito y crédito como parte de sus productos, respaldando escenarios de uso como gestión de gastos, tarjetas empresariales y consumo en mercados. Las plataformas de emisión conectan bancos y redes de tarjetas, pero operan como una capa independiente dentro de la pila tecnológica, introduciendo flujos de trabajo, mecanismos de control y estados adicionales que requieren coordinación con otras partes de la pila de pagos.

⑦ Capa de pago: red de ejecución subyacente

Las vías de pago son redes que mueven fondos entre instituciones financieras. Las vías tradicionales incluyen ACH, transferencias electrónicas y redes de tarjetas, mientras que nuevas redes como RTP y FedNow permiten liquidación en tiempo real. Cada vía tiene supuestos diferentes en términos de temporización, finalidad y reversibilidad, generando inconsistencias que los PSP deben exponer o evitar (y no abstractar por completo).

⑧ Capa de red de stablecoins: Extensión más allá de la infraestructura bancaria

Las redes de stablecoins como Ethereum, Solana, Polygon y Base han introducido una nueva forma de infraestructura de pagos que opera fuera del sistema bancario tradicional. Estas redes permiten la transferencia de dólares digitales en una infraestructura global, utilizando distintos modelos de liquidación y mecanismos de garantía. Amplían el alcance del sistema de pagos más allá de las vías basadas en bancos, añadiendo una capa adicional de complejidad que debe integrarse en los flujos de trabajo existentes.

⑨ Capa de Banco como Servicio: Conectar aplicaciones con bancos

Plataformas de banco como servicio (BaaS), como Unit, Galileo y Treasury Prime, proporcionan la infraestructura para conectar aplicaciones de tecnología financiera con bancos regulados. Permiten a las empresas ofrecer capacidades de cuentas, tarjetas y pagos sin necesidad de ser bancos. Esta capa simplifica el acceso a la infraestructura bancaria, pero añade otra parte intermedia entre la aplicación, el PSP y el flujo de fondos subyacente.

⑩ La capa que faltaba: un PSP unificado que cubre todo el ciclo de vida del flujo de fondos

Mirando las nueve capas anteriores, la regla es consistente: cada proveedor se encarga de una función específica, y ninguno puede proporcionar por sí solo una visión completa del flujo de fondos—incluyendo su comprensión, control y conciliación.

La ejecución la maneja un proveedor, las decisiones de riesgo las toma otro, y los fondos se mantienen en un banco; el proceso de pago puede extenderse a través de redes de tarjetas, vías en tiempo real y sistemas en cadena. Cada sistema expone diferentes datos, cronologías y definiciones de estado.

En un entorno fragmentado, este problema no se manifiesta en la fase de inicio, sino después: cuando el sistema presenta divergencias, los fondos se retrasan o se devuelven, y el equipo necesita respuestas. Aquí es donde comienza a colapsar el sistema de pagos.

Seven: ¿Dónde se colapsa la operación de pagos?

A las 2:55 p.m. del viernes, el equipo de finanzas envió una transferencia bancaria de $50,000 a un proveedor. A las 3:00 p.m., se cerró el límite de transferencias bancarias. El sistema muestra «enviado», pero el correo de confirmación no ha llegado.

A las 4:00 p.m., el proveedor envió un mensaje preguntando por el estado del pago. El departamento financiero revisó el panel del PSP, que mostraba «En proceso». Luego verificó la cuenta bancaria, que mostraba «Pendiente de liquidación». Dos sistemas, el mismo pago, dos estados diferentes, ninguno de los cuales te indica en qué nodo se encuentra el dinero.

A las 5 p.m. del viernes, el servicio al cliente del banco finaliza su jornada. Los proveedores esperan la programación del pago para el envío de fin de semana. El equipo financiero no sabe qué decir a los proveedores ni si el dinero se acreditará automáticamente el lunes por la mañana o si ya fue reembolsado y debe reenviarse.

Esto no es una situación extrema, sino un escenario que el equipo de operaciones de pagos experimenta semanalmente. No aparece en el manual de producto del PSP, pero sí aparece en los registros de trabajo de cada equipo de pagos transfronterizos.

Los problemas más complicados en los pagos suelen no estar en la fase de inicio, sino después, cuando el equipo necesita explicar qué sucedió exactamente.

El mapa del mercado del capítulo anterior reveló la amplitud del ecosistema de pagos. Un pago que parece único a menudo pasa por múltiples proveedores en la pila tecnológica antes de que se realice el asentamiento. Cada parte puede tener una representación diferente del mismo movimiento de fondos, con distintos tiempos, estados diferentes, documentos que llegan según cronogramas distintos y anomalías reportadas a través de canales diversos.

Este es exactamente el punto en que las operaciones de pago se vuelven difíciles.

Reconciliación: múltiples versiones del mismo evento

El equipo financiero debe hacer coincidir los libros internos con los movimientos bancarios, los informes de liquidación y los datos de los procesadores. Si un proveedor muestra que el pago ya se completó, mientras que otro indica que aún está en proceso, la empresa necesita un modelo para resolver estas diferencias. Si una devolución llega después de que el saldo interno ya se haya actualizado, el libro debe anularse o ajustarse en consecuencia.

Manejo de excepciones: fallas sin asignación clara

Una retirada puede fallar debido a una cuenta de destino inválida, el uso de una cuenta de fondos incorrecta, la suspensión de la transacción por revisión de cumplimiento o el incumplimiento del plazo de la vía. Estos fallos no son iguales ni ocurren al mismo tiempo. Sin embargo, los usuarios aún esperan una respuesta consistente, y el equipo interno aún debe gestionar el proceso.

Liquidez y fondos: El dinero está en el lugar equivocado

Las empresas que operan a través de múltiples proveedores y cuentas deben garantizar que los fondos correctos lleguen a la cuenta adecuada en el momento preciso. Incluso si el saldo total es suficiente, si los fondos permanecen en una cuenta incorrecta, la ejecución del pago puede fallar, creando una brecha entre la lógica del producto y la realidad operativa.

Auditoría y control: Reconstructar lo que ocurrió

Las operaciones de aprobación, suspensión, liberación y conciliación ocurren entre equipos y sistemas; las empresas necesitan registros confiables de quién hizo qué, cuándo y por qué. Esto no solo es un requisito de cumplimiento, sino también la base para rastrear el historial de transacciones en caso de problemas.

These issues are both operational and architectural.

El mayor fracaso en la operación de pagos suele ocurrir cuando el equipo no puede responder una pregunta sencilla: ¿dónde está el dinero?

Lo que falta no es otro proveedor que realice pagos, enrute transacciones o mantenga fondos dentro de los modelos existentes, sino un PSP evolucionado capaz de coordinar todas estas funciones, rastrear estados entre proveedores, gestionar flujos de fondos y mantener registros financieros confiables a lo largo del tiempo.

Ocho. La próxima evolución de PSP

El desafío no radica en acceder a la infraestructura de pagos, sino en mantener una comprensión consistente y confiable de cómo fluyen los fondos dentro de ella.

La división actual del ecosistema: PSP realiza pagos, los bancos mantienen los fondos, los sistemas de cumplimiento evalúan riesgos y las herramientas de orquestación enrutan las transacciones. Sin embargo, ningún proveedor único se encarga de proporcionar una vista completa y coherente del flujo de fondos durante todo el ciclo de vida del pago.

La próxima dirección de evolución de PSP es proporcionar visibilidad consistente en toda la pila tecnológica: hacer que cada pago, desde su inicio hasta su liquidación final, sea comprensible, contabilizable y confiable.

Esta capa debe poder:

• Realizar pagos a través de bancos, redes tradicionales y redes de stablecoins
• Mantener un sistema de registro consistente a través de un libro interno
• Flujo de trabajo para la aprobación de gestión, fondos y manejo de anomalías
• Reconciliar actividades externas con el estado financiero interno
• Al escalar, conecta con infraestructura de cumplimiento incorporada, cuentas y trayectorias de crecimiento continuo

Conclusión: ¿Por dónde empezar?

La infraestructura de pagos moderna ya no está definida por un solo procesador o una sola vía. Es un entorno compuesto por múltiples proveedores, cada uno responsable de diferentes etapas del flujo de fondos, aprobación, liquidación y contabilidad.

A lo largo de esta guía, hemos visto la evolución de este entorno:

Los proveedores de pagos han ido más allá del procesamiento de transacciones, con una creciente variedad de vías de pago; los sistemas en tiempo real han eliminado la red de seguridad de la liquidación diferida, y nuevas formas de infraestructura, como las monedas estables, han ampliado aún más todo el sistema.

Para los equipos que construyen productos financieros o integran pagos en software, la vía de entrada es más importante que las discusiones estratégicas.

No comiences con la pregunta de si se adoptan completamente las stablecoins; en su lugar, identifica un problema específico: una vía transfronteriza con liquidación demasiado lenta, un proceso de pago a proveedores que requiere demasiadas operaciones manuales, o fondos ociosos que no generan rendimiento durante el tránsito. Elige un caso de uso, abre una cuenta y realiza un pago real. Inicia con una prueba interna, comenzando por escenarios de gestión de tesorería (treasury), en lugar de modificar directamente los procesos del cliente. Así podrás controlar el riesgo y construir al mismo tiempo conocimiento.

En términos de cumplimiento, las normas de KYC, AML y escaneo de sanciones siguen aplicándose plenamente; las stablecoins solo representan un cambio en el nivel subyacente. El marco regulatorio se ha vuelto mucho más claro tras la Ley GENIUS que hace dos años, y no debería ser un obstáculo para el piloto.

El verdadero riesgo estratégico no es si usas o no stablecoins, sino que tus competidores hayan reestructurado sus costos de liquidación y eficiencia de capital con stablecoins, mientras tú sigues esperando el momento perfecto para entrar.

Sin una capa de coordinación unificada, la complejidad se acumula a medida que crece la escala. Con ella, las empresas pueden operar los flujos de efectivo con claridad, control y confianza.

Parte del contenido proviene de: Modern Treasury — Una guía práctica sobre PSPs en 2026