Paid scheduling: pay-to-confirm, deposits and subscriptions

Overview

Paid scheduling connects the Calendar module to the Payments module: when an event type requires payment, the chosen slot is not confirmed right away. It enters an awaiting payment state and only becomes confirmed after Conversa Labs receives the gateway's approval for the payment. That way you only block your agenda for people who actually paid.

Each event type defines how payment works: a one-off charge to confirm, a deposit smaller than the full price, or a subscription — requiring the customer to already be a subscriber, or creating the subscription at the moment of booking.

Prerequisites

• The Calendar module enabled, with at least one event type and availability configured.
• The Payments module enabled, with a gateway connection (Asaas or Mercado Pago).
• For subscriptions, a payment plan created.
• A role with permission to edit event types and charges.

Step by step

1. In Calendar, open the event type you want to charge for.
2. Choose the payment mode (see the table below): none, one-off charge, require a subscription, or subscribe on booking.
3. Set the amount and currency. If the event type is linked to a Catalog product or a plan, the price can come from there.
4. (One-off, optional) set a deposit that is smaller than the full price — only the deposit is charged to confirm; you collect the balance manually or on site.
5. Choose the accepted billing types: PIX, boleto and/or card (hosted link).
6. Pick the gateway connection and, for a subscription, the plan.
7. Set the slot hold mode and the hold time (see "Hold and expiry").
8. Save. From then on, any booking of this type requires payment.

Payment modes

Settings & options

• Amount and currency: the price charged to confirm. Resolution order is: amount set on the event type → the linked Catalog product price → the plan amount. If nothing resolves, the booking is not created (see "Troubleshooting").
• Deposit: only valid for the one-off charge; it must be greater than zero and smaller than the full price. Only the deposit is charged to confirm — the balance is collected later.
• Billing types: a subset of PIX, boleto and card. With nothing selected, it falls back to the account or connection defaults; finally, PIX.
• Connection and plan: the gateway connection that processes the charge; the plan defines the subscription cycle.
• Hold time: how many minutes the slot is held while awaiting payment (default 15).

Hold and expiry

The hold mode decides what happens to the slot while the payment has not arrived:

• Reserve and hold (reserve_and_hold): the slot is held as soon as the customer starts the payment and stays unavailable to others until a deadline (hold_expires_at). An automatic sweep runs every minute: if the deadline passes without payment, it cancels the unpaid charge at the gateway, frees the slot and marks the booking as expired.
• Pay first (pay_first): the slot is not held during payment. When the payment is approved, the slot is re-checked: if it is still free, the booking confirms; if someone took the slot in the meantime, the booking enters payment failed and the (already paid) charge must be refunded manually in Payments.

Booking lifecycle

Use cases

Where it works

Pay-to-confirm applies everywhere a booking is created:

• The public booking page.
• An agent booking directly in the conversation.
• Automation and macros.
• FlowBuilder (including native WhatsApp Flows).
• Maestro (the AI assistant).

Examples:

• Consultations and mentoring sessions that are only confirmed after payment.
• Charging a deposit to reduce no-shows, collecting the balance during the appointment.
• Recurring sessions sold as a subscription.
• Bookings exclusive to subscribers (members book without paying again).

Tips, limits & best practices

• Use PIX to confirm faster; boleto can take days and blow past the hold time.
• Tune the hold time to your scenario: too short expires slow payments; too long ties up idle slots.
• Prefer reserve and hold when the slot is in demand; pay first when you do not want to block your agenda before getting paid.

Cancellation and refund

• Cancelling a paid booking frees the slot and removes the event from Google, but does not refund automatically. A refund is a manual action in the Payments module.
• Refunding or cancelling the charge of an already confirmed booking does not cancel the appointment by itself — the agent decides. Only a booking still awaiting payment is released automatically when its charge fails, is canceled or refunded.

Troubleshooting

• The payment did not confirm the slot: make sure the gateway connection is active and receiving notifications (webhook). The slot only confirms when the gateway reports the charge as paid — the payment success page alone does not confirm it.
• The slot expired before payment: the hold time ran out. The unpaid charge is canceled and the slot is free again — just book again. Increase the hold time if this happens often.
• The amount could not be resolved (error 422): the event type has no computable price — no amount set, no Catalog product with a price, and no plan. Set an amount (or link a product or plan) so the booking can be created.
• In "pay first", the customer paid but lost the slot: someone else booked the same slot before approval. Refund the charge in Payments and offer a new slot, or use reserve and hold to avoid the race.

See also

• Public booking page
• Event types, availability and buffers
• Connect a payment gateway
• Subscriptions and plans
• Refunds, webhooks and reports