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, open the Booking deposit block and click Request deposit.

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.

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

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