Booking Refund Requests

Review and approve the money that should be returned after a Booking refund request, while keeping the financial result connected to TruPayments.

What this feature is for

Refund Requests separate the customer/booking cancellation decision from the financial approval decision. In the current Booking flow, a cancellation can create a refund request for manual review while the appointment itself is cancelled; approving the request then performs/records the refund through TruPayments.

This separation lets staff free the appointment slot promptly while still giving an authorized person control over whether and how much money is returned.

A practical way to use it

Open the refund request and confirm the related appointment, original paid amount and the policy/reason for the request.
Review the requested refund amount before approval.
Approve only when the amount and gateway/payment context are correct; reject when the request should not be paid.
After approval, open the linked TruPayments Transaction and confirm the refunded amount appears in its history and that the transaction status reflects the result (for example, partially refunded when only part of the original payment was returned).
If a gateway rejects the refund, keep the request/transaction evidence and resolve the gateway error before treating the refund as complete.

How it connects to other features

Booking Settings and service-level refund policies determine the expected refund behavior. The original payment must be represented in TruPayments for an online gateway refund. Gateway rules can impose amount/rounding/currency constraints, so the stored refund is normalized before being sent to the provider.

What to expect after changes

Approving a refund is a financial action, not merely a status change. It can send money through the original gateway and updates transaction history. Restrict refund permissions and do not retry blindly after an ambiguous gateway response—check the transaction/gateway state first to avoid duplicate refunds.

Why Refund Requests are separate from cancellations

Cancelling an appointment and returning money are related but different actions. A booking can be cancelled according to the Booking workflow while the refund remains pending for staff review. This lets an administrator confirm the policy-calculated amount, change it when permitted, and decide whether a manual or gateway refund should be processed.

What controls the amount and processing method

Booking Settings → Refund Policy supplies the module-wide default refund type, percentage, and automatic/manual processing preference.
Individual Services can have more specific cancellation/refund rules that take precedence for that service.
TruPayments owns the payment/refund history and gateway result. Automatic processing requires a gateway that supports electronic refunds.

Reading the Refund Requests list

Column	How it helps you decide what to do
Booking	Identifies the appointment that caused the refund request and links you back to the booking context.
Customer	Shows who the refund belongs to.
Payment Method	Shows how the original payment was made, which helps you understand whether the refund can be returned automatically or may need a manual process.
Paid	The captured amount recorded when the request was created.
Requested / Proposed Refund	The amount currently proposed for this refund.
Status	Shows whether the request is Pending, Approved, Processing, Completed, Declined, or Failed.
Processing	Shows whether the request is configured for Automatic or Manual processing.
Requested At	Helps staff process older requests first and audit when the request was raised.

Booking Refund Requests list with search and status filters

Refund Requests brings booking-related refund approvals and processing status into one operational list.

Reviewing a request

Open View before approving. The detail page separates the original amount paid, the amount calculated by the refund policy, the current refund amount, the amount already refunded, and the remaining refundable balance. It also shows the reason and, when applicable, a decline reason or gateway failure message.

Approving a refund

Confirm the booking, customer, payment method, and reason.
Compare Policy Calculated Refund with Current Refund Amount and Available Refundable Amount.
If your role allows change booking refund amounts, adjust the Admin Refund Amount when the business decision requires it. TruCMS revalidates the amount before approval.
For a manual request, use Approve manual refund. Complete the actual external/manual money return according to your business process.
For an automatic request, use Approve and process refund. TruPayments submits the refund through the payment provider when supported.
Return to the request/transaction and confirm the final refund status and refunded amount.

Failed, retried, and declined requests

A failed automatic refund can show the gateway failure message. When TruPayments marks the request as retryable and the user has permission, Retry Refund starts another processing attempt. Decline Refund closes a request as declined and can record a decline reason for staff context.

Do not treat cancellation as proof that money was returned

Always confirm the Refund Request and TruPayments transaction history. A cancelled booking can still have a Pending, Failed, or Manual refund that requires staff action.

Permissions

Refund access is permission-based. TruCMS distinguishes viewing refund requests, approving them, changing the proposed amount, declining them, and retrying failed automatic refunds. Give amount-changing and approval permissions only to staff who are responsible for financial decisions.

Booking Settings · Services · Appointments · TruPayments Transactions