Contexto
Un marketplace vende clases, citas o paquetes que un tercero ejecuta: el usuario paga a la plataforma, pero el valor real se entrega cuando el profesional cumple el servicio. Finanzas necesita saber qué se cobró, operaciones qué se consumió y cada proveedor qué le corresponde liquidar — sin mezclar saldos entre proveedores ni duplicar “derechos” en hojas paralelas.
Suele ocurrir que el cargo al cliente (pasarela) y el reconocimiento del servicio (app, agenda, check-in) viven en sistemas distintos: un reembolso parcial no se refleja igual en el crédito del usuario, una no-show deja el pago en un limbo y las comisiones se recalculan a mano al cierre. VaultyCore actúa como registro de derechos de servicio (quién puede consumir qué, con quién y hasta cuándo) y de los hechos que disparan liquidación o disputa.
Dolores habituales
- Saldo del usuario vs. reparto al proveedor: el cliente ve “créditos” pero el taller no sabe si ya puede cobrar o si sigue pendiente de confirmación.
- Bundles y packs opacos: varias sesiones en un solo pago; no queda claro qué parte se libera por sesión completada.
- Disputas sin hilo único: “no asistí / sí asistí” sin una secuencia de hechos que financiero y soporte lean igual.
Qué se modela en VaultyCore
- Derechos de servicio por compra: créditos vinculados a proveedor, tipo de sesión o paquete, con límites de tiempo o de usos.
- Ciclos de vida: emisión al cobrar, consumo parcial o total, cancelación, re-booking y extensión — cada evento como hecho verificable.
- Condiciones de liquidación explícitas (por ejemplo: “liberado al marcar completado por el proveedor y sin disputa abierta”).
- Separación por bóveda para marcas, ciudades o líneas de negocio que comparten la misma plataforma.
Cobro al cliente frente a liquidación al proveedor
VaultyCore no sustituye a tu pasarela ni a tu ERP de pagos: ordena los derechos que el marketplace y las apps de proveedor deben respetar. El flujo sano es: se confirma el pago o el acuerdo → se emiten los derechos de servicio en el registro → el cumplimiento (o la disputa) se registra como hechos → finanzas concilia comisiones y pagos a terceros contra esa cadena, no contra estimaciones sueltas.
¿Operas un marketplace de servicios y necesitas créditos auditables por proveedor? Te mostramos cómo VaultyCore encaja entre cobro, agenda y liquidación.
Flujo operativo típico
- El checkout o el contrato B2B confirma el pago y las condiciones (comisión, ventana de validez, proveedor asignado o elegible).
- VaultyCore emite los derechos correspondientes (pases, créditos o sesiones) en el registro verificable.
- La agenda o el flujo operativo consume o libera derechos al completarse el servicio o al activarse una política de cancelación.
- Finanzas y el proveedor revisan la cadena de hechos para pagos, comisiones y disputas sin reconstruir el caso en tres sistemas.
Multi-proveedor y multi-ciudad
El mismo stack suele atender varios proveedores y zonas con reglas distintas de comisión y moneda. Un único modelo de derechos por bóveda evita que el crédito “global” del usuario se mezcle con el saldo liquidable de un taller concreto.
Resultado
Menos fricción entre lo que el cliente cree tener comprado y lo que el proveedor puede ejecutar; cierres con menos ajustes manuales y una narrativa clara ante auditoría: qué derecho se emitió, quién lo consumió y en qué momento se volvió liquidable.
Split payments complejos, reglas de disputa y re-bookings encadenados se pueden añadir como políticas sobre este registro sin borrar el historial de derechos.