> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eat-now.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Deposits & Card Holds

> Secure bookings against a customer's card — as a charged deposit, a blocked card hold, or a saved card — to protect against no-shows and late cancellations.

A **deposit** or **card hold** ties a booking to the customer's card, so a no-show or late cancellation costs them — not you. It's one of the most effective tools against empty tables.

<Warning>
  You must connect a **payment provider** (Stripe, Payzone, or CMI) before you can enable deposits. The toggle stays disabled until you do.
</Warning>

<Note>
  Deposits are on the **General** tab. Enable **Card deposit / bank card hold** to reveal the options. A shift can use **either** a deposit **or** [prepayment](/shifts/payments-prepayment), not both.
</Note>

## Choose a transaction mode

The **Transaction mode** decides how the customer's card is handled.

| Mode               | What happens to the money                                                                      | Best for                                   |
| ------------------ | ---------------------------------------------------------------------------------------------- | ------------------------------------------ |
| **Deposit**        | Charged to the card now. Kept on a no-show or late cancellation, **refunded** otherwise.       | Strongest commitment; high-demand seatings |
| **Card hold**      | **Blocked** (pre-authorised) on the card but not charged. The amount is guaranteed, not taken. | Securing a booking without taking money    |
| **Soft card hold** | The card is **saved** for later use; nothing is blocked or charged. *(Stripe only)*            | Lightest touch; charge only if needed      |

<Tip>
  **In practice, the card hold is the best tool**: it's far smoother than a deposit, which is a real charge. The trade-off is a release delay that depends on the customer's bank — always announce it. See [Customer friction in practice](#customer-friction-in-practice) below.
</Tip>

## Set the amount and when it applies

* **Amount per cover** — how much per guest (e.g. €10 per person).
* **Currency** — MAD, EUR, USD, or XOF.
* **Minimum group size** — only apply the deposit to parties of this size or larger (e.g. groups of 6+).

## Refunds & late cancellation

Turn on **Refundable deposit** to let customers cancel and get their money back up to a deadline. Then set the **late cancellation threshold** — the cut-off after which the deposit is kept:

* Enter the number of **hours**, and choose whether it's measured **before the reservation** (e.g. 24 h before the meal) or **after creation** (e.g. within 24 h of booking).

<Accordion title="Deposit expiry — giving customers time to pay">
  When a deposit is requested, the customer has a limited time to pay before the booking is cancelled. You can set different expiry windows for **same-day** reservations (where time is short) and for **future** reservations, in **minutes** (5 minimum) or in **hours**. If the deposit isn't paid in time, the reservation is automatically cancelled.
</Accordion>

<Accordion title="Requesting the deposit later (minimum delay)">
  Use **Minimum delay for deposit request** if you don't want to ask for the deposit immediately — for example, only request it when the reservation is within a certain number of hours of the meal.
</Accordion>

## Customer friction in practice

All three modes protect your service, but they don't cost the same in **friction** — neither for the customer, nor for your team.

|                | Friction for the customer                    | Load on your team                            | The main risk                                                        |
| -------------- | -------------------------------------------- | -------------------------------------------- | -------------------------------------------------------------------- |
| **Card hold**  | Lowest: no money actually leaves the account | None: the release is automatic               | The customer worries about the amount still blocked on their account |
| **Deposit**    | A real charge on their account               | You must remember to deduct it from the bill | The customer pays twice if the deduction is forgotten                |
| **Prepayment** | Low: they pay for what they came to eat      | None: the meal is already paid for           | Almost none — the easiest mode to operate                            |

### The card hold is the best tool — but it depends on banks

It's the smoothest mode: no money truly leaves the customer's account, the amount is only blocked and then released (automatically, the day after the meal, if they showed up). You protect the seating without turning a booking into a purchase.

Its weak point isn't technical on your side — it's banking. How a hold appears, and then disappears, from the customer's statement depends on two things you don't control:

* **your payment acquirer** (Stripe, Payzone, or CMI) and how it passes the pre-authorisation along;
* **the customer's bank**, above all: it decides when the blocked amount stops showing on the account.

<Warning>
  When EatNow releases a hold, the release goes out to the provider **immediately**. The amount can still show on the customer's account for **several days, sometimes more than a week**, depending on their bank. Nothing on your side or ours can speed that up — and it's you the customer will call, not their bank.
</Warning>

The same delay applies to **refunding a deposit** cancelled in time: the refund is sent straight away, but when it lands on the account is up to the bank.

<Note>
  A **soft card hold** (Stripe) removes the problem entirely, since nothing is blocked: the card is only saved. In exchange, the guarantee is weaker — you have no reserved amount, only the ability to charge.
</Note>

### Always warn the customer upfront

This is the most important rule on this page. A customer warned **beforehand** rarely calls; a customer surprised **afterwards** files a complaint. State the delay in three places:

* in the **payment conditions** shown at booking time;
* in the **confirmation email or WhatsApp message**;
* **out loud**, for bookings taken over the phone.

<Tip>
  Suggested wording, ready to reuse:

  > The amount of your card hold is blocked, not charged. It is released automatically after your visit. Depending on your bank, it may still show on your account for a few days after the release — this is a normal banking delay, and no money will be taken from you.
</Tip>

### When a customer complains

"I haven't been refunded", "my card hold is still blocked": in the vast majority of cases this isn't an error, it's a banking delay.

<Steps>
  <Step title="Check the payment status in EatNow">
    Open the reservation: the payment carries its status — **Voided** for a card hold that was released, **Refunded** for a deposit. That's your proof the instruction left your side.
  </Step>

  <Step title="Explain the delay, without playing it down">
    Confirm the date the release or refund was sent, and explain that when it shows on their account is up to their bank — count on up to a week, sometimes more.
  </Step>

  <Step title="Give them the transaction reference">
    Look up the exact date and reference in your provider's dashboard (Stripe, Payzone, or CMI) and pass them on: that's what their bank will ask for if they want to chase it on their side.
  </Step>

  <Step title="Don't refund a second time">
    A second refund "as a gesture" creates a double movement you'll have to claw back later. Wait out the banking delay before taking any further action.
  </Step>
</Steps>

### Deposits: less friction, as long as you deduct them

A deposit causes far less of this, because it's a **real charge** the customer gets back concretely: it's deducted from their bill when they come in. They aren't waiting on their bank — they simply see their meal cost less. In exchange, the mode is heavier to operate.

<Warning>
  Never forget to **deduct the deposit from the customer's bill**. That gesture is what makes a deposit acceptable — forgetting it means charging twice, and it's the hardest complaint to recover from. If you use the NowOS till, the deduction is one tap on the pay sheet: see [Deposits, prepayments and imprints](/nowos/payments).
</Warning>

### Prepayment: the simplest case

Prepaid experiences escape all of this: the menu is paid in full at booking, so there's nothing to release and nothing to deduct from the bill. It's the mode that generates the fewest customer questions — favour it for tasting menus, themed evenings, and events. See [Prepayment](/shifts/payments-prepayment).

## FAQ

**Deposit vs card hold — which should I pick?**

Use a **deposit** when you want guaranteed compensation for no-shows (the money is taken upfront and refunded if all goes well). Use a **card hold** when you only want the *ability* to charge — the funds are blocked but not taken unless they don't show. In day-to-day use the card hold is the smoother of the two; see [Customer friction in practice](#customer-friction-in-practice).

**A customer says they haven't been refunded, or that their card hold is still blocked. What do I do?**

First check on the reservation that the release or refund actually went out. If it did, this is a **banking delay**: the amount can stay visible on the customer's account for several days, sometimes more than a week. Follow the steps in *When a customer complains* above — and do not refund a second time.

**How long does EatNow take to release a card hold?**

The release is sent to the provider automatically **the day after the meal** for customers who showed up — immediately if you trigger it by hand, or as soon as the bill is settled if you use the NowOS till. What the customer sees on their account then depends on their bank.

**Will existing bookings be charged if I turn deposits on?**

No. Deposit rules apply to **new** bookings only.

**Can I use a deposit and sell a set menu?**

Those are separate features. A deposit secures the booking; [prepayment](/shifts/payments-prepayment) sells menu items in advance. A shift uses one or the other.