Supported with Core

Refund Management

Keep refund requests, approvals, payment records, and customer context connected to the original transaction.

Refund management workflow

Start From the Original Transaction

Keep the refund tied to the payment, invoice, booking, customer, and reason for the adjustment.

Original Payment

Keep the refund connected to the payment it is reversing or adjusting.

Invoice or Booking

Keep the billing and operational context attached to the refund record.

Refund Reason

Use configured reasons or categories to make refund activity easier to review and report.

Customer Context

Keep the refund visible with the customer, guest, member, or account involved.

Use an Approval Workflow When Needed

Not every refund needs the same review. Approval rules can be configured around your operating policy.

Amount Thresholds

Route higher-value refund requests for additional review where required.

Assigned Approvers

Send selected refund requests to the right manager, finance user, or approval group.

Policy Exceptions

Route unusual or policy-exception cases for manual review instead of forcing an automatic decision.

Decision History

Keep approval status and user actions visible on the related Salesforce record where configured.

Apply the Refund Policy Consistently

Use the information already in the booking and billing workflow to support a structured review.

Cancellation Timing

Use booking dates, cancellation timing, and configured policy information during the refund review.

Full or Partial Refund

Support full or partial refund amounts where the payment provider and workflow allow them.

Deposits & Fees

Keep refundable and non-refundable amounts visible according to the configured pricing and policy setup.

Manual Review

Keep staff in control when the request needs judgment or does not fit a standard rule.

Send the Refund Through the Payment Provider

The actual refund execution depends on the configured payment processor and integration.

  • Refund availability depends on the payment provider
  • Refund timing depends on the provider and payment method
  • Provider and transaction fees may still apply
  • Partial refund support depends on the processor and integration
  • Refund status can be kept with the related payment record where supported
  • New payment providers may require a separate integration scope

Keep the Financial Record Aligned

Refunds should remain visible in the same billing and reporting context as the original payment.

Refund Status

Keep requested, approved, processed, failed, or other supported statuses visible.

Invoice Balance

Reflect the refund in the related billing context according to the configured workflow.

Reconciliation

Keep refund activity available when reviewing payment and settlement records.

Reporting

Use refund records in Salesforce reports and dashboards where the implementation supports them.

Works With the Billing & Payment Flow

Refund Management stays close to the original payment, invoice, and reconciliation records.

Payment Processing

Use the configured processor to execute the refund where supported.

View Payment Processing →

Invoice Management

Keep the refund connected to the original invoice and billing history.

View Invoice Management →

Payment Reconciliation

Review refund activity alongside payment and settlement records.

View Payment Reconciliation →

Pricing

Refund Management works with the Core billing workflow and the configured payment processor.

Separate costs

Refund & Provider Scope

Depends on setup

Refund execution, processor rules, transaction costs, custom approval logic, and new integrations depend on the payment provider and implementation.

  • No separate Refund Management subscription
  • Processor and transaction fees remain separate
  • New payment or accounting integrations may require separate scope
  • Implementation is priced separately
Implementation depends on refund rules, approval workflow, payment providers, billing setup, integrations, testing, and rollout. Learn why →

Manual Refund Tracking vs Booking Ninjas

Keep the request, approval, processor action, and billing context connected instead of managing each step separately.

Capability Manual Tracking Booking Ninjas Standalone Refund Tool
Original payment contextManual lookupConnected billing recordDepends on integration
Booking contextSeparate recordsConnected to operationsDepends on integration
Approval workflowEmail / manualConfigurable where neededDepends on product
Refund executionProcessor portalThrough configured processorDepends on connection
Reconciliation contextManual updateConnected payment recordsDepends on integration
Separate BN subscriptionNot applicableNoUsually yes

Frequently Asked Questions

Is Refund Management a separate Booking Ninjas product?

No. Refund Management works with the Core billing and payment workflow. There is no separate Refund Management subscription.

Can refunds require approval?

Yes. Approval logic can be configured when selected refund requests need manager or finance review.

Can Booking Ninjas issue the refund directly?

The refund is executed through the configured payment processor or payment integration. Available refund actions depend on that provider.

Can we process partial refunds?

Partial refunds can be supported when the payment processor, integration, and billing workflow allow them.

Can refunds be reported?

Yes. Refund records can be used in Salesforce reports and dashboards where the relevant fields are captured in the implementation.

How much does Refund Management cost?

There is no separate Refund Management subscription. Core starts at $400/month for 1–50 Active Bookable Units. Implementation, processor fees, and new integration work can be separate.

Keep Refunds Connected to the Original Transaction

Connect refund requests, approvals, processor activity, billing records, and reporting in one workflow.

WhatsApp Us

WhatsApp Us