Plans and credits

A Plan is the bundle a client buys — a 10-class pass, a monthly membership, a package of six massages. A credit is what the client gets from it: a prepaid token that a later booking spends. The client pays once, credits land in their wallet, and each visit takes one back out. Plans live in Offerings → Plans. Everything on this page assumes you already have at least one Service to spend credits on — see Offerings.

​

Two things to know before you sell a pass

Both of these surprise people, and both are how the product genuinely behaves today. Neither is a setting you can change. Price your passes with that in mind.

​

What a credit is

A credit is a whole number held against a Contact. Not money, not a discount, not a booking. Just a count of prepaid visits. Behind that number is a ledger — one row per movement, each recording the change and the balance that resulted. The ledger is only ever added to. Nothing edits or deletes a past row, so the history of a client’s pass is permanent and auditable, and the balance is always the sum of what happened. Two consequences worth knowing:

• A balance can never go negative. An attempt to spend more than a client has is rejected outright, not allowed to overdraw.
• Credits are per contact, not per plan. Sell the same client two passes and they get one bigger balance, not two separate passes you can tell apart at redemption time.

​

Worked example: a 10-class pass

You run a studio. You want to sell a pass of 10 classes, and you want each class booking to take one class off the pass. That is two pieces of setup: the plan that gives out the 10, and the service that takes one back. From then on, each time that client books the class, DMLY takes one credit off their balance and writes a ledger row. At 10 bookings the pass is spent.

​

Issuing credits

There are three ways credits get into a wallet. By hand, from the client profile. The client profile has an Add credits button. It takes an Amount, an optional Expiry date (optional) (which nothing enforces, as above) and Notes, and puts the credits straight into the wallet. This is the most direct route, and the one to reach for when you are correcting a balance. From a plan, via a subscription. Creating a subscription from a plan in Finance snapshots the plan’s items, grants the credits, and converts the contact to a client. Creating the subscription never charges anything — see One-time or recurring? for how the money and the next cycle’s credits are connected. From an automation. A flow can issue credits to the contact it is running for. That is the route to use when credits should follow something that happened in a conversation rather than a purchase you keyed in. A flow’s Create Subscription node creates a subscription from a plan, and so grants that plan’s credits too.

​

Spending credits

On booking. When a client books a service with a Credit cost above 0, DMLY takes that many credits — once per booking. It takes the credit only when the client has the balance for it. This is safe against double-spending. A double-clicked booking button or a retried background job cannot take the credit twice; the booking itself records which ledger row paid for it, and a second attempt finds it already paid. From an automation. A flow can deduct credits directly. If the balance is too low, the flow does not fail — it takes a separate path you can wire up for exactly that case, or carries on down its normal path if you have not wired one. Use that branch to send a WhatsApp message offering a top-up.

​

The low-credit warning

DMLY can start a flow when a client is running out of credits — the natural moment to send a WhatsApp message offering the next pass. It is narrower than it sounds, so read the rule before you build the flow. The threshold is 3, and you cannot change it. Not per workspace, not per plan, not per service. Three. It fires on the way down, once. The warning fires when a deduction takes a balance from above 3 to 3 or below. 4 → 3 fires. 5 → 1 fires. It fires once on that crossing, and then not again as the client keeps spending — 3 → 2 and 2 → 1 are silent, because the balance was already at or below 3 when they started. Only spending triggers it. Issuing credits never fires the warning, whatever the balance lands on. A client granted 2 credits sits at 2 in silence. So the practical shape of it: each pass gets you exactly one low-credit warning, at the moment the client drops to 3 or fewer remaining. Build the flow to make that one message count. Two other credit moments can start a flow: credits being issued, and credits being used. All three are also webhook topics — Credits issued, Credits used and Credits low — if you want them in another system. A failed trigger never damages the ledger. If the automation errors, the credit movement still stands — the balance is correct even when the message never goes out.

​

Seeing a client’s credits

A client’s credit history is on their client profile, showing the latest 50 movements. That is the record to check when someone disputes how many classes they have left: each row shows what changed and the balance that resulted, and no row was ever edited after the fact.

​

One-time or recurring?

​

Recurring credits only top up if auto-charge is on

A recurring subscription re-grants its credits when a renewal is actually charged, and that only happens when the client has a saved card. Creating a subscription charges nothing: you send the client a card-capture link with Set up auto-charge, and once they complete it the daily sweep charges that card each period and grants the period’s credits. The subscriptions table on the client profile has an Auto-charge column so you can see which are set up. If a charge fails, DMLY retries — three attempts, two days apart — and pauses the subscription if all three fail. Without auto-charge, the daily sweep rolls the subscription’s period forward and grants nothing. A “4 classes a month” membership sold that way gives the client 4 credits at purchase and never tops up again, however many months they pay for. Nothing warns you about it. So if you are collecting the money yourself through Invoices or a payment link, each cycle’s credits are yours to issue too, with Add credits.

​

What else a plan can bundle

Credits are one kind of plan item. A plan item can also be:

• Service — a service included in the bundle.
• Product — a physical item bundled in, with a Quantity. See Products.
• Credit — the wallet grant covered above.

Group your plans with categories once you have more than a handful.

Why can't I stop a massage pass being spent on haircuts?

Because the wallet has no service dimension. The balance is a single number per contact, and a booking that costs credits takes from that number without asking where the credits came from. The plan item’s service field records your intent, but nothing enforces it at redemption.If separation matters commercially, the practical workaround is to set Credit cost only on the services you are genuinely happy for any credit to buy, and to handle the rest as ordinary paid bookings — see Appointment payments.

A client's pass is wrong — can I just edit the balance?

There is no editing of the ledger. Rows are never changed or removed; the balance is what the rows add up to. A correction is a new movement in the other direction, which is why the history stays trustworthy.If the client is short of credits, Add credits on their profile issues the difference. Describe it in Notes, so the next person reading the profile can see what you did and why.If the client has too many credits, there is no button for it. Nothing in the interface takes credits off a balance — the only way to do it is to build a flow with a Deduct Credits node and run the contact through it.One thing to steer clear of on the way: the Edit credits action on a subscription in Finance describes itself as Adjust the credit balance available on this subscription, but it does not touch the client’s wallet or the ledger. All it changes is how many credits future renewals of that subscription grant.