Skip to main content

Hi everyone 👋

One of the next topics we are looking into for the Guest Portal, is giving you more flexibility to decide whether you want to collect the payment card details as part of the online check-in (OCI) flow. 

Today it is mandatory and we know it does not fit every situation: credit cards are less prevalent in certain countries, it may not be necessary for prepaid rates, it creates unnecessary confusion or drop-offs from guests, etc.

We are not ready to launch a BETA just yet 😉 but we’re exploring a few options and wanted to share our current state of thoughts to hear your feedback.

  • Set-it up at the Bookable Service level where you could decide to ask for cards in OCI, or make it depend on whether the rate is (partially/fully) prepaid or not. This is similar to the set-up we have in place for the Booking Engine. 
    • I’m wondering whether that’s not granular enough? - i.e. you may want to collect card details for OTA bookings, whether they are prepaid or not, when you only have VCC details from the OTA.
  • Set-it up at the Rate Group level, with an option to request or skip card details as part on OCI. Payment policies are also defined at that level so that seems quite logical.
  • Set-it up at the Rate level. This feels like it may be too granular given the number of rates in use? It would take more time to set-up and also be more cumbersome to maintain. 

Any feedback on the above? Or other suggestions? Please add your thought in the comments. We’d love to hear more to make our solution as easy to work with as possible. 

Thank you in advance!

  • Set-it up at the Bookable Service level where you could decide to ask for cards in OCI, or make it depend on whether the rate is (partially/fully) prepaid or not. This is similar to the set-up we have in place for the Booking Engine. 
    • I’m wondering whether that’s not granular enough? - i.e. you may want to collect card details for OTA bookings, whether they are prepaid or not, when you only have VCC details from the OTA.
  • Set-it up at the Rate Group level, with an option to request or skip card details as part on OCI. Payment policies are also defined at that level so that seems quite logical.
  • Set-it up at the Rate level. This feels like it may be too granular given the number of rates in use? It would take more time to set-up and also be more cumbersome to maintain. 

Hello!

Great to hear there is some progress on that topic!

Primarily, we would like to remove as much hurdles as possible from OCI as possible.

So a Setup at bookable service level would be great. (disabling/enabling it by default)

But also let’s look at it from the other way round - when do your really like to ask for a validated credit card? So disabled by default at service level, but required in those cases:

  • when there is no card associated with the reservation at all AND a setting at the rate / rate group levels requires it (so some company or group travel rates / rate groups are exempted)
  • when a due payment with a card on file failed previously (happens with guest credit cards received from OTAs when the MoTo transaction for prepaid reservations fails, or the card was stolen)
  • can anyone think of other possible must have cases ?

By the way, the same applies to kiosk check-ins, also for staff mode kiosk for electronic check in at the front desk. Currently, there is no credit card requirement at all as far as I know … it should be possible to at least remind staff during the check-in process that a credit card is required (as for the above mentioned cases) - but allow to skip it (if the guest has no card, pays cash, whatever ...).

Basically, during OCI be as relaxed as possible regarding credit cards, only ask for it in really important cases where it would lead to more time lost at check in. During on-site Check-In it could be a little more strict, asking for credit card details (for example to be logged into mews via mews terminal) for a broader range of cases (like for when only VCCs are available), or for all reservations without validated cards, depending on individual hotel policy.

Kind regards,

JP.


@Olivia.Dingreville thats awesome. This is gonna remove so much frustration for us and our guests because a lot of system specific problems we have are revolving around credit cards. The possibility to take payment cards completely out of our system until the actual payment is gonna be a huge improvement.

A setting of mandatory, optional or hidden would be neat i think. Granularity wise i don’t have a strong opinion but on service and even rate-level seems to cover many cases.

One problem with the current system we see constantly is that guests not really understand that it is optional to enter a credit card. It would be great if the ui of the new system transported the payment options more clearly.

Another problem i see getting worse with those changes is that it is not possible to view these guests areas … i mean as the guests sees it. I know we can create a reservation and then view the guest portal and online-checkin, but thats just for that reservation. With additional rulesets that change what is shown, there are so much more scenarios were the guests view is different from what our booking looks like.

Just yesterday the support closed a ticket with our online-checkout not working correctly because they cannot comprehend that and requesting further information. Problem is: we can’t give that … because we cannot view the online-checkout of the guest and therefore cannot send any examples or even have a look at that problem.


Another problem i see getting worse with those changes is that it is not possible to view these guests areas … i mean as the guests sees it. I know we can create a reservation and then view the guest portal and online-checkin, but thats just for that reservation. With additional rulesets that change what is shown, there are so much more scenarios were the guests view is different from what our booking looks like.

Just yesterday the support closed a ticket with our online-checkout not working correctly because they cannot comprehend that and requesting further information. Problem is: we can’t give that … because we cannot view the online-checkout of the guest and therefore cannot send any examples or even have a look at that problem.

I can second that! We have no idea if the online check in rate is low because guests are lazy and don’t read our messages, it doesn’t work for them, they stop at credit card request, or whatever .. same for online check out. For Admin level users it would be great to have at least some analytics access - at what step did the process stop, did they even start it ? - although, I guess MEWS does have the analytics! So I hope you guys at MEWS use that insight to assess where there could be some improvements and make us all happy 😀


hi @Olivia.Dingreville, at a rate level yes!

we are still facing a lot of remarks (and drop off in the OCI process) at the step of the payment card, simply because in (some) of my properties the majority of reservations is fully pre-paid using IDEAL, since these guests don’t have a credit card.. hence skipping this step is very benifical for them.

If you seriously consider to set it up at bookable service level, you are asking hotels to completely rethink their operations, as it would change everything we do; we also see guests changing rate plan after a reservation was made (from flex to non-ref), and with such a setup we would be screwing up our entire stats. 

On rate group level could work, but that is - in our organization - how we organize the cancellation policies. That is why we group specific rates at this moment. 


@Kayleigh @dvdb @jeroenmaaneman 


This is a great development, especially when it come to group rates and companies who have already paid the full amount up front etc.!

  • Set-it up at the Rate Group level, with an option to request or skip card details as part on OCI. Payment policies are also defined at that level so that seems quite logical.
  • Set-it up at the Rate level. This feels like it may be too granular given the number of rates in use? It would take more time to set-up and also be more cumbersome to maintain. 

@Ivo 


Hi Olivia,

 

What a great feature idea.

We have been struggling with this for a while as a dedicated corporate business. In many situations corporate clients with big portfolios feel reluctant to allow their guests access to our native comms and portals.

This is due to brand retention form their end btu also the Credit/Debit card request which could put a corporate traveller with all expenses paid on the fence of positive review.

I’d opt in for the:

  • Rate Group
  • and Rate Plan (optional)

The reason for this is that it will bring more cohesive PMS management and configuration. There are quite a lot of settings that are scattered around to serve a common area of control.

Placing charging on OLCI should be linked to Payment/Automatic Settlement logic and these are positioned on a Rate Group level. This is where you have your settings and controls for your Corporate, OTA and leisure guests. 

Locating this control at the R Groups will also serve better than the Service level controls - the later are too broad and provide no further flexibility or diversity.

Looking forward to this development!

Igor


This is a great development, especially when it come to group rates and companies who have already paid the full amount up front etc.!

  • Set-it up at the Rate Group level, with an option to request or skip card details as part on OCI. Payment policies are also defined at that level so that seems quite logical.
  • Set-it up at the Rate level. This feels like it may be too granular given the number of rates in use? It would take more time to set-up and also be more cumbersome to maintain. 

In such scenarios i think the best approach is to create a cascading system just like CSS for formatting websites is. So you have the option to place a “payment” rule at certain levels like: global, property, service, rate group, rate and maybe something even more granular. Each step from top to bottom inherits the rule from above except a rule is placed on that level … then it overwrites to above one.

So if you don’t need complex rules you just define one on the global level. But if there is a certain rate for example that needs a different rule you can overwrite the global rule on this level.

So you have all the granularity you need but i you don’t want that you don’t have really that much complexity. This may seem weird at first glance but once you understand this logic its really intuitive.

This approach would also be useful in other cases settings wise.


This is a great development, especially when it come to group rates and companies who have already paid the full amount up front etc.!

  • Set-it up at the Rate Group level, with an option to request or skip card details as part on OCI. Payment policies are also defined at that level so that seems quite logical.
  • Set-it up at the Rate level. This feels like it may be too granular given the number of rates in use? It would take more time to set-up and also be more cumbersome to maintain. 

In such scenarios i think the best approach is to create a cascading system just like CSS for formatting websites is. So you have the option to place a “payment” rule at certain levels like: global, property, service, rate group, rate and maybe something even more granular. Each step from top to bottom inherits the rule from above except a rule is placed on that level … then it overwrites to above one.

So if you don’t need complex rules you just define one on the global level. But if there is a certain rate for example that needs a different rule you can overwrite the global rule on this level.

So you have all the granularity you need but i you don’t want that you don’t have really that much complexity. This may seem weird at first glance but once you understand this logic its really intuitive.

This approach would also be useful in other cases settings wise.

Like that very much @jones.eth !


Hi @Olivia.Dingreville ,

thats really a great feature we would also use in some cases,

 

  • Prepaid Rates
  • Reservations / Corporate Rates where we sent an invoice
  • Blocks where guests doesnt have t pay by themselves
  • Bookings with VCCS
  • We use Mews Kiosk in every property and are very happy to get more OCI

Different Topic but:

Regarding VCCS we have the issue that we need to manually charge them at the day of arrival. Mews cannot distinguish between booking with VCC and guest credit card. 

@Daniel.Schleser 

Happy to hear more of it when you have a beta ready

 

Best

Linus 

 


Hi @Olivia.Dingreville,

This sounds exciting! We have been struggling with online check in from day 1. I can think of many, many examples that should be excluded from adding creditcard details to complete an online check in. It would be of great help if hotels can decide on their own whom en when to ask for creditcard details. 

I agree with @jones.eth, a cascading structure would be really usefull and easy to use as a hotel. This way, you can include all exceptions and make it fit perfectly to your specific property. You might even think of setting it per market segment as an addition.  

We would definitely benefit of this new feature, looking forward to news on this topic 💡

Regards, Sanne 

 


FYI @Jasmin H.


Reply