Request and track deposits

A deposit is requested before the consultation is booked — it secures the booking without blocking it. If the patient prefers to pay at the practice, record that instead; the booking never waits on the link.

Patients who book themselves through online booking pay their deposit inside the booking flow — those deposits appear here automatically with the same refund and no-show lifecycle.

If an online-booking hold expires before payment, Smileline cancels the hold, releases the diary slot and cancels the pending payment request together. If the practice has already recorded an in-person payment, or an attempted refund has failed, the slot is still released but the money record is kept and a Booking payment review task is created for staff. A paid or in-progress refund is left with its automatic booking or refund process instead of being silently cancelled. The same review task is created if the practice management system rejects a slot after money has been collected.

A booking-payment review is durable and separate from the editable task text. Cancelling or editing its task never causes the cancelled paid appointment to reappear. Staff must explicitly arrange a replacement booking or refund the Stripe payment; a practice-collected payment is refunded outside Stripe.

Send a deposit request

From the Today queue or a patient's record, find the Booking deposit card and click its request button, which names the amount — for example Request £25 deposit. On Today the card also sits on the outcome wizard's booked step, under the value, so the link goes out while the consultation is being booked. The card turns amber while the deposit waits and green once it's paid.

Each journey, appointment, or patient-only request can have at most one live deposit request. Cancel the current request before changing its amount.

If the browser loses the response while sending or re-sending, retrying the same action does not create another message. Smileline keeps one send attempt per selected channel and finishes any interrupted handoff automatically. If the request is paid, cancelled or expires before a queued message reaches the channel provider, Smileline does not deliver that stale payment reminder and does not offer to retry it from the Inbox.

Which location a deposit belongs to

Every deposit request records the location its payment is recorded at, so the money lands on that location's ledger, its takings and its month end:

• A request you send takes its journey's location, else the patient's location, else the practice's first location.
• A deposit paid in online booking belongs to the location the patient booked at.

If the visit moves to another location before the deposit is paid, the request moves with it. Once the deposit is paid, it stays at the location its payment was recorded at.

The payment page and the messages a request sends show that location's details, such as its phone number.

A practice with no location can't request a deposit: add one under Locations first.

While it's pending

The deposit block shows the request's state live — it flips to Paid the moment Stripe confirms, so you can complete the booking mid-call.

• Copy link — paste the payment link into any other channel. A request sent before payment links were secured gets a new link here; its old link keeps working until the request expires.
• Pay by card — the patient reads their card out on the call; see Take a card payment over the phone.
• Paid at practice — the patient paid by cash or card in person; the link is voided. Refunds for these are settled in person too.
• Cancel — voids the link. If a patient somehow pays seconds after a cancel, the payment is refunded automatically.

Links expire after the configured number of days and the request is marked Expired. Links sent before payment links were secured (…/l/ followed by ten characters) keep working until their request expires, then stop. A payment that lands moments after expiry still counts — the money is real, so the request flips to Paid.

If the practice enters Closing or Purging, every still-pending deposit link becomes inactive immediately. A deposit confirmed before closure remains recorded and is not refunded merely because the practice closes. If Stripe first confirms payment after closure has begun, Smileline records a durable automatic-refund obligation; a refund that ultimately fails is left visible for staff review.

Opening the link concurrently or retrying after a network error reuses the same Stripe payment-page generation. If Stripe ever reports a second successful payment for the same request, Smileline preserves the original payment and tracks the additional payment as its own automatic refund. A failed additional refund flags the deposit for staff review rather than hiding or resending it. Smileline also rechecks stale payment pages on the connected Stripe account, so a captured payment still converges if its webhook delivery was permanently missed; the same amount, currency and payment-identity checks apply.

Proof of payment

Once the deposit is paid — through the link, by card on the call, or recorded as paid at the practice — the card turns green and shows Proof of payment with Copy. It updates the moment the payment arrives; there's nothing to reload.

The proof is the same link the patient was sent. After payment it opens a proof page with the amount, when and how it was paid and the payment reference, plus View Stripe receipt for a card payment. The link doesn't expire, so you can paste it into a booking or send it to the patient. A request whose link had already expired before Smileline kept payment links shows no proof link.

The deposit on the booking

When staff book a consultation for a patient whose deposit is waiting or paid, Smileline starts the appointment's note with the deposit and its link: Booking deposit £25 — live payment status and proof: …. This happens in the Smileline diary — from Today or the diary — and in Dentally, Open Dental and CareStack when Smileline makes the booking there. The note says no status on purpose: it isn't rewritten when the patient pays later, and the link always shows the current status.

Bookings made by the AI receptionist or through online booking don't get the line.

If Smileline can't book in your practice management system yet, the booked step asks you to Book it in your system then enter the date and time here. Smileline doesn't create that appointment, so copy the link from the deposit card (Copy link while it waits, Proof of payment once paid) and paste it into the booking's notes yourself.

Take a card payment over the phone

If the patient would rather read their card out than use the link, take it yourself while you're on the call.

If the patient's bank wants them to approve the payment, the bank's check opens on your screen and the patient approves it in their banking app while you wait. A practice whose Stripe account takes phone payments (MOTO) skips this check — see Phone payments.

A declined card shows the bank's reason, and you can try another card straight away. Closing the card form stops the card payment; nothing is charged.

While a card payment is in progress, the payment link waits: a patient who opens it is told that a payment is being taken. If the card form closed unexpectedly — for example, the browser crashed — the block shows Card payment in progress with Check with Stripe and Cancel card payment. Smileline also checks unfinished card payments with Stripe in the background, so a payment that went through is recorded as paid even if its confirmation was lost.

After the consultation

• Attended — the deposit is refunded in full automatically. This works whether attendance is recorded in Smileline or arrives from your practice management system sync.
• Did not attend — depending on the practice policy the deposit is either kept automatically or flagged No-show review, where a manager chooses Refund or Forfeit from the patient's record, or from Payments → Deposits in the clinical workspace. See Keeping a deposit.
• Refund failed — rare (for example the patient's card was cancelled); the deposit is flagged and a manager can retry the refund. The money stays in the practice's Stripe balance until a retry succeeds or it's settled out-of-band.
• Refund needs review — Stripe reported conflicting, truncated or differently-owned refund history, so Smileline cannot safely choose an attempt automatically. Automatic recovery stops instead of creating another refund. Review the payment in Stripe and contact Smileline support with the deposit request ID before taking another money action. Support can investigate the evidence, but Smileline does not currently provide an in-product override for conflicting refund history. The review remains visible even if new deposits or connected-account charges are later disabled.

When Stripe has accepted a refund but still reports it as pending, Smileline checks that exact refund directly instead of publishing another refund job. Those checks are bounded to the provider's 35-day settlement window. If the outcome is still unclear at the attempt or deadline limit, the deposit changes to Review required and shows Recheck Stripe. A recheck never creates a second refund; it reads the same Stripe refund ID. Rechecks have a 15-minute cooldown and stop after three attempts, after which you must review the payment in Stripe.

A known partial external refund can offer Refund remainder for only the verified unpaid amount. Queue publication exhaustion remains review-only: Smileline cannot prove that a delivery was not already accepted, so it never creates a second refund generation from a missing queue acknowledgement. Conflicting, truncated, differently-owned, or exhausted recheck evidence is also review-only and shows no money action until the Stripe outcome has been resolved.

If Stripe evidence ever totals more than the original deposit, Smileline shows Review required, disables every refund action and keeps the displayed refunded amount capped at the original deposit. Do not issue another refund. Review the charge in Stripe and contact Smileline support with the deposit request ID.

Stripe can finish an asynchronous refund after it previously reported that attempt as failed or cancelled. Smileline accepts that late success only when the exact refund ID, payment and attempt still match; an older callback can never overwrite a newer refund decision.

Keeping a deposit

When a deposit is kept — a manager clicks Forfeit, or the practice's no-show policy keeps it — the money goes on the patient's ledger at once, as a Deposit kept charge that the deposit pays. What is kept is what is left of the deposit after any refunds. The charge carries no VAT, and the deposit is no longer held for treatment.

A kept deposit can't also pay for treatment, so whatever it had paid is owed again:

• a bill the deposit had paid reads unpaid again on the patient's Account tab, and the balance shows it;
• payment-plan instalments it had settled are open again. A plan that had completed shows An instalment is unpaid again — see An instalment unpaid again.

The deposit block reads Kept · on the ledger as “Deposit kept”. While it reads Kept · not on the ledger yet, Smileline is still posting it — for example, the deposit's payment is waiting in the Review queue — and it posts on its own within a few minutes once it can. Deposits kept before kept deposits reached the ledger are added to it the same way, on their own.

Undo a kept deposit

A manager or owner can click Undo on a kept deposit — after a mis-click, or a no-show recorded in error. Smileline asks you to confirm with the patient's name, then:

1. the deposit goes back to Paid, flagged No-show review, so you can Refund it or Forfeit it again;
2. if its Deposit kept charge is on the ledger, the charge is reversed and the deposit pays again, oldest first, what it can — usually the bill it had paid.

Instalments it had settled stay open: if the deposit was for them, allocate it from the plan.

Refunds of a kept deposit

A kept deposit is the practice's money. To give it back, Undo it first, then Refund it. On the ledger, Refund refuses a kept deposit's payment, and Reverse refuses a deposit's payment and its Deposit kept charge, so the deposit block and the ledger always agree.

• If a refund made at the desk from the deposit's payment is reversed, more of the deposit is left to keep: the kept amount is updated on its own within a few minutes.
• If the deposit is refunded directly in your Stripe dashboard, Smileline reverses the Deposit kept charge and records the refund. If the ledger can't take it at once, the refund waits in the Review queue with the reason and is added within a few minutes once it can. Stripe is never asked to refund it again.

Every request in one list

In the clinical workspace, Payments → Deposits lists every deposit request, newest first, with Load more until the list ends. Narrow it to Awaiting payment, No-show review or Paid, or show All. Each row names the patient with their date of birth, the amount, the request's state and what happens next, and carries the same buttons as the deposit block above. Each row names its location, also one since closed, unless it is the practice's only location, and with more than one location the location picker keeps one location's requests. See Payments.