Deposit Setup & Refund Policy — When to Charge, How Much, How to Refund

Charging a deposit isn't "the earlier the better" or "across every slot." The wrong setup just scares hesitating customers away and inflates support work. Here are the criteria.

Three questions to decide whether to charge

1. What's your current no-show rate?

• Under 5%: no deposit needed for now. Customer quality is high enough; charging will only hurt conversion.
• 5%–15%: worth enabling for "high-risk slots" (weekend dinner, holidays, large parties).
• Above 15%: enable across all slots. Each no-show costs you far more than the few customers who'll bail rather than pay a deposit.

Don't know your no-show rate? Run Eatsy Tool: No-Show Loss Calculator.

2. How high is your seat opportunity cost?

A weekend dinner slot at a popular restaurant might be worth NT$ 1,500–3,000 per seat. A no-show throws that revenue away. If your ticket size is high and table turnover is already tight, the value of a deposit gets amplified.

3. Will the deposit drive customers away?

Business lunches, family gatherings, last-minute weekday meet-ups — these customers have low tolerance for "book now, pay now" and might just go book elsewhere if you charge. Fine dining, omakase counters, birthday celebrations — these customers expect to pay a deposit; no issue.

Recommended setups (by scenario)

Scenario A: Everyday restaurant with high weekend-dinner no-shows

Reason: concentrate the deposit on slots with the highest opportunity cost + highest no-show risk.

Scenario B: Counter / by-appointment / fine dining

Uniform deposit, NT$ 500–1,000 per person. Treat as "minimum-spend guarantee" — fully credited toward the bill at the meal.

Scenario C: Newly opened restaurants building customer data first

No deposits for the first three months — the goal is collecting more customer data. After three months, review the no-show rate and customer distribution to decide whether to enable.

Three critical settings in your refund policy

1. "Free-cancellation window"

Most common: 24 hours before the meal.

• Cancel earlier than 24h: deposit fully refunded
• Cancel within 24h: deposit forfeited (or half-refunded — depending on your strictness)

Too loose (e.g., 2h) → customers will cancel right at the deadline, you get no real protection.

Too strict (e.g., 7 days) → customers find it unreasonable, online reviews suffer.

2. "Exceptional situations"

Natural disasters, restaurant emergency closures, the booker or party member testing positive — recommend full refunds. Set an internal SOP for the on-duty manager to judge case-by-case; don't hardcode it in system rules.

3. "No-show" handling

Default: no refund. But a humane shop SOP:

• First-time no-show + proactive apology + valid reason → half refund, keep goodwill
• Repeat no-show / no apology → no refund, log to blacklist

Operational flow

The following actions are in the Eatsy back office — for UI specifics, see Getting Started.

Enable deposits

1. Go to "Settings → Booking Rules"
2. Find the "Deposit" toggle, turn it on
3. Pick the scope (all slots / specific slots / parties above a size)
4. Set the amount (per person / per group)
5. Save

Refunds (by payment method)

In the booking card, tap "Cancel Booking," then choose the refund method:

• TapPay credit-card deposit → initiate the refund from the back office directly; 3–10 business days back to the original card
• Bank-transfer deposit → the system won't auto-refund; ask the customer for their refund account (name / bank / account number) and wire it back manually

Either way, the system sends a notification email to the customer with the outcome.

Deposit records & reconciliation: just use internal notes

The back office doesn't have a "month-end reconciliation / deposit ledger" report. For deposit applications, transfers, and partial refunds, you don't need complex offset logic in the system — just note it in the booking's internal note:

• Date change, deposit carried over → in the new booking's internal note: "Deposit NT$XXX received, carried over from previous booking OOO (date)"
• Applied to meal → internal note: "Deposit NT$XXX applied to this meal"
• Partial refund → internal note: "Refunded NT$XXX, remaining NT$XXX counted as revenue, processed OOOO/OO/OO"

Notes are permanently attached to the booking — flip through the records when you reconcile. This is more flexible and less error-prone than building a full reconciliation flow.

Eatsy's service fee (NT$ 5 per booking with deposit) is settled separately at month-end.

FAQ

Can I set my own deposit amount?

Yes. Each slot can have its own amount, no upper or lower limit (though we recommend keeping it under 50% of the typical ticket — beyond that, customers just abandon).

Do I need to contact the customer after they pay the deposit?

No. Eatsy doesn't issue deposit receipts, but the system sends an automatic email that clearly states "Deposit NT$XXX received, booking confirmed" — once the customer gets that email, they know the payment is settled. You don't need to follow up unless they reach out first.

Can deposits be "transferred" to a future booking?

The system doesn't support automatic transfer. In practice: write "Deposit NT$XXX received, carried over from previous booking OOO" in the new booking's internal note, and apply it directly at the meal — no system-level offset required.

What payment methods are supported?

Two methods are currently supported:

• TapPay credit card — customer pays online by credit card; the restaurant can issue refunds from the back office (Apple Pay / Google Pay and other payment methods are not currently supported)
• Bank-transfer deposit — customer transfers per the on-screen bank details, enters the last 5 digits or uploads a screenshot; the restaurant confirms manually after reconciliation; refunds are wired back manually to a customer-supplied account

One last reminder: deposits are a tool, not the goal. Once your no-show is down and revenue is up, consider reviewing the slots again after 6 months and dropping deposits where they're no longer necessary — your booking experience gets smoother.