AddThisFeature
Sign in

Booking Deposits

Take a partial payment at booking so the slot is held against a real commitment.

moderate Monetization

What it adds

A deposit charged during booking, tracked against the remaining balance and the cancellation policy.

What your agent is told to do

5
  1. 1

    Show the deposit amount, the remaining balance, and the refund terms on the booking screen before payment, not in the confirmation afterwards.

  2. 2

    Hold the slot while payment is in progress, and confirm the booking only once the payment provider reports settlement. Treat an unsettled payment as no booking at all.

  3. 3

    Reuse the app's existing hosted checkout and the callback handling that already confirms payments. Do not add a second payment integration for bookings, and do not confirm on the browser redirect alone, because a user who closes the tab never returns to it.

  4. 4

    Record the deposit against the booking as a payment with its own state, so the remaining balance, later charges, and refunds all reconcile to one record rather than being recomputed from totals.

  5. 5

    Do not charge the deposit again on a reschedule. Carry the existing payment across to the new time; recharging a customer for moving an appointment reads as a penalty and generates disputes.

Edge cases it handles

8
  • The booking must not be confirmed until the payment settles. Confirming on submit and reconciling later produces confirmed bookings that were never paid for.
  • A failed or abandoned payment must release the held slot after a short window, and the hold must expire on its own rather than depending on the user returning to cancel it.
  • The refund policy is tied to the cancellation window. Cancelling inside the window forfeits the deposit under stated terms; outside it, the refund is issued automatically rather than needing a support request.
  • The deposit and the remaining balance must stay reconciled through partial refunds, price changes, and later top-up payments, so no booking ever shows a balance that disagrees with the payments recorded against it.
  • A reschedule carries the existing deposit to the new booking without a second charge and without a refund-and-recharge cycle that leaves the customer out of pocket in between.
  • A duplicate webhook or a retried callback must not record the deposit twice. Key payment handling on the provider's identifier so replays are ignored.
  • If the app has Failed Payment Recovery, route a failed deposit into that flow instead of dropping the booking attempt silently.
  • Currency, tax, and the amount displayed must match what the provider actually charges, including in the confirmation email.

Definition of done

9
  • The deposit, remaining balance, and refund terms appear before payment is taken.
  • A booking is confirmed only after the payment settles, verified server-side rather than on redirect.
  • An abandoned or failed payment releases the held slot automatically.
  • Cancellations apply the stated refund policy according to the cancellation window.
  • Deposit, balance, and refunds reconcile to the booking record at all times.
  • A reschedule preserves the deposit with no second charge.
  • Repeated payment callbacks do not create duplicate charges or bookings.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.