El módulo Marketplace — Split SmartCheckout habilita la distribución automática del importe de un cobro entre múltiples entidades o comercios dentro de una única sesión de pago. El comprador realiza una sola transacción; la plataforma resuelve internamente cómo se divide ese pago entre la entidad originante y los vendedores o receptores que intervienen en la operación.

Resuelve un problema fundamental en modelos de negocio multi-parte operando en el canal tarjeta no presente: la imposibilidad de distribuir fondos de forma automática, trazable y consistente sin requerir múltiples transacciones ni múltiples sesiones de pago. El comprador vive una experiencia de pago única y unificada; la complejidad de la distribución es resuelta por la plataforma de forma transparente.

Este módulo forma parte del conjunto de capacidades de canal tarjeta no presente de SUGA, específicamente dentro del flujo e-commerce / checkout / VPOS, y comparte el mismo modelo conceptual de split que opera en suscripciones con split y en la operatoria de marketplace presencial vía orden pre-creada.







Dentro de la arquitectura SUGA, el split checkout se posiciona como una extensión del módulo de checkout estándar. No requiere un endpoint diferente ni un flujo de autorización distinto: el nodo split es una instrucción de distribución que se añade al payload del checkout y que el Smart Acquiring Core ejecuta en el momento de procesar la autorización.

Este posicionamiento es relevante porque garantiza que todas las capacidades del checkout estándar —medios de pago configurables, cuotas, prevención de fraude, webhooks, operatoria en dos pasos— están disponibles también en la modalidad marketplace con split, sin necesidad de construir integraciones adicionales.





Cuando se crea un checkout con el nodo split, se declara explícitamente cómo se distribuye el importe total entre las entidades participantes. Cada entrada del array split especifica la entidad receptora, el monto que le corresponde y la comisión que retiene la entidad originante sobre esa porción.



La plataforma valida que la suma de los montos declarados en el array split sea exactamente igual al total del checkout. Si existe discrepancia, la creación del checkout es rechazada con un error de validación. Este control garantiza que el 100% del importe quede asignado sin ambigüedad antes de que el comprador inicie el pago.



El comprador accede a un único checkout, con una única pantalla de pago y una única interacción con su medio de pago. No percibe la distribución interna que opera la plataforma. Los medios de pago disponibles, las cuotas habilitadas y la experiencia visual del checkout son los definidos y controlados por la entidad originante.



Esto diferencia al modelo marketplace (split) del modelo multivendor, donde cada vendedor expone su propio checkout con sus propios medios de pago y cuotas. En el split, la unificación de la experiencia es total.



Cada cobro procesado con split genera una estructura de transacciones relacionadas:





Cada operación hija posee su propio uid, lo que permite consultarla de forma independiente en el módulo de gestión de transacciones, auditarla y ejecutar acciones sobre ella como la liberación de fondos en caso de retención.



El parámetro hold permite configurar que los fondos de una operación hija sean retenidos en lugar de acreditarse automáticamente a la entidad receptora. La retención es útil cuando la acreditación al vendedor está condicionada a una confirmación externa, como la entrega de un producto, la prestación de un servicio o una validación de cumplimiento. La liberación se realiza de forma explícita a través del endpoint de liberación de fondos.



El parámetro refundfee controla si la comisión retenida por la entidad originante se devuelve ante una devolución total de la operación. Su valor por defecto es true, lo que significa que el reintegro al comprador incluye también la comisión. Este comportamiento puede configurarse de forma independiente para cada porción del split.







•       Configuración de hasta 50 entidades receptoras por operación

•       Asignación de monto total y comisión (fee) por entidad receptora

•       Validación automática de consistencia: suma de split igual al total del checkout

•       Generación de uid de operaciones hijas en la respuesta de creación

•       Soporte para retención de fondos (hold) por porción

•       Control de devolución de comisión (refundfee) por porción

•       Descripción y referencia individual por operación hija



•       Checkout único para el comprador, independientemente del número de receptores

•       Medios de pago, cuotas y experiencia visual controlados por la entidad originante

•       Compatibilidad con modo embebido (embed) para integración en sitios propios

•       Soporte para personalización visual (theme) del checkout

•       Incompatible con multicard: el pago con múltiples tarjetas no aplica en operaciones con split



•       Cada porción del split genera una operación hija con uid propio

•       Las operaciones hijas son consultables en el módulo de gestión de transacciones

•       Los uid se devuelven en la respuesta de creación del checkout para su almacenamiento

•       Webhooks de resultado enviados por operación (padre e hijas)



•       Endpoint dedicado para liberar fondos de operaciones hijas con hold activo

•       Liberación individual por operación hija mediante su uid

•       Permite flujos de acreditación condicionada a eventos externos





Para operar el split checkout, deben cumplirse las siguientes condiciones:

•       Todas las entidades receptoras deben existir previamente en la plataforma SUGA.

•       La suma de los montos del array split debe ser exactamente igual al total del checkout.

•       El parámetro multicard no es compatible con operaciones de split y debe omitirse.

•       Los uid de operaciones hijas devueltos en la respuesta deben almacenarse si se utilizará retención de fondos (hold).

•       La autenticación requiere x-api-key y x-access-token en todos los headers.







El módulo Marketplace — Split Checkout demuestra que la plataforma SUGA comprende que los modelos de negocio digitales modernos rara vez involucran una única relación comercial. Los marketplaces, agregadores y plataformas multi-parte requieren que la infraestructura de pagos resuelva la distribución de fondos de forma nativa, sin trasladar esa complejidad a la capa de aplicación ni a la experiencia del comprador.