Any business that books something in advance ends up needing this: a deposit at booking, a balance closer to the date, and a cancellation policy that determines what happens in between. It touches more parts of a payment integration than almost anything else.
Hold the resource before taking money
The sequence matters. Take the hold on the slot, the room, the departure place or the appointment first, inside a database transaction, then collect payment.
The reverse order produces the situation where a customer has paid for something that was taken while they were entering their card details, and now you are issuing a refund and apologising.
The hold needs an expiry. If payment does not complete within a defined window, the hold is released automatically and the resource returns to availability. Without expiry, abandoned checkouts silently block your calendar.
Collect a reusable payment method, not just a payment
The deposit is a charge. The balance in six weeks is a charge against a stored payment method, and that method has to be set up correctly at the first interaction.
The card is collected by processor hosted fields or a hosted checkout, exchanged for a token, and the token is stored against the customer. Your systems never hold a card number and the later charge references the token.
Record the customer's agreement to future use and configure the processor's supported setup flow while the customer is present. The agreement must describe the intended later charges. This does not guarantee that a later off session payment will succeed without authentication: the issuer can still require the customer to return. Build that recovery path as well as the initial setup.
Payment schedules as data
A booking should carry its schedule: what is due, when, and against what.
A deposit due immediately. A balance due a defined number of days before the date. Possibly an instalment in between. Each with a state: pending, attempted, paid, failed.
Modelling it as data rather than as a job that runs means you can show the customer what they owe and when, you can change a schedule for a specific booking without changing code, and reporting on outstanding balances is a query.
The balance charge and what happens when it fails
A scheduled job attempts the balance on the due date against the stored method.
It will sometimes fail. The card has expired, the bank declined, the account is closed. Design the sequence before it happens: a notification to the customer with a link to update their payment method, a retry schedule over a few days, and a defined point at which the booking is at risk.
Provider supported network token lifecycle updates can help when underlying card details change, but they do not guarantee a successful balance charge. Keep the failed payment and customer authentication paths even when this feature is enabled.
The sequence should stop the moment payment succeeds, and any retry must be idempotent so a repeated attempt cannot charge twice.
Encode the cancellation policy
A policy written in a paragraph is applied inconsistently. Encode it.
A window relative to the date, a treatment for each window, and a rule for whether it applies per booking or per customer. Cancel more than a stated period ahead and the deposit is refunded. Inside that window it is retained. Inside a shorter window the balance is due regardless.
Have the policy reviewed for the relevant offering and jurisdiction. The system can calculate the proposed outcome and show it before confirmation, with an exception path for situations requiring review. Software should implement the approved policy, not turn an arbitrary cancellation rule into a legal assumption.
Refunds and partial refunds
A deposit refund is a refund against the original charge, which is cleaner than a new payment out.
Where a partial refund applies, refund against the specific charge so the processor and your records agree, and record the reason. When the reconciliation runs, every refund should trace to a booking and a policy outcome.
Changes to the booking
The case that produces the most support work. A customer moves their date, changes the party size, or upgrades.
Decide the rules explicitly. Does moving a date carry the deposit across. Does an increase in value change the balance or generate an additional charge now. Does a decrease refund the difference or credit it.
Writing those down before the build means the system answers them. Leaving them out means a person answers them differently each time.
Reconcile
Every deposit, balance, refund and payout should reconcile against the booking that produced it. A scheduled comparison between the processor and your records catches the balance that was charged but never recorded, and the booking marked paid where no payment arrived.
That report gives the team a way to investigate disagreement before relying on an incorrect balance.
Do not confuse a booking hold with a card authorisation
A booking hold reserves capacity in your application. A card authorisation reserves an amount through the payment system and has its own validity limits. Keeping an appointment for a future date does not extend the life of a card authorisation. Confirm the supported authorisation and capture window with the processor instead of assuming it lasts until the service is delivered.
Handle a late payment result explicitly. The local slot hold may expire while the customer completes authentication. When the successful payment event arrives, attempt to confirm the reservation under the current availability rules. If the capacity has already been assigned, place the case into a defined recovery flow rather than silently double booking or leaving the payment unattached.
The recovery flow should identify the payment, booking attempt and operator action. Depending on the approved policy, it may offer another slot or arrange a refund through the processor. Test this sequence with a delayed webhook, not only a customer who completes checkout quickly.