A free intro is still a real booking, but it does not open checkout or create a payment record.
Payments
Payments without hidden assumptions
Direct answerUse this page to understand how money works in Consulta. Free intros skip checkout, ordinary one-to-one paid sessions remain simulated, and workshop cohorts can use provider-backed card checkout or configured bank deposit with server-side confirmation.
Paid sessions stay pending until Consulta receives trusted payment status from the server-side payment path.
Silvatech Payments hosted checkout is active for configured workshop cohorts; ordinary one-to-one checkout and WOP-mediated payment sessions keep separate launch 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.
- Ordinary one-to-one checkout remains simulator-first until its callback, late-payment, and production-smoke gates are complete.
- Workshop cohorts can explicitly use production, sandbox, or simulated checkout; production and sandbox reconcile provider status server-side.
- 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.