Overview

The Billing page in Customer Care enables the Travel Operator (TO) to manually input payment and refund transactions. These transactions are then incorporated into the payment plan associated with the itinerary's components and services. This functionality allows the TO to efficiently plan and record payments and refunds within Customer Care, ensuring that the booking's outstanding balance or refundable amount remains accurate.

The payment and refund amounts for each itinerary can be accessed through the Booking API.

It's important to note that although there is no integration with a payment provider, all payment and refund operations are logged within TripBuilder and are executed externally by the TO for all financial transactions.

 

Payment and refund flow example

Consider an itinerary with a sales price of 1000€ with a 30% advance payment:

• Payment Status = Partially paid
• Total Sales price = 1000€
• Total Payments = 300€
• Total Refunds = 0€

In this case, there is an uncovered value of +700€

Sixty days before the itinerary start date, the traveller goes to the travel agency and pays the uncovered value of 700€ with a credit card:

• Payment Status = Paid
• Total Sales price = 1000€
• Total Payments = 1000€ (300€ + 700€)
• Total Refunds = 0€

There is no uncovered value.

Forty days before the itinerary start date, the traveller decides to cancel an activity that was programmed and booked in the itinerary. The activity is fully refundable at this time and has a cost of 200€:

• Payment Status = Paid
• Total Sales price = 800€
• Total Payments = 1000€ (300€ + 700€)
• Total Refunds = 0€

In this case, there is an uncovered value of -200€. As the uncovered amount is negative (sales price lower than payments received), a manual/offline refund payment is required.

Thirty days before the itinerary start date, the Travel agency refunds 200€ to the traveller according to the payment method previously used (i.e. credit card):

• Payment Status = Paid
• Total Sales price = 800€
• Total Payments = 1000€ (300€ + 700€)
• Total Refunds = 200€

Billing page

When this feature is active, two additional rows - “Total refund” and “Total payments” are available under the “Base Information” section on the “Billing” page:

• Total refund: includes only offline refund payments (their total sum)
• Total payments: includes all online and offline payments

Further, if there isn’t an exact cover of the total sales price (either payment or refund is required), then a Warning message is displayed with an indication of the value required to settle:

• A positive value indicates that a payment is required
• A negative value indicates that a refund is required

A payment or refund action is triggered via the “+ PAYMENT” button.

 

In the example, we have a total amount to be paid of USD 6,516 (resulting from the difference between the Total sales price and the Non-payable amount fields). From this, an initial payment of USD 2516 was already received. The warning message under the Payments section indicates the remaining payment amount to settle.

 

Creating a payment

Clicking on the “+ PAYMENT” button will present a modal window for the user to define the type of operation to execute: either a “Payment” or a “Payment Refund”. When selected, click the “ADD” button to proceed with the payment definition.

 

The modal is then expanded with a new “Payment Management” section and additional fields:

• Method*: Credit Card or Bank Transfer (at least one need to be selected)
• Type*: Total or Partial, related to the amount to pay
• Payment Amount*: a numeric value that:
  • in the case of a “Total” payment, has the default value of the remaining amount required to cover the difference.
  • in the case of a “Partial” payment, is a positive amount inferior to the remaining amount required to cover the difference
•  Payment Due Date*: An indicative date for the payment operation. Only dates in the present and future are allowed for selection (i.e. dates in the past are not allowed)
• Comment: A descriptive field for the operation, internal for itinerary management and not shared outside TripBuilder

(* mandatory fields)

 

In the use case of a “Partial” payment, the user will get an error message with that indication if the Payment Amount is more than required to settle the difference.

Let us consider we create:

• A payment
• With a credit card
• That is partial
• With an amount of USD 2,500
• For a future date
• With a “Second payment” payment

 

Clicking on the “Add” button:

• The updated warning message indicates that USD 1,500 are still required to settle the difference
• The new payment is added as a row in the “Payments” section with the status “Open”

 

Payments and refunds in status “Open” have two action icons at the end of the row that represent them in the Payments table:

• Trash bin for deleting the payment/refund entry. If triggered, a confirmation modal is presented to the user

 

• Checkmark to commit the transaction to the actual itinerary billing

Please note: Since transactions are only committed to the itinerary billing by user action, planning all expected payments (and their respective due dates) is possible. When executing, the user only needs to commit them as they go until they reach the total payment value.

 

By adding a new payment of USD 1,500 with the same process as previously described, the warning message is removed, even if not having still committed the payment reception. If the payment is below USD 1,500, the warning message will still indicate the difference required to pay.

 

Committing a payment

A confirmation popup is presented when the user commits to a payment (clicking the checkmark icon for the respective payment row).

 

Clicking on the “Yes, Payment has been received” button:

1. An email is sent to the customer (if the option “Send payment confirmation to customer” was kept selected in the modal)

 

2. The modal is closed

3. On the Billing page:

• The payment entry:
  • had a status change from “Open” to “Closed”
  • the buttons to remove and commit the payment are removed
  • an email icon is added that can be used to send an email to the customer (particularly relevant if that was not performed previously when committing to a payment)

 

• The “Total payments” field is updated. For example, by committing all payments, the “Total payments” field will correspond to the “Total amount to be paid” in the “Base Information” section

 

Creating a refund

Doing a refund follows a similar process to create a payment.

A need for a refund to a customer is also detected by a warning message where the overall total of payments is superior to the total sales price. A negative value is presented in the warning message.

 

A refund action is also triggered by clicking the “+ PAYMENT” button.

In the “Add Payment” modal, select “Payment refund, “ where the same fields are present as in the case of the offline payment.

 

Clicking the “Add” button, a new entry appears in the “Payments” section with a negative value under the “amount” column and with a “type” refund.

 

The same buttons for deleting or committing a refund are present as in the case of a payment with equivalent behaviour and functionality.

 

Committing a refund

A confirmation popup is presented when the user commits to a refund (clicking the checkmark icon for the respective refund row).

 

Clicking on the “Yes, Refund has been received” button:

1. An email is sent to the customer (if the option “Send refund confirmation to customer” was kept selected in the modal).

 

2. The modal is closed

3. On the Billing page:

• The payment entry:
  • had a status change from “Open” to “Closed”
  • the buttons to remove and commit the refund are removed
  • an email icon is added that can be used to send an email to the Tour Operator (particularly relevant if that was not performed previously when committing to a refund)

 

• • In the “Base Information” section, the “Total refund” field is then updated by subtracting the newly refunded value from the previous one (if any), thus resulting in a negative value (which becomes even more negative if multiple refunds are applied).

 

Adjusting Payments and Refunds on a Booking Change

TripBuilder supports different payment alternatives, such as invoicing or online payments, for settling the cost of an itinerary during checkout.

 

Know more: More details about the payment methods, including payment via an invoice, can be found in the Payment Configuration article.

 

At the point of booking the itinerary, if a down payment has been configured, two payments are generated:

• A down-payment due on the booking date, where the amount results from the down-payment percentage of the total itinerary cost.
• The remaining payment, due X days before the start of the trip, equals the outstanding balance of the itinerary (total cost minus the down payment).

Please refer to the example below, which illustrates a 30% down payment, with the leftover balance due 30 days before the trip's commencement.

 

It's important to acknowledge that post-booking changes may affect the overall price of the itinerary. This could result in additional payments or refunds. If so, TripBuilder will automatically generate new transaction entries, following specific guidelines:

• The due date for post-booking transactions will be calculated the same way as the initial booking transaction, depending on the set period determining how many days before the trip the balance is due.
• If a post-booking transaction is added resulting in an overdue payment, the due date will be readjusted to the day after the booking change.
• If the travel start date is changed as a result of a booking modification, the due dates for any outstanding future payments will be adjusted accordingly. No changes will be made to payments that have already been settled.

 

The example below shows the addition of a 100 EUR fee. This automatically resulted from a booking change and is due 30 days before the start of the trip).

Please note: After executing a post-booking change that will result in the automatic creation of new payment/refund transactions, if these are not immediately visible in the "Billing" page, please manually refresh your browser window.