Taking a deposit and chasing the balance
Payment schedules and deposits
A deposit is a promise made in March about a cake due in October. The hard part is not asking for it. It is knowing, in October, which of the eleven orders on the board still owe you something.
ibakepro turns your deposit rule into a schedule on every order, keeps the balance current as the order changes and raises the ones past their date.
Set the rule once
Under Settings, orders, turn the payment schedule on. You get two rows to start: a 50% deposit due when the order is placed and the rest due the day before the event. Both are yours to change.
A row has a name, an amount and a timing.
- Amount is a percentage of the order total, a fixed amount or the rest. One row at most can be the rest, and the percentages you enter cannot add up to more than 100.
- Timing is on the order date, a set number of days before the event, on the day itself or a number of days after. On-the-order-date rows take an offset too, so an invoice is not overdue the hour you send it.
Add as many rows as you want a customer to pay in. Three rows is an instalment plan. You can also hang an override on a row: if the order total is over, under or exactly some figure, charge a different amount instead. That is how a flat deposit on small orders becomes a percentage on the big ones without a second rule to maintain.
Due dates are clamped so they cannot land before the order exists. A "seven days before" row on an order taken three days out is due today, not last week.
On the order itself
The order form shows the schedule as it will be saved, priced against that order's total, and you can change the rows for that one order without touching your default. Preview and saved schedule come from the same maths.
A quote with several options is the exception, because there is no single total yet. Its schedule is built when the customer picks an option or when you convert the quote, from that option's own rows if it has them and your default if it does not. See orders and quotes for the rest of that path.
Taking the money
The customer pays from their order portal, choosing between the next instalment and the whole remaining balance. They can pay by card if you have connected Stripe, and by any method you have defined yourself, such as a bank transfer with your account details on screen or cash on collection.
A card payment lands immediately. A payment made by one of your own methods is submitted with an optional proof of payment and waits for you to approve it, because nothing should mark a bank transfer received until you have seen it. You can also record a payment on the order yourself.
The order page shows what has been paid and what is left. Change the order total after a deposit has landed and the unpaid rows resize around the money already collected. Paid rows are untouched, and no row can shrink below what has been paid against it. If the order was fully paid and the total rises, a balance row is added for the difference.
Chasing what is owed
ibakepro raises a payment as due soon when it is within three days of its date, and overdue once the date passes. Overdue payments also surface on your dashboard as a single alert row rather than one per order.
Those are triggers, not emails.
When something is listening, the guards hold. One message per payment per day at most, nothing at all in the first 24 hours after a schedule is created and drafts skipped. Cancelling an order stops its schedule, so a cancelled order never chases anyone.
Design decisions
- Every payment is one the customer chooses to make, or one you record. No card is ever debited without them.
- The triggers fire. A message reaches the customer through an automation you built and enabled.
- Chasing stays in your voice. Due soon and overdue are the two triggers, and the message and the cadence are yours.
- Cancelling stops the schedule. Money moves only when you refund it deliberately.
- Your deposit rule is yours to set. For help deciding it, see taking a deposit on a cake order and pricing a custom cake.