Payment options are not currently rate-specific, therefore the deposit/deferred payment option which you set up will be applied to all of your rates.

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 (not spa or tables).

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.

Clients wishing to set up their ecommerce platform site with deferred/deposit payments for rooms will need to request to do so with their Onboarding Specialist or Client Success Manager and discuss the options that they wish to set.

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.

A client may 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 in line 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, card expired, incorrect postcode 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.

Additionally, there are options to manage the payment by clicking the ellipsis button at the end of the row.

Change Date

If the client has changed the dates of their room booking, you can amend the dates for the future payment to be in line with the new arrival date.

Mark as ‘Paid’

There may be an occasion where a payment has failed and the remaining payment is not taken via ecommerce platform. This option allows you to ensure that ecommerce platform order and payment records reflect the status of the booking. Note, that if a refund is required in this scenario, ecommerce platform would not be able to process the refund and an alternative method of payment would need to be used.

Copy Payment Page URL

This may be used if you want to view the payment page for an order where alternative card details need to be entered, or corrected. This may be used if entering the details for a card over the phone (note that the customer will still be required to verify 3DS so this may not be possible), or if the customer is on-site. Alternatively, you may wish to manually email the link to the customer if they are having problems receiving the automatic emails.

Cancel Payment

If an order is cancelled, and the deferred payment is no longer required (if outside of the cancellation terms), you will also need to cancel the deferred payment separately.

To do so you will need to click 'Cancel Payment' as shown in the image above (See payment History)

This may also be used in conjunction with ‘Mark as ‘Paid’’ if the customer has paid offline. Cancelling a payment will ensure that ecommerce platform makes no further attempts to take payment.

Resend Payment Email

If a customer has not received payment the payment email after a failure, use this option to resend to the customer again. Note that it is worth checking that the original email address for the customer is correct and contains no typos. If this needs to be edited, it can be done so via the general tab for the order.

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

The SynXis API doesn’t have knowledge of a deposit, just the data relating to the booking (guest information, dates, room/rate, extras, price sold etc).

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).

Roomlynx does allow ecommerce platform to post deposits automatically, so there is no manual effort required.

Each time a payment is made, the booking will be updated to post the deposit, and also notes will be added to detail the dates that the payment was taken by Stripe for extra information if required.

Roomlynx pushes all of this information into Rezlynx so the systems automatically reconcile payments.

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.

Items in the basket (spa, products etc) other than a room will be paid in full at the point of placing the order, so the payment options in this document only relate to rooms ordered.

Journey's ecommerce platform will always take full payment for an order by the time the client arrives at the hotel. There are no options to pay on arrival. This is because there are no monthly invoices for the use of ecommerce platform as payment for using the platform is deducted from each transaction.

Payment options affect all rates. It is not possible to change payment options per rate at this stage, but providing a solution for more flexibility is in the roadmap.