> ## Documentation Index > Fetch the complete documentation index at: https://docs.dmly.io/llms.txt > Use this file to discover all available pages before exploring further. # Take payment for a booking > Charge for an appointment with one of three payment modes — no payment, pay after, or pay before with a 15-minute slot hold. A Service decides whether money changes hands and when. You get three choices: take nothing, confirm the booking and send a pay link afterwards, or hold the slot until the client has actually paid. The mode is a property of the Service, so different services in the same workspace can behave differently — a free consultation takes no payment while a treatment demands payment up front. ## Two things it needs before any of this works **Payment mode lives in Offerings, not Appointments.** You set it on the Service, under [Offerings](/offerings/overview) → **Services**. There is no payment setting on the Appointments screens. **A mode without a price does nothing.** Payment only ever happens on a service priced above zero. Set **Pay before booking** on a service priced at 0 and DMLY ignores it completely — the booking behaves exactly as if no payment were required. The editor tells you as much: **Set a price above 0 to require payment.** You also need a connected payment gateway. Without one, **Pay before booking** stops clients booking on the public booking page and **Pay after the appointment** silently sends no pay link. See [Payments and gateways](/finance/payments-and-gateways) — connect one before you switch a live service to a paid mode. ## Set the payment mode Go to **Offerings → Services** and edit the service you want to charge for. A price of 0 makes every payment mode inert. Pick **No payment required**, **Pay after the appointment**, or **Pay before booking**. If no gateway is connected you get a warning here: **No payment gateway is connected, so clients won't be able to pay. Connect one in settings.** Add-ons have no payment mode — they are never bookable and are sold as extras on an order. ## The three modes The default. The booking confirms immediately and DMLY never mentions money. Use it for consultations, or when you take payment in person. The booking confirms immediately, then DMLY sends the client a pay link. The booking is real whether or not they pay. The slot is held, not booked. It only becomes a real appointment once the payment clears. ### Pay after the appointment The booking is confirmed first — the client gets their confirmation, the reminders are scheduled, the slot is yours. Only then does DMLY mint a checkout link and message it to the client on their active channel. The message reads `💳 Complete your payment for : `. This step is best-effort by design. If no gateway is connected, or the gateway errors, or the message can't be delivered, **the booking stays confirmed and unpaid**. Nothing rolls back and nothing warns you. Treat pay-after as an invoice you sent, not as money you collected — check the booking's paid state rather than assuming. ### Pay before booking The slot is **held** for 15 minutes while the client checks out, then confirmed by the gateway. During the hold the booking exists but almost nothing else does: * No confirmation message to the client. * No reminders scheduled. * No push to your connected calendar. * No `appointment_booked` trigger, so any [Automation](/automation/overview) hanging off a booking stays quiet. All of it fires the moment payment clears — not before. This is deliberate: a client who abandons checkout never gets a confirmation for an appointment they don't have. The held slot is genuinely blocked, so nobody else can take it while the first client pays. If no gateway is connected, the public booking page refuses a pay-before booking before any hold is created. The client sees: **Online payment isn’t available right now. Please contact us to book this service.** An AI chatbot booking releases the slot again and hands off to a human; a booking created through the API holds the slot with no pay link until the hold expires. Connect the gateway first. ## When payment never lands Every 15-minute hold ends one of three ways. | What happened | Booking becomes | The slot | | --------------------------------------- | --------------------------------------------------------------------------- | ------------------- | | Payment succeeded | Confirmed and paid — confirmation, reminders and calendar push all fire now | Kept | | The client never paid within 15 minutes | Expired | Freed automatically | | The gateway reported a failed payment | Payment failed | Freed | A background sweep runs every minute and releases holds past their deadline, so a freed slot comes back on the booking page within about a minute. Either way, any reminders queued for that booking are skipped — they never fire for a booking that fell through. Expired and payment-failed are both **final**. DMLY does not re-hold the slot, chase the client, or reopen the booking. If they still want the appointment, they book again. **A payment that arrives after the slot was released is not applied to the booking.** The slot may already have been re-booked by someone else, so DMLY refuses to resurrect it. Instead it flags the booking for manual refund or review and writes a timestamped note on it: *Payment succeeded after the slot was released — needs refund/review.* Nobody is messaged automatically. You have taken the client's money without giving them an appointment, so refund or rebook them by hand. ## What the client is charged The charge is priced off the booking's own price snapshot, taken at the moment the slot was held — not the service's live price. Editing the price in **Offerings → Services** while someone is mid-checkout cannot change what their gateway charges. Tax comes from the service's own **Tax rate (%)** field in **Offerings → Services**, applied to that snapshotted price. Leave the field blank and the booking is charged with **no tax** — the workspace default tax in [Finance settings](/finance/settings) is not consulted at checkout, despite the field's hint reading *Leave blank to use the default tax rate*. Invoices do fall back to that default, so a service with a blank rate can be charged untaxed while its invoice shows tax. Set the rate on the service itself if you need bookings taxed. ## Paid classes Classes follow the same three modes, set on the class Service. Two differences worth knowing: * A pay-before class seat is held the same way, and released the same way. Releasing it frees the place in the session. * When a paid seat is released, the next person on the waitlist is promoted into a **pay-before hold of their own** — a promoted place still has to be paid for, it is not a free seat. See [Classes](/appointments/classes). ## Where payment does not apply Booking someone in yourself from **Appointments → Calendar** never takes payment, whatever the service's mode says. A manual booking is created confirmed and unpaid — no hold, no pay link, no checkout. That is usually what you want when you take a card in person or over the phone, but it does mean the service's payment mode is not a guarantee that every booking on it got paid for. Payment modes do apply to bookings made from the public [booking page](/appointments/booking-page) and by an [AI chatbot](/automation/overview) taking the booking in chat. Through the [API](/api-reference/introduction), only **Pay before booking** is honoured — the response carries `payment_required` and `payment_url`. A **Pay after the appointment** service booked through the API is confirmed with no pay link, so send one yourself. Almost always a hold that expired before the payment webhook arrived. Check the booking — if it is expired or payment failed, and their card was charged, the payment landed after the 15-minute deadline. The booking carries a note saying it needs refund/review. Refund them, or rebook them manually from **Appointments → Calendar** and settle the payment yourself. See [Logs](/troubleshooting/logs) if you need to trace the gateway's side.