Marketplace (Split)

definición 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 concepto central entidad originante → genera el checkout, controla la sesión de pago y retiene la comisión (fee) entidades receptoras → reciben su porción del pago según la configuración del nodo split operación padre → transacción principal registrada en la entidad originante operaciones hijas → una transacción derivada por cada entidad receptora del split checkout único → el comprador realiza un único pago; la distribución es transparente para él el split checkout abstrae la complejidad de coordinar múltiples flujos de pago en un modelo multi parte dentro de una única sesión de compra la plataforma suga encapsula todo esto en una única instrucción declarativa un checkout → una sesión de pago → una autorización en el core autorización aprobada → distribución automática entre n entidades del split operación padre + n operaciones hijas → trazabilidad completa por entidad retención opcional (hold) → acreditación condicionada a liberación explícita devolución → reintegro automático proporcional incluyendo comisiones según refundfee rol dentro de la plataforma 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 módulo relacionado relación con split checkout smart acquiring core procesa la autorización del cobro y ejecuta la distribución de fondos entre las entidades del split módulo de checkout provee la sesión de pago unificada sobre la que opera la instrucción de split gestión de transacciones registra la operación padre y cada operación hija como transacciones independientes y trazables módulo de liquidaciones cada entidad receptora participa de su propia liquidación con su porción neta correspondiente hub de prevención de fraude la configuración y gestión de fraude la realiza y controla la entidad originante para toda la operación módulo acl / roles y permisos controla qué entidades pueden ser configuradas como receptoras dentro de un split módulo de medios de pago los medios de pago disponibles en el checkout son los configurados por la entidad originante funcionamiento del módulo modelo de distribución (split) 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 sesión de pago unificada 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 estructura de transacciones cada cobro procesado con split genera una estructura de transacciones relacionadas estructura de transacciones por checkout con split operación padre → registrada en la entidad originante · incluye el total cobrado y la comisión retenida operación hija 1 → registrada en la entidad receptora 1 · monto neto según configuración del split operación hija n → una por cada entidad receptora adicional definida en el array (máximo 50) 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 retención de fondos (hold) 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 devoluciones 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 marketplace vs multivendor diferencias clave dimensión marketplace (split) multivendor división del pago sí, entre originante y receptores según fee configurado no; el 100% de cada venta va al vendedor correspondiente checkout único para toda la operación uno por cada vendedor que interviene medios de pago unificados los del originante cada vendedor gestiona los propios cuotas y financiación las definidas por el originante cada vendedor define las suyas prevención de fraude la configura y gestiona el originante la configura y gestiona cada vendedor costo de procesamiento se cobra al originante se cobra a cada vendedor individualmente caso de uso típico marketplace con comisión, agregadores, plataformas de servicios plataformas donde cada vendedor opera de forma autónoma componentes y funcionalidades principales creación de checkout con 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 experiencia de pago unificada • 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 trazabilidad y operaciones hijas • 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) liberación de fondos retenidos • 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 dimensiones y entidades del módulo entidad descripción checkout con split sesión de pago unificada que incorpora una instrucción de distribución de fondos en el nodo split entidad originante comercio que genera el checkout, controla la experiencia de pago y retiene la comisión sobre cada porción entidad receptora comercio que recibe una porción del pago según la configuración del split debe existir previamente en la plataforma operación padre transacción principal registrada en la entidad originante al procesarse el cobro operación hija transacción derivada registrada en cada entidad receptora, con uid propio y monto neto según split nodo split array de objetos json (máx 50) que define la distribución entity, total, fee, hold, reference, description, refundfee fee monto de comisión que retiene la entidad originante sobre la porción de cada receptora se descuenta del total asignado hold indicador que retiene los fondos de una operación hija hasta su liberación explícita vía api prerequisitos de integración 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 flujo operativo flujo — marketplace split checkout 1 originante crea checkout con nodo split → plataforma valida suma = total 2 respuesta incluye url del checkout + uid de operaciones hijas → originante almacena los uid 3 comprador accede al checkout y completa el pago con su medio de pago 4 smart acquiring core procesa la autorización contra el procesador/red 5 aprobado → se genera la operación padre en la entidad originante 6 plataforma distribuye fondos automáticamente → operación hija por cada entidad receptora 7 si hold true → fondos de esa operación hija retenidos hasta llamada a /release 8 webhooks enviados al originante con resultado de la operación padre e hijas 9 cada entidad receptora participa de su liquidación con su porción neta beneficios y valor operativo dimensión valor que aporta el módulo experiencia de compra unificada el comprador realiza un único pago sin importar cuántas entidades participen de la distribución distribución automática la plataforma resuelve la distribución en el momento de la autorización, sin intervención posterior control centralizado la entidad originante controla medios de pago, cuotas, fraude y experiencia para toda la operación trazabilidad total cada receptor tiene su operación hija con uid propio, consulta y auditoría independiente flexibilidad financiera la retención (hold) permite condicionar la acreditación a eventos externos o validaciones de negocio consistencia financiera la validación de suma garantiza que el 100% del cobro queda asignado antes de procesar el pago integración en liquidaciones cada entidad del split participa en su propia liquidación dentro de la plataforma suga compatibilidad con checkout estándar todas las capacidades del checkout —cuotas, fraude, embebido, webhooks— están disponibles en modo split qué transmite este módulo 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 ✔ distribución automática de fondos en modelos multi parte dentro de una única sesión de pago ✔ experiencia de compra unificada un checkout, un pago, múltiples receptores ✔ control centralizado de medios de pago, cuotas y prevención de fraude por la entidad originante ✔ trazabilidad completa operación padre + operaciones hijas con uid propio por entidad ✔ retención y liberación explícita de fondos para flujos de acreditación condicionada ✔ integración nativa con liquidaciones, conciliación y gestión de transacciones de suga ✔ compatibilidad total con las capacidades del checkout estándar cuotas, fraude, embebido, webhooks