Booking Deposits and Refunds: Keep Payment Authority Explicit

Prerequisites

Before changing a booking-payment workflow, identify the payment provider and the system that records each booking. Confirm which provider account processes deposits, which staff roles may approve refunds, and who can execute them. The person designing the workflow needs access to the relevant configuration and test environment, but should not assume that a booking record alone proves a payment was captured or that a refund completed.

Gather representative cases: a deposit paid in full, a partial payment, a cancellation with a disputed amount, a payment whose status is unclear, and a refund already initiated by a staff member. Include booking IDs, payment references, amounts, currencies, timestamps, and the source of each value. Use synthetic or appropriately protected test data when validating the process.

Agree on the business rules before automating them. For example, define which cancellation reasons may qualify for a refund, how a refundable amount is calculated, who can approve an exception, and what should happen when the applicable rule is ambiguous. This article covers the boundary between an operational recommendation and authority to move money; it does not prescribe legal or contractual refund terms.

Set up a way to inspect the payment provider’s current status and a place to preserve approval evidence. Decide how operators will pause the automation, locate pending cases, and resume work safely. If these controls do not exist, start with a manual approval queue rather than allowing an automated process to execute refunds.

Warning: Treat a refund as an external financial action, not as a routine edit to a booking. A model, rule engine, or staff member can propose an amount; a clearly authorized actor must approve the exact action before execution.

1. Separate the booking decision from payment authority

A booking system answers questions about the reservation: which service was booked, when it is scheduled, what was paid according to the booking record, and whether the reservation was changed or cancelled. A payment provider answers a different set of questions about the money movement: whether a charge exists, what amount is refundable, and what state a refund has reached. These records may not update at the same moment.

Build the process around that separation. Let the booking workflow assemble facts and calculate a candidate refund under an approved business rule. Then require a separate payment-authority step to approve the proposed amount and authorize the provider operation. Finally, read the resulting provider state and update the operational record with what is actually known.

This boundary avoids a dangerous inference: cancellation does not itself prove that a payment should be refunded. A cancellation may fall outside a refund rule, a deposit may be only partly refundable, or the payment could already have been refunded manually. Nor should a booking system’s displayed payment label be treated as conclusive when the provider record is unavailable or inconsistent.

A sound design has three distinct statements in its audit trail: the workflow recommended a particular amount for a stated reason; an identified approver authorized that exact amount; and the payment operation produced a separately verified status. Keeping those statements distinct helps staff explain what happened without implying that an approval is proof of settlement.

For a vendor-specific workflow, inspect the provider boundary rather than assuming that a booking integration is the authority for all payment operations. Dayrun describes payment-related functionality on its product page, but that description should be translated into original acceptance tests for the particular booking, approval, and provider setup before use (Dayrun payments). The practical question is not whether a product page mentions payments; it is whether the actual system exposes the facts and controls your process requires.

2. Define the inputs and the amount calculation

Create a narrow refund request record instead of passing a loose instruction such as refund the customer. At minimum, capture the booking reference, provider payment reference, currency, original captured amount, prior refund total if known, requested refund amount, reason code, and the source and time of each relevant fact. Add the staff member or rule that initiated the request.

Make the calculation visible. If a policy says that a deposit of $240 is refundable less a $30 cancellation charge, the candidate amount is $210. If a prior refund of $40 is recorded against the same payment, the remaining candidate may be $170, provided the policy and provider record both support that calculation. These figures are illustrative, not a recommended cancellation policy. The workflow should store the inputs and calculation rather than only the final number.

Use the currency and the provider’s supported amount representation consistently. Do not silently convert currencies or round a calculated result to make a request fit. If the payment reference cannot be matched, the currency is missing, the original charge is not confirmed, or the proposed total could exceed the remaining refundable amount, route the case to a person with payment authority.

Distinguish a zero amount from a missing amount. Zero may mean that the policy yields no refund; missing may mean the workflow cannot calculate a safe answer. Those states need different handling. A zero result can be communicated as a policy outcome if the evidence is sufficient. An unknown result should be held for review, not interpreted as zero or filled in by a model.

Record the rule version or policy identifier used to calculate the request. If a business changes its cancellation terms, a later reviewer should be able to tell which rule applied when the recommendation was made. Do not let a new policy silently rewrite the reason for an already-approved request.

3. Bind approval to the exact proposed action

An approval is useful only if it refers to an unambiguous action. Show the approver the booking and payment references, the amount and currency, the reason, the policy basis, any prior refund known to the workflow, and any uncertainty or mismatch. Require an explicit approve or reject outcome. An informal message that says looks fine is not a durable authorization unless the process can establish what exact request the message referred to.

Bind the approval to a stable representation of the proposed payload. That representation should include the target payment reference, amount, currency, and the operation being approved. If the amount, target, or material reason changes after approval, invalidate the approval and ask again. A useful implementation stores a payload fingerprint or immutable request version with the approval record; it must not permit the executor to substitute new values after the approver has acted.

Set an expiration for approval. A request approved while a booking is in one state may no longer be appropriate after a schedule change, a new provider event, or another refund. When approval expires, the workflow should refresh the relevant facts and obtain a new decision rather than treating the old approval as standing authority.

Keep approval and execution roles explicit. An organization may allow the same authorized person to approve and execute a request, or may require separate people for certain amounts or exception types. Either way, the process should identify who made each decision and avoid granting a model or unattended automation implicit authority to approve its own recommendation.

Pro tip: Put the amount, currency, payment reference, and request version in the approval view itself. A reviewer should not have to infer which transaction is being authorized from a customer name or booking description.

4. Implement the workflow as a controlled sequence

Use the following sequence as a starting design. Adapt the state names to your systems, but preserve the boundaries: gather facts, calculate, approve, execute, verify, and reconcile. Do not combine approval and execution into a single step merely because the integration makes that convenient.

1. Receive a refund request. Create a durable case with a unique request ID. Record who or what initiated it, when it arrived, and the booking and payment references supplied. Reject or hold requests that lack the identifiers needed to locate the payment.

2. Refresh booking and payment facts. Retrieve current records from their respective systems. Compare their references, currency, amount, and relevant timestamps. If the booking says paid but the provider state is unavailable, record that limitation; do not promote a booking label into proof of provider payment.

3. Apply the business rule. Calculate the candidate amount and record the rule version, inputs, and reason. If the facts do not support a deterministic result, mark the case for review. Do not ask a model to invent a missing payment amount or choose an exception policy.

4. Present a bound approval request. Display the exact target and amount with the explanation and relevant uncertainty. Save the approver identity, decision time, request version, and approval expiration. A rejection ends the execution path, while a changed request returns to review.

5. Execute only after checking approval. Before calling the payment provider, confirm that approval is still valid and matches the payload about to be sent. Use a stable operation reference for retries where the provider integration supports it, and consult its specific behavior rather than assuming repeated requests are safe.

6. Read back the provider outcome. Store the provider response and then verify the current refund status through an appropriate provider record or event. Do not mark the case complete solely because a request was accepted for processing.

7. Update the booking record and notify the operator. Record the verified status and any remaining uncertainty. If the provider outcome is pending or ambiguous, keep the case in a non-final state and make the next action visible to staff.

flowchart TD
  accDescr: Workflow stages and decisions: Gather booking and payment facts, Calculate candidate refund, Approve exact payload, Hold for review, Execute provider request, Verify provider status. The adjacent text explains the conditions and exceptions.
  accTitle: Booking Deposits and Refunds — Keep Payment Authority Explicit workflow
    A["Gather booking and payment facts"] --> B["Calculate candidate refund"]
    B --> C["Approve exact payload"]
    C -->|"Rejected or expired"| D["Hold for review"]
    C -->|"Valid approval"| E["Execute provider request"]
    E --> F["Verify provider status"]
    F -->|"Unclear or pending"| D

The diagram shows why approval comes before the provider request and why a response does not automatically mean a case is finished. A request with rejected or expired approval stops before execution. A request with an unclear or pending provider state returns to a review queue, where staff can decide whether to wait, investigate, or take a separately authorized action.

For retries and restarts, preserve the request ID and execution state so a restarted worker can determine whether it is resuming a known action or creating a new one. Design the tool boundary to avoid duplicate external effects, but do not promise exactly-once behavior: a network timeout can leave the caller unsure whether a provider processed a request. The relevant implementation background is designing idempotent agent tools, particularly when a process can be retried after a partial failure.

5. Work through a hypothetical booking case

Consider a hypothetical multi-location studio with a $240 deposit on a booking. The customer cancels, and the location’s stated policy would allow a $210 refund after a $30 cancellation charge. A staff member has already issued a $40 refund, but the booking record has not yet been updated. The automation must not assume that the full $210 remains available.

First, the workflow loads the booking and payment references and queries the payment provider. Suppose the provider record confirms a $240 captured payment and a $40 refund, while the booking record still says that no refund has been made. The conflict is important operational evidence. The provider record supports a remaining candidate of $170 under the stated hypothetical rule, while the booking record needs correction; it does not support sending another $210.

The workflow creates a request for $170, labels the calculation as policy-based, includes the existing $40 refund, and flags the stale booking value. An authorized operator sees both records and approves that exact amount and payment reference. If the operator instead changes the amount to $160 because of a case-specific exception, the original approval cannot authorize the revised payload. The changed request needs a new approval record.

After execution, suppose the provider returns a status that indicates the refund request is still being processed. The system stores the response, leaves the case pending, and schedules a status check or operator review according to the provider’s documented behavior. It does not tell the customer that the funds have arrived. Provider refund states and timing vary; Stripe, for example, documents provider-specific refund status and timing, so an implementation should rely on the current provider record rather than promise immediate settlement (Stripe refund documentation).

For this hypothetical case, a measurable acceptance criterion is: the workflow must not execute a request unless a current approval matches the same payment reference, currency, and amount; after execution, it must not mark the refund complete until a provider status is recorded that the business has explicitly defined as complete. This is a testable process condition, not a claim about a particular provider’s timing.

A useful test set varies one condition at a time. Check a valid $170 approval, an approval for $210 against a $170 request, an expired approval, a duplicate request ID, and a provider timeout after submission. The expected result for each should be written before a test is run. The timeout case should enter an investigation or reconciliation state, not trigger a blind second refund.

6. Handle exceptions without converting uncertainty into authority

A missing payment reference is an identity problem. Do not search by customer name alone and select a plausible transaction without confirmation. Put the case in a queue that asks an operator to match the booking to the provider payment using reliable identifiers, then preserve the confirmed match in the case record.

A mismatch in amount or currency is a reconciliation problem. The workflow should show the conflicting values and their sources, with timestamps, and stop the execution path. A person can investigate whether the booking record is stale, a payment was split, or a conversion occurred elsewhere. The automation should not choose whichever value makes the refund calculation work.

A duplicate or repeated request is a coordination problem. Two staff members can submit requests for the same booking, or a client may retry after a timeout. Check for existing requests and refunds against the payment before allowing a new action. If the result of an earlier operation cannot be determined, reconcile that operation first. A fresh request is not evidence that the earlier one failed.

An unusual cancellation reason is a policy problem. If the approved rules do not cover the case, route it to the role authorized to interpret the policy. Avoid presenting a confident generated explanation as if it were a rule. Where a model helps summarize case details, its output should remain a summary for the reviewer; it should not create an approval or change the exact amount that has been authorized.

An approval that arrives after the underlying facts change is a stale-approval problem. Re-fetch the relevant booking and payment state before execution. If a prior refund, payment reversal, booking amendment, or amount change means the payload is no longer valid, cancel the pending execution and request fresh approval. This is safer than allowing an approval to function as broad, reusable permission.

7. Preserve evidence that explains each transition

A useful record lets an operator reconstruct what the system knew at each decision point. Store the request ID, booking reference, provider payment reference, currency, original amount, prior refund amounts considered, proposed amount, rule version, reason code, and source timestamps. Preserve the values used in the calculation rather than only a prose explanation.

For approval, record the approver, decision, time, expiration, and immutable request version or payload fingerprint. For execution, record the actor or service identity, submission time, operation reference, and provider response. For verification, record the status observed, when it was observed, and the source used to establish it. Avoid storing unnecessary sensitive customer information in the approval record; staff generally need enough context to identify and assess the request, not an unbounded copy of the customer profile.

Make state names operationally meaningful. For example, distinguish awaiting facts, awaiting approval, approved, submitted, pending provider status, complete, rejected, and reconciliation required. A single status called processed conceals whether money was merely requested or whether the provider’s record supports completion.

Keep a human-readable reason alongside structured fields. A concise explanation such as prior refund of $40 deducted from the $210 policy calculation is easier to review than a bare amount. The structured values remain essential because prose can be ambiguous and difficult to validate. If the explanation and calculation disagree, stop and investigate rather than choosing one silently.

The evidence should support both customer-service follow-up and operational correction. Staff need to know what to say when a case is pending, what to inspect when records disagree, and whether another action is safe. For the distinct question of maintaining context in subsequent customer messages, see automating customer follow-ups without losing context; keep communication continuity separate from payment authority.

8. Validate the boundary with acceptance tests

Write tests around the authority boundary, not only around whether the integration returns a success response. Test that a missing approval prevents execution, that an approval for a different amount cannot be reused, and that an expired approval is rejected. Also verify that a request changed after approval requires a new decision.

Test the calculation with ordinary and awkward inputs: no prior refunds, one prior partial refund, multiple prior refunds, a zero candidate, missing currency, and a candidate greater than the remaining refundable balance reported by the provider. For every case, define the expected state and whether the result should be automated or reviewed. A correct outcome may be a deliberate hold rather than a refund.

Test failures around the moment of external execution. Simulate a timeout before a response is received, a response that cannot be parsed, and a restart after submission but before the local record is updated. Confirm that the process checks the provider state or escalates for reconciliation before resubmitting. Do not claim a test has passed until it has actually been run in the relevant environment.

Test provider status handling separately from request submission. Establish which returned or subsequently observed states count as submitted, pending, failed, or complete in your implementation. Use the provider’s current documentation and test environment to confirm the mapping. The booking system should not display a stronger claim than the provider evidence supports.

Finally, test human handoffs. A reviewer should be able to see why the case stopped, which facts conflict, what action is currently blocked, and what evidence would resolve the block. A queue that merely says error transfers the technical failure to an operator without making it actionable.

9. Launch in a deliberately narrow scope

Start with a small, clearly bounded set of refund cases where the policy and payment reference are straightforward. Keep exceptions manual while validating whether the records needed for the calculation are consistently available. This is a way to learn whether the process is dependable, not a reason to expand payment authority before the evidence supports it.

During an initial operating period, review a sample of completed and held cases. Compare the booking state, provider state, approval payload, and final case record. Look for mismatched amounts, duplicate requests, stale approvals, and cases labeled complete without a verified provider status. Track counts by outcome so that ambiguous cases are visible rather than hidden inside a general success rate.

Define a pause condition before launch. Examples include an unexplained mismatch between booking and provider totals, repeated duplicate submissions, missing approval records, or an increase in cases with unknown status. When a pause condition occurs, disable automated execution while preserving read-only case collection if appropriate. Resume only after the responsible owner identifies the failure mode and confirms that the corrected process meets the acceptance criteria.

Keep the scope of the automation explicit across locations if policies or roles differ. This article does not set out franchise governance; use HQ rules and local overrides for that separate design question. Likewise, questions about asking operational data through a connector belong to Dayrun’s MCP connector, not to the authority rule for moving funds.

If your team needs help mapping these controls into a broader operations automation design, focus the implementation brief on the case states, provider boundaries, approval binding, reconciliation path, and acceptance tests. Those details are more useful than a generic request to automate refunds.

Printable decision worksheet

Use this worksheet in a design review or operational walkthrough. Complete it for one representative case before enabling automated execution. If a field cannot be answered from a reliable source, mark it unknown and define the review path instead of guessing.

Decision area	Record for this workflow	Stop or escalation condition
Booking identity	Booking reference and source system	Reference missing or ambiguous
Payment identity	Provider and payment reference	No reliable match to the booking
Amount basis	Currency, captured amount, prior refunds, calculation	Missing values or conflicting totals
Business rule	Rule identifier, version, reason code	Case falls outside an approved rule
Proposed action	Exact amount, currency, target, request version	Payload changes after approval
Approval	Approver, decision time, expiration, bound request	Rejected, expired, or mismatched approval
Execution	Submission time and provider operation reference	Timeout or uncertain submission outcome
Verification	Provider status, source, observation time	Pending, unknown, or contradictory status
Case closure	Final operational status and next communication	No evidence for a completion claim

Printable summary

• The booking and provider payment are matched using reliable references.
• The refund calculation records its inputs, rule version, reason, and currency.
• The approval names the exact amount and payment target, is unexpired, and cannot be reused after a material change.
• Execution is blocked until that approval is verified.
• A timeout or ambiguous response leads to reconciliation, not a blind retry.
• The case is marked complete only after the required provider status is observed and recorded.
• Staff can see why a case is held and what evidence is needed to proceed.

Summary: keep the authority chain visible

A dependable booking-refund workflow does not treat a cancellation, a generated recommendation, or a successful-looking response as permission to move money. It gathers booking and provider facts, calculates a candidate under an explicit rule, binds approval to an exact payload, executes only while that approval remains valid, and verifies the provider outcome separately.

The most important design test is simple: can an operator explain who approved which amount for which payment, what was actually submitted, and what evidence supports the current status? If not, keep execution manual while improving the record and exception path. Explicit boundaries make a refund process easier to review, safer to resume after failure, and clearer to customers when a provider outcome is still pending.