How to Accept Appointment Deposits or Full Payment at Booking

Almost everyone arrives here hunting for one field. Something that says deposit: 25 per cent, sitting on the service next to the price, taking a quarter up front and the rest on the day. It is such an obvious thing to want that when you cannot find it, you assume you are looking in the wrong menu.

You are not. There is no deposit percentage setting in DMly. The payment mode called Pay before booking charges the full service price, not a portion of it. Better to know that now than after an afternoon of hunting, and it is far less of an obstacle than it sounds, because appointment deposits are perfectly achievable three other ways, and one of them is arguably better than the field people were looking for.

This guide covers everything appointment deposits actually involve: what the three payment modes really do for you, the fifteen minutes after somebody clicks pay when almost nothing happens, the three real deposit methods and what each one costs you, gateways, tax, and the refund behaviour that catches every business exactly once.

The one that catches everybody, said early: The Refund button in DMly is bookkeeping only. It marks the payment refunded in your records and never contacts your payment provider, so no money moves. You refund in Stripe, PayPal or whoever you use, then mark it in DMly so the two agree. Nobody reads this in advance and everybody meets it once.

The Three Payment Modes Behind Appointment Deposits

Payment mode decides whether money is a condition of the booking or an afterthought, and you set it on the service rather than on the appointment. There are three, and they are not three strengths of one idea. They are three different products.

One rule sits above all three: a price of 0 makes every payment mode inert. A free consultation cannot take money however you set the mode. Obvious once said, quietly baffling when you are staring at a service that stubbornly refuses to charge anybody.

Payment mode lives on the service, under Offerings and then Services, next to the price and the tax rate. That location is the whole trick, as you will see: because money rules live on services rather than on your workspace, different work can have completely different rules, and that is what makes a deposit possible at all.

The Fifteen Minutes When Almost Nothing Happens

Pay before booking holds the slot for fifteen minutes, and during those fifteen minutes your customer thinks they have booked and your system does not agree. This is the most surprising behaviour in the whole appointments system, and building around it without knowing it produces some strange conversations.

While the hold is running, none of this happens:

• No confirmation message goes to the customer.
• No reminders are scheduled.
• No calendar push, so it does not appear on a connected calendar.
• The appointment-booked trigger does not fire, so nothing you built on it runs.

All of it waits for the payment to clear. If the fifteen minutes pass unpaid, the hold expires, the booking is marked expired and the slot is freed automatically, with a background sweep releasing expired holds about every minute. A failed payment frees the slot the same way.

The practical fix is wording, not configuration. A customer who has chosen a time and reached a checkout believes she is finished. Tell her she is not, in the message that takes her there: your slot is held for 15 minutes and the booking is confirmed as soon as the payment goes through. Somebody told that will finish paying. Somebody who assumed she was done will find out at the worst possible moment, which is usually the following Tuesday at ten to nine.

Two smaller behaviours, worth knowing once: The charge uses a price snapshot taken when the slot was held, not the live price, so putting your prices up mid-checkout does not affect somebody already paying. And if a payment lands after the hold has expired and the slot has gone, DMly will not resurrect the booking. It flags it for manual review with a timestamped note, and you sort it out with the customer yourself. Expect that to happen occasionally, and decide in advance who handles it.

Three Ways to Actually Take Appointment Deposits

Since there is no deposit field, a deposit has to be built, and the three ways of building one suit genuinely different businesses. Read all three before choosing, because the obvious one is not always right.

1. The deposit-priced service

Create the service at the deposit amount rather than the full amount, set it to Pay before booking, and collect the balance on the day or afterwards by invoice.

So a colour treatment that costs 200 becomes a service priced at 50 with pay before booking. The name is doing real work here. Colour appointment, 50 deposit is honest and clear. Colour appointment priced at 50 is a complaint waiting to happen at the till.

This is the closest thing to the field people go looking for, and it is what most businesses settle on. Its one weakness is bookkeeping: your service list now carries prices that are not the price of the service, so anything reading those numbers, including your own back-of-envelope maths at the end of the month, needs interpreting.

2. Pay after, with an invoice

Set the service to Pay after the appointment, let the booking confirm immediately, and invoice for the whole amount afterwards. Not a deposit at all, strictly, but for established clients it is often the right answer, and it takes every scrap of checkout friction out of the booking.

Use it where the relationship carries the risk: regulars, account clients, the woman who has been coming every six weeks for three years. Do not use it for a first-time booking on your most expensive slot, which is precisely where the money goes missing. Our guide to sending invoices through WhatsApp covers the collection side properly.

3. Request payment, in amount mode

Separately from the booking flow, DMly can send a payment request for any amount you like, from the Inbox, from a step in a flow, or as an automation action. Send payment link has an amount mode that takes whatever figure you type.

That is a genuine deposit mechanism, and it is more flexible than a percentage field would have been, because the amount can follow the job rather than a rule. A wedding photographer quoting 1,800 can ask for 300; the same photographer quoting 600 can ask for 100. No percentage setting would have let you do that.

The trade is that it sits outside the booking. The appointment confirms whether or not the deposit is paid, so you are relying on a follow-up rather than a gate. Best for quoted work where the deposit is a proportion of an estimate you have just given, rather than for a fixed-price slot on a page.

Most businesses that take appointment deposits seriously end up with the first method on their high-risk services and no payment at all on everything else. That is a better outcome than a blanket policy in either direction, and it is only possible because payment mode lives on the service.

Connecting a Gateway, and the Step Everyone Skips

Appointment deposits collect nothing at all until a payment provider is connected, and there are exactly six DMly can talk to. Stripe, PayPal, Paystack, Razorpay, MyFatoorah and Mercado Pago. If yours is not on that list, taking a deposit through the booking flow is not available to you, and that is a hard limit rather than a setting you have missed. Our guide to setting up payments walks through the connection itself.

Each takes its own credentials, pasted from the provider’s dashboard into Configurations and then Integrations. They are checked when you connect, so a typo fails there rather than at your first real payment.

The webhook step is not optional, and DMly does not do it for you. After you save the credentials you have to add DMly’s webhook endpoint in the provider’s own dashboard. The gateway tile shows you the URL. Skip it and payments will succeed at the provider and never report back, which looks exactly like nobody paying you, and sends people hunting through the wrong settings for an afternoon.

The second thing to get right is which gateway wins. The Default payment gateway card at Finance, then Settings, then Gateways ships on First connected gateway, and almost nobody changes it. Leave it there and the link is minted on the earliest still-connected gateway. So if you connected PayPal in March to try it and Stripe in June to actually use it, your deposits are going through PayPal until you name Stripe in Charge through, and nothing in the interface is going to mention it.

Tax, Tips and Where the Numbers Come From

Tax on a booking comes from that service’s own tax rate, and your workspace tax settings do not apply. Leave the field blank and there is no tax on the booking, quietly and without complaint.

That catches people who duplicate a service to make a deposit version of it: the copy is a new service, and the tax rate is one of the things you need to check on it. It is a ten-second job that saves a conversation with your accountant.

Tips are worth a mention because they are easy to switch on and easy to misplace. They live under Finance, then Settings, then Invoice, behind a Collect tips at checkout toggle, with presets given as a comma-separated list of whole percentages between 1 and 100. DMly takes up to six, removes duplicates and sorts them for you.

The part that matters here: tips apply to invoice pay links and booking payments only. They do not appear on a Request payment, on a Send payment link in amount mode, on orders or on subscription captures. So if you are taking your deposit by the third route above, no tip prompt is going to appear on it. For a mobile therapist or a hairdresser who does home visits, that is the difference between a tip prompt on every job and none at all, and it is worth choosing your deposit route with that in mind.

The Refund Behaviour That Catches Everyone

Refunding in DMly is bookkeeping. It marks the payment refunded in your records and never contacts your payment provider. No money moves. The customer is still waiting.

This is not a bug, and once you know it the workflow is obvious, but it has to be the right way round: refund in the gateway first, then mark it in DMly. Doing it the other way leaves your records saying the customer has been refunded while your bank says otherwise, and the customer messaging you on Thursday to ask where her 50 is.

Two supporting details. The Issue refunds permission is admin-only by default, which is worth reviewing if the person who actually handles refunds is not an admin. And payment statuses move forward only, along Pending, Failed, Succeeded and Refunded, so a late or out-of-order message from a provider cannot reverse something already marked paid.

Make somebody responsible for the pairing. A five-minute check once a week, comparing refunds marked in DMly against refunds actually issued in the gateway, is the whole of the discipline this needs.

What Happens to the Money When Somebody Cancels

Nothing happens to the money automatically, ever. A customer cancelling from their manage page changes the booking, not the payment. There is no automatic refund, no partial refund, no forfeiture rule.

Which means your deposit policy is not a setting. It is a sentence you write, and it belongs in two places: on the terms page you link from your booking page’s Terms URL field, and in the confirmation message the customer actually reads.

A workable one for a small business, in plain words: your deposit holds the appointment and comes off the final bill. Cancel more than 24 hours before and we will refund it. Inside 24 hours we keep it, because we cannot refill the slot. Whatever you choose, write it before you switch anything on, because the first time you have to decide it is while somebody is upset with you.

Then honour it by hand: refund in the gateway, mark it in DMly. That is the whole mechanism, and it is not going to get more automatic than that.

Deposits, No-Shows, and What They Cost You

A deposit is the bluntest instrument available against no-shows, and it works by making some people not book at all. That is the trade, and it is worth stating clearly because most articles pretend deposits are free.

Taking payment before the booking is confirmed is the only mechanism in DMly that makes not turning up cost the customer something. Marking a booking as a no-show afterwards records what happened; it does not take any money.

So point deposits at the slots where an empty chair genuinely hurts: an hour of a specialist’s time, a Saturday, the first appointment of the day, anything three hours long. On a fifteen-minute fringe trim that somebody else will happily take, the friction costs you more than the risk does. The salon automation guide works through the same trade with a real diary attached.

If your no-show rate is the actual problem, deposits are one lever of several, and reminders are the gentler one. Start with the reminders and reach for the deposit on the services where reminders have already failed you.

The Hole in Any Deposit Policy

An appointment created by hand from the Calendar bypasses payment entirely. No hold, no pay link, no checkout, whatever the service is set to do. It is created confirmed and unpaid.

That is genuinely convenient when a regular rings up and you do not want to push her through a checkout to book the thing she has booked forty times. It is also the reason appointment deposits quietly stop happening: once your team learns that adding somebody to the calendar is faster than sending a link, half your bookings stop taking deposits, and nothing in your records will explain why the deposits dried up.

There is no setting for this, so the fix is a rule. Decide which services must always go through the booking page, say it out loud to the people who answer the phone, and glance at the calendar every couple of weeks for manually created bookings on those services. Two minutes, once a fortnight.

Which Services Should Take Appointment Deposits?

Charge for everything and you lose bookings; charge for nothing and you lose slots. The dividing line is almost always what an empty slot costs you and whether you could refill it.

Duplicating a service is a completely legitimate move here. The same treatment can exist twice: once with a deposit for new clients, once without for the people you know, with the second hidden from the public booking page and given out as a direct link. Just check the tax rate on the duplicate, and check the payment mode, because a copy inherits neither of your intentions.

If you keep customer history in one place, deciding who gets which version becomes much less of a guess. Our WhatsApp CRM guide covers keeping that history where the person answering the phone can see it.

Testing It Without Charging Yourself

Sandbox mode exists exactly for this, and it will only ever show you the happy path. In sandbox no gateway is contacted at all, the pay links are fake and predictable, shaped like https://pay.demo/<provider>/<reference>, and a charge always succeeds.

Which is useful and also the limitation: you cannot test a failure in a system where nothing fails. Test the unhappy paths on a live gateway with a small real amount, on a service nobody can see. Half an hour, once.

1. Book a pay-before service and complete the payment. Confirm the booking appears, the confirmation sends and the reminders schedule.
2. Book one and walk away. Wait out the fifteen minutes and confirm the slot comes back and nothing was sent to the customer.
3. Check the appointment-booked trigger fired after payment, not before, so anything you built on it runs at the right moment.
4. Do a real refund end to end, in the gateway and then in DMly, so somebody on your team has done it once before a customer needs it.
5. Check which gateway minted the link if you have more than one connected. On the default Charge through setting, the earliest still-connected one wins.
6. Check the tax on the receipt against that service’s own Tax rate field, especially on a duplicated service.
7. Create a booking from the Calendar on a pay-before service and watch it skip payment entirely, so you have seen the hole with your own eyes.

What You Can Honestly Measure

Nothing in DMly reports on appointment deposits, so the numbers below are counted rather than read off a dashboard. What you have is a payments list with statuses and a Bookings list you can filter by service, staff, status and source.

Four things worth counting, once a month, in about twenty minutes:

• How many pay-before bookings never completed payment. Count the expired and failed ones against the succeeded ones. A high share usually means the price was a surprise rather than that anybody changed their mind, which is a wording problem you can fix.
• Bookings on a service before and after you added a deposit. Filter the Bookings list by that service for the month either side. Deposits suppress some bookings, and you want to know how many rather than assume none.
• No-shows on deposit services against the rest. Filter by status. This is the number that says whether the policy earns its friction.
• Manually created bookings on deposit services. Filter by source. This is your policy leak, and it is the one nobody thinks to look for.

And one pairing check rather than a metric: refunds marked in DMly against refunds actually issued in your gateway. Because refunding here is bookkeeping only, those two lists can drift apart silently, and the first person to notice should not be a customer.

Mistakes Worth Avoiding

Every one of these is common, and all of them are cheaper to read about than to meet.

• Looking for a deposit percentage. There is not one. Price a service at the deposit amount instead.
• Assuming the Refund button refunds anything. It is bookkeeping only. Refund in the gateway first, then mark it.
• Letting a customer believe she has booked during the hold. Fifteen minutes, and nothing has been sent to her.
• Skipping the gateway webhook step. Payments will not report back and it looks exactly like nobody paying.
• Never setting Charge through. On its First connected gateway default, the earliest connection mints the link.
• Relying on workspace tax settings. They do not apply at checkout. Tax comes from the service.
• Setting a payment mode on a service priced at 0. Every mode is inert without a price above zero.
• Letting the team book deposit services from the Calendar. That path skips payment completely.
• Expecting a tip prompt on an amount-mode payment request. Tips only appear on invoice pay links and booking payments.
• Writing the cancellation policy after the first argument. Write it before you switch the deposit on.

Frequently Asked Questions

Can I charge a percentage as one of my appointment deposits?

No. There is no deposit percentage or partial-deposit setting anywhere in DMly, and Pay before booking always charges the full service price. The usual answer is to create the service priced at the deposit amount, take that up front, and collect the balance afterwards by invoice. Name the service so the customer can see what she is paying, for example “Colour appointment, 50 deposit”.

What happens if the customer does not pay within fifteen minutes?

The hold expires, the booking is marked expired and the slot is freed automatically, with a background sweep releasing expired holds about every minute. A failed payment frees the slot the same way. If the money arrives after the slot has gone, DMly will not resurrect the booking: it flags it for manual review with a timestamped note and you sort it out with the customer.

Does the customer get a confirmation while she is paying?

No, and this surprises everybody once. During the hold there is no confirmation message, no reminders, no calendar push and the appointment-booked trigger does not fire. All of it waits for the payment to clear, so say in the checkout message that the slot is held rather than booked.

Does refunding in DMly return the customer’s money?

No. Refunding is bookkeeping only: it marks the payment refunded in your records and never contacts the gateway. You have to issue the real refund in your payment provider’s dashboard, then mark it in DMly so the two agree. The Issue refunds permission is admin-only by default, so check that the person who handles refunds actually has it.

Which payment gateways can I use?

Six, and nothing else: Stripe, PayPal, Paystack, Razorpay, MyFatoorah and Mercado Pago. Paystack is the only one with no webhook secret field. Mercado Pago is pay-link only and cannot charge a saved card. If your provider is not on the list, the booking flow cannot take payment for you.

Why is my deposit going through the wrong gateway?

Because the Default payment gateway card at Finance, then Settings, then Gateways is still on First connected gateway, so the link is minted on the earliest still-connected provider, very often one you connected months ago to try out and then forgot about. Set Charge through to the one you want, then disconnect the one you are not using.

Can I charge a customer for a no-show?

Not automatically. Marking a booking as a no-show records what happened but does not take any money. The only mechanism that makes not turning up cost something is having taken the payment before the booking was confirmed, which means Pay before booking on a service priced at your deposit amount.

Does a deposit get refunded automatically when somebody cancels?

No. Cancelling changes the booking, not the payment, and there is no forfeiture rule or automatic refund of any kind. Your deposit policy is a sentence you write, put on the terms page you link from your booking page and repeat in the confirmation message, then honour by hand in the gateway.

Price the Deposit, Do Not Go Looking for It

The field everybody wants does not exist, and the moment you stop looking for it the shape of this gets simple. Put the deposit in the price of a service that gates the booking. Keep the full amount on the services where a relationship already carries the risk. Use an amount-mode payment request for anything quoted.

Then write down the two things no setting will decide for you: what your message says during those fifteen minutes, and what happens to a deposit when somebody cancels. Both of those are policy, both live outside the software, and both are what people will actually argue with you about.

The rest of appointment deposits is configuration, and most of it sits on a booking page you have already built. Half an hour of testing with a real card, on a service nobody can see, and you will know exactly what your customers get.