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. On top of the mode, a pay-before service can take a deposit instead of the full price, and any service can charge a no-show fee when a client doesn’t turn up.

​

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.

​

Take a deposit instead of the full price

A Pay before booking service can ask for part of the price up front. A salon or clinic usually wants a deposit to make a slot cost something to abandon, not to collect the whole fee weeks early. It’s a percentage rather than an amount, so it keeps making sense when you change the price. A 25% deposit on a service costing 60 is 15 to book and 45 at the appointment. The percentage is taken of the full price including tax. The booking page tells the client what they pay now to reserve the slot and what is due at the appointment, and the checkout charges exactly that amount. Everything else works as described above: the slot is held, and the booking confirms when the deposit clears. The balance is yours to collect. DMLY doesn’t send a link for the rest. Take it at the appointment, or send an invoice or payment link yourself. A booking only counts as paid once the full price has been collected, so a deposit-only booking shows as not paid, which is how you spot who still owes you. If you refund a deposit, the full price is owed again.

​

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 uses the workspace default tax from Finance settings, as the field’s hint says (Leave blank to use the default tax rate). Invoices use the same fallback, so a booking and its invoice are taxed the same way. A deposit is a percentage of this taxed total.

​

Charge a fee when someone doesn’t show

A No-show fee charges the client when their appointment is marked as a no-show. It works on any service, whatever its payment mode, including No payment required. Set it in either or both of two places:

• On a service: in Offerings → Services, the No-show fee field, in the service’s currency. Its hint reads Charged when someone is marked as a no-show. Leave blank to use the workspace default.
• As the workspace default: in Appointments → Settings, under Booking policy. It applies to every service that doesn’t set its own. Left blank, it shows No fee.

A service’s own fee wins over the default. To exempt one service from the default, set its fee to 0.

​

When it’s charged

Only when somebody marks the booking as a no-show: from the Appointments screens, the mobile app, the API, an automation step that marks a no-show, or class attendance. An appointment nobody marks is never charged. To make sure no-shows get marked, set Appointments nobody marked to Wait for review; see Past bookings close themselves. The fee comes on top of the usual no-show handling: the appointment_no_show trigger still fires, so your automations run as before.

​

How the money is taken

• A saved card is charged. The client is then messaged that a missed appointment has been charged, and invited to reply if they think it’s wrong.
• Otherwise they’re sent a payment link on the channel they use.

Cards are only saved when a client sets up automatic payment for a subscription, so for most clients the fee arrives as a payment link. A declined card falls back to a link too, rather than being recorded as money you collected. A few rules worth knowing:

• Once per booking. Correcting the status and marking the no-show again doesn’t charge a second time. Changing the status back doesn’t refund it either.
• Separate from any deposit. DMLY doesn’t subtract a deposit the client already paid. If you want the deposit itself to be the penalty, leave the fee blank.
• Charged in the booking’s currency. The workspace default has no currency of its own.

​

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.

​

Bookings your team or the API makes

Booking someone in yourself from Appointments → Calendar on a Pay before booking service works like the booking page, with one difference: there’s no checkout page to send the client to, so DMLY holds the slot and messages them a payment link, for the deposit if the service takes one. The booking confirms once they pay. The hold lasts two hours rather than 15 minutes, because a client booked over the phone needs time to see the message. If you’re taking the money yourself (cash, a card machine, a package they already hold), tick Payment taken in person. The appointment is confirmed straight away and no link is sent. The box only appears for a single confirmed booking: booking several slots at once, or a repeating series, confirms them without taking payment, so collect for those yourself. 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.