Take payment for a booking

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 → 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.

​

Set the payment mode

Add-ons have no payment mode — they are never bookable and are sold as extras on an order.

​

The three modes

​

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 <service name>: <pay link>. 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 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.

​

When payment never lands

Every 15-minute hold ends one of three ways. 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.

​

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 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.

​

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 and by an AI chatbot taking the booking in chat. Through the API, 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.

A client says they paid but the appointment isn't there

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 if you need to trace the gateway’s side.