Deposits, Cancellations and Changes
TablePort supports two different payment protections. Explain the chosen policy
clearly at booking so guests understand what is charged now and what may be
charged later.
Deposit versus cancellation fee
| Policy | When payment happens | What happens later |
|---|
| Deposit | Direct bookings: now. Requests: only when the venue accepts. | Applied as credit to the guest's bill; may be refundable within your window |
| Cancellation fee | Card is verified and kept on file | Charged only for a qualifying late cancellation or no-show |
Card verification may show a temporary authorisation as described by the
supported payment flow. An authorisation is not proof that a deposit or fee was
captured. Check the recorded status; the guest's bank controls when a released
hold disappears, so do not promise a fixed amount or instant bank update.
Deposit settings
Enable deposits and configure:
- minimum party size;
- per-guest amount and/or fixed amount;
- optional maximum charge; and
- refundable window in hours before arrival.
For a direct booking, TablePort collects the calculated amount upfront. For a
booking request, the guest securely saves a card but is not charged while the
request is pending. Accepting the request collects the deposit; if that charge
fails, the request remains pending so staff can ask the guest to update their
card or decline the request. Staff can review payment status and issue an
authorised refund from the booking details.
Cancellation-fee settings
Enable cancellation fees and configure:
- minimum party size;
- per-guest amount and/or fixed amount;
- optional maximum fee;
- how close to arrival the fee applies; and
- whether qualifying fees are charged automatically.
Only late cancellations and no-shows qualify. A card being on file does not mean
it has already been charged. If automatic charging is off, an authorised staff
member reviews and applies the fee.
Shift overrides
A shift can override the normal deposit or cancellation-fee policy. Use this for
clearly defined services such as Friday dinner or a festive menu. Test the shift
boundary and make sure the guest-facing wording matches the amount and cutoff.
Offering overrides
An offering can have its own payment and cancellation terms. This is the clean
way to give Private hire a larger deposit or longer cancellation window than
ordinary dining in the same shift. In the offering editor, open Payment &
cancellation terms, turn on custom terms, then configure the deposit and late
cancellation fee. Offering terms take priority over shift terms, which take
priority over the venue defaults.
Turning on custom terms is an explicit replacement, not a partial merge. Review
both the deposit and late-cancellation sections before saving. Disable one
inside the custom terms when that protection should not apply to the offering.
When a late cancellation has both a charged deposit and a cancellation fee,
TablePort credits the unspent retained deposit toward the fee and charges only
the remaining balance. A manager may waive the additional fee. If the deposit is
already outside its refund window, the cancellation confirmation tells the guest
that it was retained.
Private-hire request lifecycle
For a private-hire booking request, the payment state follows the booking
decision rather than pretending a pending request is confirmed:
| Event | Booking outcome | Deposit outcome | Cancellation-fee outcome |
|---|
| Guest submits request | Pending | Card saved securely; no deposit charged | Card may be saved for the disclosed policy |
| Venue accepts | Confirmed | Deposit charged once | Card remains available for a qualifying later fee |
| Deposit charge fails during acceptance | Remains Pending | No successful charge | Staff can retry after the guest updates the card, waive where authorised, or decline |
| Venue declines | Canceled | No charge; any legacy captured deposit is refunded first | Never charged |
| Guest cancels outside the cutoff | Canceled | Refunded when the configured refund window allows | Not charged |
| Guest cancels late | Canceled after the financial decision succeeds | Any non-refundable deposit is retained | Retained deposit is credited toward the liability; only the balance may be charged |
| Guest is marked no-show | No-Show after the financial decision succeeds | Applied according to the disclosed policy | Only the remaining eligible balance is charged |
A failed financial decision can leave the booking in its earlier status. Read
the displayed failure and current payment state before an authorised retry or
waiver. An uncertain outcome is not a confirmed failure: inspect the existing
transaction first, and do not recreate the booking or use another charge to
force the desired status.
Paid experiences
An offering can require a fixed or per-guest experience payment. TablePort adds
it to any normal deposit in one checkout, while recording whether the experience
is a separate fee or credit toward the final bill. Included menu items and a
linked promotion can move to the POS order when the party is seated. Paid terms
cannot be silently added or changed during a guest modification. Guests are
directed to contact the restaurant, and the existing booking remains unchanged.
See
Special Days & Paid Experiences.
Guest cancellations and changes
Under Modification, choose whether guests may change bookings and set the
cutoff in hours. Under cancellation settings, choose whether guests may cancel,
set the cutoff, and provide a clear message for requests that are too late.
Changes are not accepted merely because a link is visible: the revised time,
party size, offering, space, table inventory, and pacing must all remain valid.
If not, staff can help review alternatives.
From a booking, authorised staff can:
- send a secure card link by text or email, or present a QR code;
- record a card-requirement waiver with a reason;
- review deposit and cancellation-fee status;
- refund an eligible deposit; and
- handle a qualifying cancellation fee.
Accepting a request that will collect a deposit always requires an explicit
confirmation in Console or the App. Late-cancellation and no-show actions show
the configured liability, any retained-deposit credit, and the remaining amount
before staff confirm. A waiver records the operational decision; it does not
rewrite the guest-facing policy.
Declining a pending request never creates a cancellation fee. If a legacy
request already has a charged deposit, TablePort refunds it first. If that
refund fails, the request stays pending rather than recording a decline that has
not returned the guest's money.
Never collect card details in booking notes, email, or chat. Use the secure
payment flow.
Policy checklist
- The public wording states the amount, timing, cutoff, and refund treatment.
- The fee never exceeds the configured maximum.
- A test confirms deposit credit reaches the booking/order correctly.
- Staff know who may waive, refund, or charge.
- A shift override does not unexpectedly cover adjacent services.
- Guest cancellation and modification links behave correctly before and after
the cutoff.
- A request test proves the card is saved on submission, charged once on
acceptance, and not charged on venue decline.
- A late-cancellation test proves a retained deposit offsets the fee rather than
being charged in addition to the full fee.
Holds and uncertain outcomes
Release hold applies to an uncaptured authorised amount. A charged deposit
uses its supported refund action instead. Verify both booking status and the
financial result after acceptance, cancellation, no-show, release, or refund.
Required guest notification is another outcome to inspect, not proof of charge
settlement.
Use an authorised safe test environment for policy-boundary testing. Product
configuration and an acknowledgement do not establish the enforceability of the
restaurant's terms. Preserve existing records and ask the responsible
manager/support to resolve a disputed or unknown result; do not collect card
details in screenshots, notes, email, or chat.