Una intro gratis sigue siendo una reserva real, pero no abre checkout ni crea registro de pago.
ConsultaPagos
Pagos sin supuestos ocultos
Usa esta pagina para entender como funciona el dinero en Consulta antes de reservar o conectar proveedores live. El producto esta disenado para consultoria pagada y links compartibles, pero el lanzamiento publico mantiene honestidad sobre modo simulador, prueba de pago del servidor y readiness de proveedores.
Sesiones pagadas quedan pendientes hasta que Consulta recibe estado confiable desde el camino de pago del servidor.
Silvatech Payments, links de pago, QR y pagos mediados por WOP quedan detras de gates de proveedor.
Ruta de intro gratis
Consulta separa agenda gratis de checkout pagado. Las intros gratis confirman sin pago pero usan reglas de horario, pase de confirmacion, calendario, politica y acceso Beam.
- La disponibilidad de intro gratis la configura el consultor.
- Una reserva sin pago igual reserva un horario real.
- La reserva gratis no debilita la regla de prueba de pago para sesiones pagadas.
Ruta de checkout pagado
Reservas pagadas usan estado pending-payment mientras checkout esta activo. El cliente puede volver desde checkout, pero la reserva confirma solo cuando Consulta recibe estado confiable server-side.
- Paginas de retorno del navegador son navegacion, no prueba de pago.
- La creacion de checkout es idempotente por contexto de reserva para evitar intentos duplicados.
- Intentos vencidos o fallidos liberan el horario segun reglas de hold y estado.
Silvatech Payments
Silvatech Payments es el riel de checkout hospedado para reservas de perfil, links tipo factura, pago invitado y QR. Consulta guarda referencias y estado, no numeros de tarjeta.
- El default actual sigue simulator-first hasta completar credenciales, callback y smoke de bajo valor.
- URLs de checkout y QR pertenecen a sesiones de pago del proveedor, no a paginas publicas de discovery.
- Payloads de proveedor y secretos quedan server-side.
WOP y links de pago
Pagos mediados por WOP sirven para WhatsApp, n8n o links creados por agentes. Son utiles cuando el cliente recibe el artefacto de pago por chat o automatizacion.
- Una submission de WhatsApp Flow no es prueba de pago.
- Estado de sesion WOP o callback debe decir paid antes de tratar el pago como pagado.
- Checkout hosted directo sigue como default aburrido para reservas web publicas.
Reembolsos y politica
Reembolsos y politica deben seguir la politica del consultor, estado del proveedor y revision operador cuando aplique. Consulta no debe prometer refunds automaticos hasta probar el proveedor end to end.
- Cambios y cancelaciones siguen ligados a politica desde el pase de confirmacion.
- Estado refunded manual es registro operador, no prueba de que todo refund del proveedor esta automatizado.
- Preguntas sobre setup live deben ir por Contacto o readiness del dashboard protegido.