Beauty, fitness and classes
A deposit reduces no-shows at the busiest hours. A cancellation rule is stated as somebody books, rather than discovered afterwards.
Deposits and payments
The payment link goes out during the conversation, and its real status is tracked to the end — paid, pending, or nothing at all.
7 days, 20 answered calls, no card
The task it takes over
A deposit asked for during the conversation gets paid; one asked for the next day does not. It is that simple, and it separates a confirmed booking from a slot held for nothing.
This add-on creates the payment request at your provider, sends the link to the person, and tracks the real status of that payment rather than the hope it went through. A file changes state once money arrives, not once a link was sent.
It decides nothing on your behalf. Cancellation, refund and exception rules stay yours: the conversation applies them where they are clear, and passes the situation to whoever is responsible where they are not. Refunding is no automatic act.
Step by step
- Request
The provider's link, rather than an improvised amount
The payment request is created at your payment provider, on whichever amount your rules set for that service. The conversation fixes no price absent from a catalogue.
- Send
During the conversation, rather than after
The link goes out on the channel where somebody already is. A deposit sent later is a deposit to chase, which is exactly what this avoids.
- Track
The real status, to the end
Status comes from the provider. While it stays uncertain it is marked uncertain, and a technical retry creates no second payment request.
- Stop
Follow-up ends on receipt
Once payment arrives, follow-up stops and the file moves on. Where it does not arrive, whichever rule you set decides what happens to the booking.
An add-on, with a purchased scope
The add-on covers merchant payments, for files you authorised. It grants the right to create a payment request and reconcile its status, inside that scope.
What it is not: reading a status held by a third party, accepting an estimate, or authorising a repair. A connected store order and a restaurant order already carry their own payment: in those cases this add-on is not bought twice.
What this changes for your business
Restaurants and events
Groups and events confirm with a deposit. A held date stops being a verbal promise, and a room knows what is genuinely booked.
Trades and maintenance
A materials deposit ahead of ordering is common. The amount comes from whatever you defined for that type of work, and the trace stays on the customer file.
Garages and auto services
A specially ordered part gets paid up front in many shops. The payment request is attached to whichever repair order it belongs to.
What it receives
- A payment provider and an authorised account
- Deposit amounts set by your rules
- Files where a request is authorised
- Cancellation, refund and exception rules
What it produces
- A payment request created at your provider
- A link sent on the channel of the conversation
- A status tracked and reconciled, uncertainty included
- A situation passed to a responsible person where a rule falls short
A refund, an exception and an out-of-rule cancellation are your decisions. A payment request does not turn into permission to refund.
What is metered, and what comes from elsewhere
The add-on carries payment requests per month, inside a purchased scope.
- Payment requests per month, reset at each period
- A retry on the same payment does not count a second time
- Messages carrying the link use their channel meter
- Connected store orders count inside their own scope
Payment provider fees are billed by that provider, separately from a subscription, under its own contract and rates.
With your payment provider
A status shown is technical qualification. A merchant account stays yours, and money reaches you.
- Payment providerTo qualifyCreating a request, receiving a status and reconciling a retry are qualified at the provider; a merchant contract and its fees stay between that provider and you.
Questions about this add-on
Does the money pass through Zenvox?
No. The merchant account stays yours and the money reaches you. Payment provider fees are billed by that provider, separately from your subscription, under its own contract and rates.
Does the file move once the link is sent?
No. The file changes state once money arrives. Status comes from the provider and, while it stays uncertain, it is marked uncertain; a technical retry creates no second payment request.
Can it issue a refund?
No. A refund, an exception and an out-of-rule cancellation are your decisions: a payment request does not turn into permission to refund.
I already sell through connected orders. Do I need this as well?
Not for those orders: a connected store order and a restaurant order already carry their own payment, and this add-on is not bought twice in those cases. It stays necessary for any other billing.
Where does the deposit amount come from?
From your rules for that service. The conversation fixes no price absent from your catalogue, and the request is created at your provider on that amount.
Where to next
What comes ahead of payment, or a full store order.
Deposits and payments