...
For PMS providers that have already been implemented, the below may require changes to the set up they currently have. Whilst SiteMinder could be flexible in accommodating exceptions in the past, the constant increase in the number of PMS installations and is reaching a level where exceptions can no longer be allowed.
| Note |
|---|
Failure to follow these guidelines could jeopardise the PMS interface and, if no action is taken by the PMS provider to rectify non-compliance within 3 months from notification, SiteMinder reserves the right to disable the interface till such corrections have taken place. |
...
If the non-compliance of the PMS puts the performance to the whole SiteMinder production environment at risk, SiteMinder reserves the right to disable the interface immediately. |
...
| Table of Contents | ||||
|---|---|---|---|---|
|
...
The ‘Content-Type’ for all Soap XML requests made to pmsXchange V2 must be 'text/xml; charset=utf-8'. Any other ‘Content-Type’ will not be accepted.
...
Uploaded messages must not be larger than 2MB (uncompressed). You can read more about how we respond to a message larger than 2MB within the 'Developer Guide' on this page.
Bundling Updates
Rate, Availability or Restriction updates must be bundled in instances where the values for consecutive dates are the same. For example, if you are changing a rate of $120 from the 1 July - 14 July you must bundle the message. More information on bundling is included within the 'Developer Guide' on the bundling updates best practice page.
Delta and Actions Performed Only Updates
Request messages (Availability, Restrictions & Rates) must ONLY CONTAIN data relevant to the action being performed in your PMS. For example, if a PMS user is changing the availability of a room in the PMS, you must only send the availability update and no other rate or restriction messages. No unchanged dates should be included in these request messages. More information on each message structure will be contained in the pmsXchange 'Developer Guide'. More details on deltas can be found here.
In addition to this, these updates MUST be sent to pmsXchange V2 in as close to real-time as possible. Updates should be sent within 2 minutes of the change occurring in your PMS.
Non-Delta and Frequent Full Flushes
Updates that are not delta (refer to previous point) and frequent full data flushes within 24 hours is not allowed. These actions could put performance to the whole SiteMinder production environment at risk.
Only perform a full data flush when sending the first updates to a new hotel connection. After that, it should only be delta updates (refer to previous point).
Overlapping Dates
Any 'Inventory API' requests made over pmsXchange v2 should not contain overlapping dates. All date ranges in a singular message should be unique for each Inventory Code/Rate Code combination.
...
These uploads include all messages pertaining to the transfer of inventory counts and restrictions with the PMS capability, pmsXchange compatibility, and as described in the transfer of availability messages to pmsXchange.
The PMS provider MUST ensure that only changes to availability and restrictions, and not full refreshes, are sent. Refreshes should only be sent at most once per day and at times when traffic is low i.e. between midnight and 5 am. Only in exceptional circumstances should additional full refreshes be sent.
Identical changes in availability for consecutive days should be condensed into one message wherever possible. For instance, if the change in inventory counts for room type SGL is = 10 for Jan 1st, Jan 2nd and Jan 3rd, the PMS provider should send one single message to pmsXchange with start date Jan 1st and end date Jan 3rd rather than 3 daily messages.
The PMS will need to establish transaction/error logs to collect error messages generated by the system in case of errors in the transmission of your upload messages. The error log and error messages must be available to the property use for regular checks (to be undertaken by the properties, at a minimum, on a daily basis). For example, if an availability message is rejected by pmsXchange because of erroneous content (for example if it contains a room type code that is not recognised error message. The PMS provider must ensure such message is made available for the property to view and that the property is alerted the transaction was not successful. Upon viewing the error message the property must ensure the appropriate correction is applied as soon as possible and ideally no later than 12 hours from receipt of the message. If no corrective action is taken, and the incorrect message continues to attempt to upload in a loop, SiteMinder will reserve the right to disable the interface till such time as corrective action is taken.
It is advisable that the PMS has a queuing mechanism that queue upload messages in case of lack of connectivity with the pmsXchange service or during scheduled release outages. If pmsXchange fails to respond at all, then the messages should be re-sent when connectivity is re-established.
pmsXchange v2 only allows Inventory Updates for Room/Rate code combinations that are known to SiteMinder (i.e. have been setup and mapped to the PMS within the SiteMinder Channel Manager). If we receive an Inventory Update that contains a Room/Rate code that is unknown to SiteMinder Channel Manager, the entire Update will fail.
Rate Uploads
These uploads include all messages pertaining to the transfer of rate data from the PMS to SiteMinder
For day to day usage, when ARI changes are made, the PMS provider must ensure that only changes to rates, and not full refreshes, are sent. Full refreshes should only be sent at most once per day and at times when traffic is low i.e. between midnight and 5 am. Only in exceptional circumstances should additional full refreshes be sent.
Identical changes in rates for consecutive days should be condensed into one message wherever possible. For instance, if the change in rates counts for room type SGL is = $100 for Jan 1st, Jan 2nd and Jan 3rd, the PMS provider should send one single message to pmsXchange with start date Jan 1st and end date Jan 3rd rather than 3 messages.
The PMS will need to establish transaction/error logs to collect error messages generated by the system in case of errors in the transmission of your upload messages. The error log and error messages must be available to the property user for regular checks. For example, if a rate message is rejected by pmsXchange because of erroneous content (for instance if it contains a rate code that is not recognised by pmsXchange the PMS provider must ensure such message is made available for the property to view and that the property is alerted the transaction was not successful. Upon viewing the error message the property and/or PMS must ensure the appropriate correction is applied as soon as possible and ideally no later than 12 hours from receipt of the message. If no corrective action is taken, and the incorrect message continues to attempt to upload in a loop, SiteMinder will reserve the right to disable the interface till such time as corrective action is taken.
It is advisable that the PMS has a queuing mechanism that queue upload messages in case of lack of connectivity with the pmsXchange service or during scheduled release outages. If pmsXchange fails to respond at all, then the messages should be re-sent when connectivity is re-established.
pmsXchange v2 only allows Rate Updates for Room/Rate code combinations that are known to SiteMinder (i.e. have been setup and mapped to the PMS within the SiteMinder Channel Manager). If we receive an Inventory Update that contains a Room/Rate code that is unknown to SiteMinder Channel Manager, the entire Update will fail.
PMS Payment Transaction Sync
The SiteMinder Pay integration with Channel Manager & Property Platform offers customers the ability to process payments for their Channel and Direct Booking reservations, and secure their funds effectively. Currently, customers have to manually record these payments in their respective PMSs. However, Siteminder is launching a new PMS-Pay Transaction Sync feature that enables SM payment transactions associated with a CM reservation in CM or Property Platform to be passed automatically to participating PMSs as a separate "Payment Transaction". This removes the manual effort required to record payments processed by SM Pay to the customer’s PMS, improving user experience and reducing time spent on managing payments. This feature will increase adoption and transaction volumes for us going forward.
The PMSX payment sync feature introduces a new integration API which allows participating PMSs to sync details of SM payment transactions associated with a CM reservation and display it on their own customer interface. Hotel’s will now have visibility of the payments processed via CM in their PMS, which helps them to process invoicing and pending payments in their PMS more efficiently. This feature is a one-way sync which allows participating PMS systems to pull payment details associated with a channel reservation into their system, SM does not pull payments processed via the PMS back to our systems (future functionality).