Booking and Payment

[mathie...@noath.net]

Hello,

I was reviewing the updated architecture at https://github.com/windingtree/wiki/blob/master/architecture-hotel.md and the associated swagger API https://windingtree.github.io/docs/swagger-ui/

The information I see missing on the swagger to handle the booking and payment operations are:

- What passenger data is required for the booking and how to transmit it

- What are the payment methods available: LIF, CC, ..

- If the rate is pre-paid or post-paid

- If advanced deposit is required and amount

- What is the cancellation policy

Both booking and payment operations involve the transmission of sensitive data (from GDPR and PCI-DSS when using credit cards) from the booking party to the supplier party. In many systems currently the hotel requires the passenger name and a credit card to guarantee the booking if it is post-paid.

You also need to handle cases like cancellation, no-show and how to charge the cancellation fee with the passenger absent.

One idea that I would suggest is to add Passenger and Credit Card objects, and allow to send this data to an https endpoint defined in the hotel object.

For example in the hotel object, an hotel could add: {'reservation_endpoint': 'https://secure.myhotel.com/wt-reservation'} and when doing the booking it would be just a matter of sending a POST request to this endpoint with structured passenger and/or payment data. Using an https adress would bring a layer of encryption, another layer could be added by encrypting the sensitive data with the hotel public key. Using something else than an https address must be considered very carefully as it might be difficult for an hotel to have it approved by a PCI-DSS and GDPR auditor.

Do you already have some thoughts on how to handle the booking and payment in a compliant way?

Regards,

Mathieu

[Robin Gottfried]

Hello,

thank you for your feedback.

We plan to work on booking and payment after we finish and test hotels listing (with room types, rate plans and availability). That is why the information is still missing from the data specification. The list of features still missing in specification is summarized here.

I expect that we will work on booking data specification in autumn. I added link to this topic to card in our Trello board for later reference when the work starts.

The generic idea of booking and payment is described in our a architecture document. If you would like to take part and contribute, it would be great if you add proper format of booking and payment message to the hotel-data-swagger.yaml and create a pull request. Regarding naming and specific data format, we are trying to keep it close to OTA specification.

Again thank you for your review!

Regards,

Robin

[mathie...@noath.net]

Hi Robin,

Thanks for your quick answer!

OK I understand that you don't have it in your summer release. This means if I don't miss a point that it will not be possible to have an MVP until Q3 this year right?

Regarding the booking and payment data, sure I can have a look to extend the swagger. Just two doubts:

1. Since this is not hotel specific but can potentially be used in other use cases like airlines shouldn't it be placed in a separate swagger?

2. Wouldn't it be better to clarify the booking and payment flow first? Maybe a sequence diagram would help here, happy to create a draft for your review.

Cheers,

Mathieu

[Robin Gottfried]

Hi Mathieu,

I am not sure if I understand the question. I can imagine MVP where booking and payment are realized off the Winding Tree platform (phone call, web page order, regular cryptocurrency transaction or bank transfer). Anyway I do not expect booking or payment  to be ready for testing in Q3.

Regarding the swagger extension - We do not have detailed diagram of booking nor payment yet. But the booking process will start by sending "booking request" from user to hotel. If we will have spec of the informations which are required to start booking (room type, rate plan, price, conditions, personal info of all guests, ...) it would help us when we start work on the booking process.

As I wrote, we did not started the work yet but here is my rough vision how it could work:

1) A user sends booking request to a hotel. The request should contain everything the user wants to by including price, paid and free services, contacts to guests, etc.

2) The hotel verifies the request and check that the offer is still open (availability, etc.) The hotel respones by confirming the booking request (by signing the booking request) or by a rejection message with a reason.

3) If the hotel accepts the booking request, the user and the hotel creates unique ID of the contract they aggreed to by calculating hash of the booking data (hmac e.g.).

4) [payment] If the hotel requires payment / deposit in advance they can trade the ID on blockchain.

The is still a lot of unanswerred questions like

- how resellers will contribute to booking/payment?

- where / if to store contract details (sensitive data)?

- ...

Cheers,

Robin

--
You received this message because you are subscribed to the Google Groups "Winding Tree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to windingtree...@googlegroups.com.
To post to this group, send email to windi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/windingtree/9050f8c6-b48a-4006-8386-ec5d5a80b48e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jirka Chadima]

Hello,

you can check the latest development on Booking data format on https://github.com/windingtree/wiki/issues/61, the technical description is being solved in https://github.com/windingtree/wt-booking-api/pull/2

The format is based on what we currently have in WT platform and some things are totally missing. Feel free to comment on github or here

Thanks for any feedback,

Jirka Chadima

[renold...@gmail.com]

Hey there,

just wanted to let you know that we are trying to address the payment and of course the booking preliminary. something which we d like to finalize and showcase during the hackathon. It wont be a full blown payment solution but we want to address the questions that you have listed here. 

In order to facilitate payments we are building a sample booking contract to be signed by different parties. This would contain minimum information from payment data in order to link off chain payment data with on chain bookings. 

In addition, we are working on the contract required between hotels, or supplier in general, and a financial institution that would be taking over the risk when payment is not via cash, lif or transfer. So for any payments or guarantees required in advance. The idea here is to have such agreements in on-chain-contracts happening on the fly or at least with minimum activities happening in advance. that means the hotel needs no i.e. credit card acquirer, because one will be found at the booking time.   

that said, i would be happy to work with you in fine tuning the above and bringing these as close to reality as possible given that the knowledge on payments is guaranteed by us (interfaces, data modeling, etc).

feel free to contact me directly to elaborate more prior to hackathon!

best 

Renold