Concept

Deposit rules and refund eligibility

How deposits work on InkMap — how they're set, how you pay them, and what happens to your money if a booking is cancelled.

Applies toEveryone

Some practitioners require a deposit to lock in your booking; others don't. When a deposit is involved, every booking has to answer two questions: how do you actually pay it, and what happens to that money if the booking is cancelled. The exact rules vary from one practitioner to the next — but the system underneath them is the same on every booking, and that's what this page covers.

The short version: the practitioner's policy at the moment you submit your booking is captured on your booking and frozen, the eligibility math is a single rule, and the refund path you go down depends on whether the deposit was paid through Stripe or by hand.

  • How deposits are set up

    Deposits aren't a platform setting — each practitioner decides whether to require one, and how much, in their own pricing setup. The shape of that setup depends on the booking model (see Time-based vs project-based bookings explained).

    • Time-based practitioners (piercer, permanent makeup, laser) set deposits per service, as a flat amount in their currency (e.g. €30 for a nostril piercing). Different services on the same practitioner can have different deposit amounts, or no deposit at all.
    • Project-based practitioners (tattoo artist, body modification) set the deposit per session, in the currency they work in. They can publish a default percentage on their profile as a hint for what to expect, but the actual deposit on each session of your booking is a number they pick on that specific session — not a formula automatically applied to the session's price. Different sessions inside the same booking can have different deposit amounts.

    If a practitioner hasn't enabled deposits at all, the booking simply has no deposit step — confirmation goes through immediately on the practitioner's side without any money changing hands until the day of the appointment.

  • How you pay your deposit

    There are two ways to pay a deposit on InkMap: Stripe and manual. Which ones you can choose from depends on what the practitioner has set up.

    • Stripe deposit — only available if the practitioner has connected their Stripe account and turned Stripe deposits on. You enter your card, the deposit is charged immediately, and the system confirms receipt automatically — there's nothing for the practitioner to do. The Stripe processing fee is either added to your charge or absorbed by the practitioner, depending on which option they picked; either way, you'll see the breakdown before you confirm.
    • Manual deposit — the practitioner picks which off-platform methods they accept (cash, bank transfer, card in person, Revolut, PayPal, other), and for the structured ones (bank transfer, Revolut, PayPal) they can publish the per-method details too — IBAN + BIC, Revolut @username, PayPal email. On the deposit screen of your booking you'll see a Payment info button next to the methods chip; tapping it opens a modal listing every method the practitioner accepts with the per-method details ready to copy. Full breakdown in the next section. Once you've paid them outside the app, you tap "I've paid outside the app" on the booking. The practitioner then confirms receipt in their own view. The booking can't move forward until that confirmation happens — for time-based bookings, this is the step that flips the booking from Pending to Confirmed.

    The "manual confirmation" step matters more than it sounds. It's the only signal the platform has that the money actually changed hands, and most of the refund logic later on hinges on whether the deposit was just sent or actually received.

  • Where do I find the practitioner's payment info?

    When a practitioner accepts manual deposits, the deposit screen shows a small Payment info button next to the methods chip. Tapping it opens a modal listing every method the practitioner accepts, with the per-method details ready to copy:

    • Bank Transfer — IBAN (formatted in groups of 4 for readability) and the optional BIC underneath. The copy button always copies the canonical no-spaces form, which is what banking apps accept.
    • Revolut — the practitioner's @username with a copy button.
    • PayPal — the practitioner's email with a copy button.
    • Cash / Card in person / Other — these have no structured field by design; the modal just lists the method name. Settle the details directly with the practitioner.

    If the practitioner accepts a method but hasn't filled in the per-method field yet, the modal shows the method with a small "Ask the practitioner for details" line — so you know the option is on the table even if you have to message them for the specifics.

    Below the method list, a "Note from the practitioner" block (when the practitioner left one) shows any free-form context — preferences like "cash preferred on the day", "I'll send a payment link after we confirm", etc.

    The button is hidden on Stripe-only deposits — Stripe handles payment in-app, so there's no off-platform info to surface.

  • How to set up your payment details (practitioner side)

    Practitioners set per-method payment info in Settings → Receive Payments → Manual deposit methods. The flow:

    1. Tick the manual methods you accept (Cash, Bank Transfer, Revolut, PayPal, Card in person, Other). 2. For each ticked method that has a structured shape, fill in the per-method field that appears below — IBAN (required when Bank Transfer is accepted), optional BIC, Revolut @username, PayPal email. 3. Use the "Anything else you want the client to know" general note for free-form preferences or context that the structured fields don't cover ("I prefer cash on the day", "Bank transfer fine for the deposit", etc.). Soft-capped at 500 characters, optional.

    The IBAN is validated as you type — if it's malformed, you'll see a red "Invalid IBAN" hint and the field won't auto-save until it parses. The stored value is normalised (no spaces) so it's clean for clients to copy. Spaces, hyphens, and human-readable formatting are all fine on input — they get stripped automatically.

    Clients see the modal exactly as you fill it in. Methods you tick but leave with empty per-method fields will show with a small "Ask the practitioner for details" line on the client side, so the option is still visible — but filled-in details mean fewer DM round-trips before payment.

  • The cancellation policy snapshot

    Every practitioner sets their own cancellation rules in their Policies & Legal info card. The three rules that matter for your deposit are:

    • Refund notice period — how many days before the appointment you have to cancel to be eligible for a refund (e.g. "7 days").
    • Deposits never refundable — a flag the practitioner can turn on to mean "no refunds, full stop, regardless of notice".
    • Practitioner cancels = full refund — a stated commitment that if they cancel on you, you get the full deposit back.

    When you submit your booking, those three settings are copied onto your booking and frozen — what the docs call the policies snapshot. This matters: if the practitioner edits their policies the day after you book, your booking still uses the policy that was active when you submitted. You're never penalised by a mid-flight rule change, and you don't get unexpectedly upgraded by one either.

  • Eligibility math: are you getting your deposit back?

    When you cancel a booking with a deposit, the platform runs one calculation to decide whether you're eligible for a refund. It uses your booking's policy snapshot and the appointment date.

    • If the snapshot says deposits never refundable, you're not eligible. End of calculation.
    • Otherwise, the platform measures how many days of notice you're giving (today vs the appointment date), and compares it to the snapshot's required notice period. If your notice is greater than or equal to the required days, you're refund eligible; if it's less, the deposit is forfeited.

    Two safety nets bend that math in your favour:

    • Practitioner moved your appointment — if the practitioner proposed a new date for a session and you cancel before responding, the eligibility calculation uses the last confirmed date, not the new pending one. You don't lose your refund window because the practitioner asked to reschedule.
    • Practitioner never confirmed your deposit in time — if you sent your deposit and the appointment date arrived without the practitioner confirming receipt (so the session got auto-rejected), you're treated as eligible regardless of the notice math. It's the practitioner's negligence, not your cancellation, that ended the booking.

    The eligibility decision and its reason ("Policy requires 7 days notice. You're cancelling with 3 days notice.") are stored on the booking the moment you cancel and don't change after that.

  • The refund flow, step by step

    Once you've cancelled and eligibility has been decided, the booking enters one of three paths.

    • Stripe deposit, eligible — the platform fires a Stripe refund automatically. Your booking shows Stripe refund processing, and the money returns to your card on Stripe's normal timeline (usually 5–10 business days). Nothing for you or the practitioner to do.
    • Manual deposit, eligible — the practitioner is notified that they owe you a refund. They pay you back outside the platform, mark the refund as sent, and you confirm you received it. Once you confirm, the booking moves to Review > Dropped and the loop closes. If the practitioner had never confirmed your deposit yet, that step happens first — the booking sits in awaiting deposit confirmation until the practitioner says yes (deposit confirmed, refund flow continues) or no (see Disputes in the FAQ below).
    • Not eligible — if the practitioner already confirmed receipt, the booking drops immediately and the deposit is kept. If the deposit was only marked as sent (not yet confirmed), the booking still parks in awaiting deposit confirmation so the practitioner can mark it received for their accounting before everything finalises — but no refund is due either way.

    If you tap "I didn't receive the refund" instead of confirming, the practitioner is notified to send it again. After a few back-and-forths the case escalates (see FAQ).

  • What happens when the practitioner is the one who cancels

    Practitioner-initiated cancellations don't go through the eligibility calculation — if a deposit was exchanged, a refund is always required, no notice-period math involved. The flow itself is identical to the eligible client-cancellation path: Stripe deposits auto-refund, manual deposits go through the same send → confirm loop.

    The "Practitioner cancels = full refund" line you may see in the practitioner's policies at booking time is a stated commitment — the practitioner is telling you "if I cancel, I'll refund you fully". The platform doesn't enforce this independently; it surfaces it so you can make an informed decision before booking, and it's the practitioner's reputation on the line if they don't follow through. If a refund flow stalls, the same reminder and escalation timers apply (see FAQ).

Frequently asked questions

My practitioner is taking ages to send my refund — what happens?

Once the appointment cancellation is in, timers run automatically from the day you cancelled. At day 7, the practitioner gets a reminder push that a refund is still owed; at day 14, they get a firmer reminder warning that a public InkMap Warning will land in 7 days if they don't act. At day 21, if the refund is still unpaid, InkMap auto-issues a public "InkMap Warning" on the practitioner's profile tied to the unpaid refund. The warning is locked — only an admin can remove it — and surfaces as an orange "N Warnings" pill in the practitioner's Reviews Info Card (Info tab on their profile), right under the rating summary. The booking itself also moves to its final "dropped — pending out-of-band refund" state at the same moment, so it stops sitting indefinitely in the refund-pending column. The practitioner remains responsible for paying you back outside the platform; you'll get a push the moment the warning lands. You don't have to do anything to start the timer; it begins automatically when you cancel. (More detail in InkMap Warnings, explained.)

I tapped "I've paid outside the app" but the practitioner is taking forever to confirm. What happens?

A symmetric timer kicks in the moment you mark the deposit as sent, mirroring the refund-side timer above. At day 7, the practitioner gets a reminder push that they still need to confirm receipt; at day 14, they get a firmer reminder warning that a public InkMap Warning will land in 7 days if they stay silent. At day 21, if they still haven't tapped Confirm or rejected the deposit, InkMap auto-rejects the booking and publishes a public "InkMap Warning" on the practitioner's profile — same warning surface as the refund-side day-21. The practitioner remains responsible for returning your deposit out-of-band; you'll get a push the moment the warning lands explaining what to do next. You don't have to do anything to start the timer; it begins automatically when you tap "I've paid outside the app". Stripe deposits skip this whole flow because Stripe confirms receipt automatically the moment the charge clears. (More detail in InkMap Warnings, explained.)

The practitioner says they didn't receive my deposit. What now?

You can re-mark it as sent (because it's the same deposit — you don't pay again). They confirm or reject again. After 3 cycles of "marked sent / marked not received", the booking is automatically flagged as a deposit dispute and a litigation ticket is opened against it. The same 3-cycle limit exists in the other direction for refunds: if the practitioner keeps marking the refund as sent and you keep marking it as not received, that also opens a ticket after 3 cycles. Once a ticket is opened the booking is set aside for admin attention rather than continuing to ping back and forth between you and the practitioner. If InkMap then rules in your favor, a public InkMap Warning is issued on the practitioner's profile; if InkMap rules against you, a small private note (a "past-dispute mark") is left on your account — see InkMap Warnings, explained for both sides of how that works and how to appeal.

What if I cancel one session of a multi-session tattoo booking?

Each session in a project-based booking has its own deposit and its own eligibility calculation, run against its own confirmed date. Cancelling session 3 of a 5-session booking doesn't touch sessions 1, 2, 4, or 5 — they stay on track with their own deposits and dates. Only the cancelled session enters the refund flow described above.

Why is the deposit amount different for each session of my tattoo booking?

Project-based practitioners set the deposit per session rather than as one number that applies across the whole booking. The number you see on each session is what they decided for that specific session. Many of them follow their own published default percentage as a guide, but the platform doesn't automatically compute the deposit from the session price — it's a number they pick. Different sessions inside the same booking can therefore have different deposit amounts.

The studio took my deposit — who refunds me when I cancel?

That depends on how the practitioner decides to handle it. When the studio collected the deposit, the practitioner is asked to pick the refund routing: either defer to the studio (the studio sends you the refund directly), or refund you themselves and settle the difference with the studio later through the studio's accounting. From your side it doesn't matter which they pick — you get the same "refund sent → confirm received" prompt either way, and the money lands the same way it would have on a non-studio booking.

See this in action

Was this helpful?

Get InkMap on your phone

Available on iOS and Android

© 2026InkMap  ·  All rights reserved