A free intro is still a real booking, but it does not open checkout or create a payment record.
ConsultaPayments
Payments without hidden assumptions
Use this page to understand how money works in Consulta before booking or connecting live providers. The product is designed for paid consulting and shareable payment links, but the public launch remains honest about simulator mode, server-side payment proof, and provider readiness.
Paid sessions stay pending until Consulta receives trusted payment status from the server-side payment path.
Silvatech Payments, payment links, QR links, and WOP-mediated WhatsApp payment sessions sit behind provider gates.
Free intro path
Consulta separates free scheduling from paid checkout. Free intros confirm without payment while still using slot rules, confirmation passes, calendar handoff, policy actions, and Beam browser access.
- Free intro availability is consultant-configured.
- A no-payment booking still reserves a real slot.
- Free booking does not weaken the paid-session payment proof rule.
Paid checkout path
Paid bookings use a pending-payment state while checkout is in progress. The client may return from a checkout page, but the booking is confirmed only when Consulta receives trusted server-side payment status.
- Browser return pages are navigation, not payment proof.
- Checkout creation is idempotent by booking context so retries do not create duplicate booking intent.
- Expired or failed attempts release the slot according to the hold and booking state rules.
Silvatech Payments
Silvatech Payments is the intended hosted-checkout rail for profile bookings, invoice-style payment links, guest payment, and QR links. Consulta stores references and status, not card numbers.
- The current default remains simulator-first until live credentials, callback proof, and low-value smoke proof are complete.
- Hosted checkout URLs and QR codes belong to provider-backed payment sessions, not public discovery pages.
- Provider payloads and secrets stay server-side.
WOP and payment links
WOP-mediated payment sessions are for WhatsApp, n8n, or agent-created payment links. They are useful when the client receives the payment artifact through a chat or automation path.
- A WhatsApp Flow submission is not payment proof.
- WOP session status or callback proof must say paid before Consulta treats the payment as paid.
- Direct hosted checkout remains the boring default for public web bookings.
Refunds and policy
Refund and policy handling must follow the consultant policy, payment-provider state, and operator review where required. Consulta should not promise automatic refunds until the provider path is proven end to end.
- Reschedule and cancel actions remain policy-bound from the confirmation pass.
- Manual refunded status is an operator record, not proof that every provider refund path is automated.
- Questions about live provider setup should go through Contact or the protected dashboard readiness panels.