Skip to content

26 September 2026 · 4 min read

Pet service packages with an explainable session balance

Track prepaid entitlements through bookings, attendance, cancellations and corrections without treating one editable balance as the entire record.

Author
Sawhorse Engineering
Published
26 September 2026

A customer believes there are two visits left in a prepaid package. The desk screen says one. Staff can edit the number, but nobody can explain whether a cancelled booking used a session or whether a previous correction was applied twice. The balance is visible while the history that would justify it is missing.

Package software needs an entitlement record that can be traced through the work. Payment, eligibility, reservation and consumption are related but different events. Keeping them separate makes it possible to answer a customer question without guessing or changing a number simply to end the conversation.

Define what the package grants

Record the approved package terms: eligible services, quantity or allowance, permitted pets or household, any validity rule and how cancellations are treated. The business must supply and review those terms. The application should not invent expiry, forfeiture or refund rules because they are convenient to implement.

Version the terms accepted for each purchase. A later change to the current package offering should not silently rewrite an existing customer's entitlement. Staff need to see which rules apply to the package they are actually using.

Keep monetary amounts in the payment system's appropriate model and session quantities in the entitlement model. A package can grant a service allowance without making one session interchangeable with every other service or a cash balance.

Payment acceptance and entitlement activation differ

Use the processor's authoritative payment result to activate a paid package according to the approved workflow. A customer returning to a success URL does not by itself prove that payment completed. Preserve the processor operation reference and the package purchase reference.

If a verified payment event is delivered twice, it must not grant the package twice. Record the granting operation idempotently at the shared data boundary. If payment is pending or needs customer action, show that state without creating usable entitlements prematurely.

Handle later payment changes explicitly. A refund or dispute may require review of unused entitlements under the business's terms. Do not automatically remove already delivered service history or assume a payment event determines every operational consequence on its own.

Use movements rather than an editable total

Record each grant, reservation, use, release and adjustment with a stable reference and reason. The displayed balance is derived from those accepted movements. Staff should be able to open the balance and see how it was calculated.

Corrections should add an authorised adjustment or reverse an incorrect movement, preserving the original context. Replacing the total without history prevents later reconciliation and can conceal a duplicate use that will recur.

Scope permissions carefully. Front desk staff may need to view the history and request a correction, while a different role approves adjustments. Make the routine correction path usable so staff are not forced to borrow broad administrator access.

Reserve a session while the booking is pending

If a customer books several future visits, decide whether those bookings reserve entitlements. Without a reservation rule, several bookings can each see the same remaining session as available. With an overly broad reservation rule, an abandoned booking can block the customer's package indefinitely.

Represent held and consumed quantities separately. A temporary booking hold can release its reserved entitlement when it expires. A confirmed booking can retain it until the approved attendance or cancellation event determines the final treatment.

Apply concurrent changes transactionally. Two booking requests for the last available session must not both receive an entitlement that cannot cover them. Return a clear result and preserve the customer's other entered details when availability changes.

Consumption needs an operational trigger

Choose the event that uses a session under the approved policy. It might be a reviewed attendance outcome rather than the mere start time of the appointment. A scheduled job that deducts every calendar entry can consume sessions for cancelled or incorrectly entered visits.

Link the use to the specific visit and pet where applicable. A household package covering several pets needs an explanation of which service consumed each unit. Do not hide that detail behind one household total.

Late corrections to attendance should flow through a reviewed entitlement adjustment. If a visit was marked completed by mistake, the correction must address both the operational record and the related package movement without deleting either history.

Show customers the same accepted facts

The portal should distinguish available, reserved and used sessions. Explain a pending correction as pending rather than quietly showing a provisional number as final. Use readable visit references so the customer can identify the entry they want to ask about.

Restrict visibility to the appropriate household permissions. Someone authorised to collect a pet may not be authorised to view purchases or change package arrangements. The customer account model should express that difference.

For expired or closed packages, preserve the history and show the applicable term. Avoid misleading labels that suggest a technical error when the actual issue is a business rule requiring staff review.

Reconcile the lifecycle, not only the number

Compare paid purchases with entitlement grants, confirmed bookings with reservations and approved service outcomes with consumption records. Equal totals can still hide a grant attached to the wrong household or a use attached to the wrong visit.

Test a duplicate payment event, two bookings for the last session, a cancelled appointment and an approved correction after a package closes. Ask staff to explain the resulting balance from the visible history alone.

An explainable package system makes a disagreement investigable. It does not promise that every commercial rule is simple. It preserves the evidence and applies the approved rule consistently enough that staff and customers can understand what remains available and why.

Let’s talk about the system you need.

Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.

  • A mutual NDA is signed before project details are shared.
  • Scope is fixed in writing before any build starts.
  • You own the source code, the IP and the documentation at delivery.
  • Support plans are available and tailored on a discovery or technical call.