By default, ecommerce platform sites are set up to take full payment at the point of placing the order. However, Journey's ecommerce platform can take a deposit or defer the payment for a room (or spa). Card information is stored securely in Stripe, and payment is taken automatically for the defined amount at a future date.

Customers will receive notification in advance (by email) that their payment is due to be taken. The time for the reminder, the payment date and the deposit amount are all configurable in ecommerce platform.

It is possible to allow the customer the option to pay in full for the whole order if they so wish, or have the choice of paying a deposit/deferring the payment until a later date. If a client doesn’t want to provide the option of paying in full for a room at the point of booking, this option can be changed to ensure that only deferring the payment is available.

You can choose any percentage to be taken at the point of booking from 0 (defer the entire payment to a later date), to a partial payment (e.g. 25%).

The final payment for a room will be taken around midnight on a configurable number of days before arrival. We usually recommend this be set to be inline with the cancellation terms - e.g. 48 hours / 2 days.

Customers will also be sent a reminder email to let them know that their payment is due to be taken, and for how much. This is also configurable, but we recommend that it is set to be sent out 1-2 days in advance of the payment to give time for any conversations that may be required with the hotel (e.g. amendments or cancellations).

When the customer is at the checkout payment step, the options for payment will be presented, depending on the configuration agreed upon.

Customers will be required to provide card details which can be entered manually, or by using a digital wallet (Apple/Google Pay). The payment information is stored securely within Stripe which is PCI compliant, so there are no security risks.

If a deposit or items such as spa, need to be paid for at the point of placing the order, the card details will be processed for that part of the payment, and also stored to process the payment for the final part of the payment in future.

It is not uncommon for a card to fail during the payment process on a future date. This can be because the card issuer’s bank is forcing 3DS verification again, insufficient funds, the card has expired, etc.

In these scenarios, the customer will be sent an email to say that payment has failed and provide a link to return to ecommerce platform and enter different/correct card details to process the remaining payment.

Within ecommerce platform, the orders section shows all of the orders that have been received. Each order had a ‘Payments and Refunds’ tab which displays the details for payment attempts and deferred payments.

The payment history section displays all attempts to take a payment, the status of the attempt and how much it was for.

It is possible to expand the payment history line to show more information about the card used, and if there was a failure, the reason why.

The deferred payments section displays details about the payment that will be taken in future, the date due and the amount.

When deferred/deposit payments have been turned on, orders that have a future payment pending will display in the ‘Payments’ section of ecommerce platform under the ‘Orders’ section.

Orders are listed in order of payment due date and can be filtered to show which payments are

This means that deposit information will not appear in the PMS automatically, and will need to be posted manually. However, we do include details of the payments taken in the notes for a SynXis booking and the ecommerce platform order reference number to be able to easily cross-reference if a manual deposit has been missed.

(Please note: credit card details collected via ecommerce platform will not come across to the PMS via Synxis, therefore the hotel will need to gain credit card details on arrival for extras).

The transaction report is the most useful report to use for this (see below).

There are two reports that are useful for payment checking and reconciliation:

The finance report shows the status quo of an order and is run by the dates that the order was created. This is really handy to see a full breakdown of the order items and value received within a given period.

The data in a finance report may change over time, as payments and refunds are processed, and items or the order may be cancelled.

This report shows all of the interactions with Stripe to take payment and perform refunds.

In contrast to the finance report, the data in the transaction report will not change. Every transaction is a record of the payments or refunds processed.

This report is useful to clients with a SynXis integration where manual deposits are required. Some hotels task the night manager/staff with running this report for the previous day, and ensure they manually post each deposit to the relevant PMS reservation.

The transaction report provides the CRS ID for each room/order so that it can be easily searched and found in the PMS.

From the main site dashboard in ecommerce platform, it is possible to access the ‘Room Statistics’ dashboard to view deeper insights into the order items for rooms in a given period.

All information displayed in this dashboard is based on the date that orders were received rather than stay dates.