Platform and security
| Question | What your answer decides |
|---|---|
| Do you filter inbound traffic by IP address? | If so, D-EDGE sends you the addresses to allow before the tests. See Transport security. |
| Do your endpoints run on HTTPS with a valid, trusted certificate, on TLS 1.2 or higher? | Required on every endpoint you host. |
On your POST endpoints, do you accept both text/xml and application/xml as request content type? | D-EDGE sends application/xml; charset=utf-8 today, and your parser must not depend on the header. See Requests. |
| Which credential model do you provide: one login and password per hotel, or master credentials for all hotels? | Master credentials unlock the all-hotels variant of Get bookings. See Choose a credential model. |
| Do you validate incoming XML against a schema before processing it? | Tells D-EDGE how strictly your endpoints read the messages, including the namespace declarations and the byte order mark D-EDGE messages can carry. |
| Do your booking messages carry card details? | If they do, D-EDGE routes your booking flow through its PCI environment, and you tell your D-EDGE Connectivity Project Manager before the connection is set up. See Card data. |
| Do you provide an administration interface to hoteliers? If so, which URL? | The D-EDGE team uses it to check what your platform received, during the tests and later in support. |
| Does a hotel need a technical activation on your side before it can receive XML? If so, how does it work? | It becomes a step of Connect a new hotel for your integration. |
| Once a hotel is connected to D-EDGE, is its planning locked against manual changes on your side? | Explains to hotels where they manage their planning once the connection is live. |
| Is your test hotel reachable on your production URLs too? If so, under which hotel code? | Lets D-EDGE keep a test hotel connected after the pilot. |
| Who are your technical, support, and sales contacts for this connection? | The D-EDGE team reaches them during the tests, in support, and for new hotel setups. |
Rooms and rates
| Question | What your answer decides |
|---|---|
| How are room types and rates structured on your platform: one or several room types, one or several rates, and how are they linked? Can one room type carry several rate codes? | Shapes the Get hotel response and the mapping D-EDGE builds from it, and decides whether the multi-rate scenarios apply. |
| How do you handle meal plans: as separate rates, as a property of the rate, or otherwise? Can you store the meal price separately from the room price, per adult and per child? | Decides how D-EDGE maps meal-inclusive rates, and whether your connection carries the meal plan detail. |
| Do you manage negotiated or contracted rates with special rules, such as prices D-EDGE must not update? | D-EDGE maps such rates with an update type other than PRI. |
| Do you manage rates derived from another rate, such as a discount on the flexible rate? Are they linked to D-EDGE or computed on your side? | If D-EDGE also updates a derived rate, the rate has two sources of truth: D-EDGE and your own calculation. |
| Do you manage allotment contracts directly with hotels, with a contracted number of rooms? | Contracted availability lives next to the free availability D-EDGE sends, and the two must not be confused. |
| Do you handle several currencies? Is the currency defined per hotel, or per hotel and rate? Do you connect hotels outside the euro zone? | Decides the currency attribute you return in Get hotel and how D-EDGE handles a mismatch. See Currency. |
Availability, prices, and restrictions
| Question | What your answer decides |
|---|---|
| At which level do you store availability: per hotel and day; per room type and day; or per room type, rate, and day? | Decides whether the connection sends room-level availability only, or per-rate availability too. |
| At which level do you store prices: per room type and day; per room type, rate, and day; or per room type, rate, and occupancy? | This is your price model: PerDay, PerPerson, or PerOccupancy. It shapes every planning update for the life of the connection. |
| How far ahead do you store availability, prices, and restrictions, in days? | The scenarios send updates up to that horizon, and D-EDGE caps the initial synchronisation accordingly. |
| Which maximum values does your platform accept for availability, prices, minimum stay, and maximum stay? | The tests send very low and very high prices, which your endpoint must accept. For every other value, the tests stay under your limits. |
| How do you treat a price of 0: ignored, a free night, or refused? | D-EDGE avoids sending a value your platform would misread. |
| Do you expect sellable prices, commission included, or net prices? VAT and local taxes included, or excluded? | Prices are sellable, commission included, by default. See Fill the amounts for your payment model and the price conventions below. |
| Do you manage a minimum stay and a maximum stay? If so, do they apply on arrival or through the stay, and at which level? | D-EDGE sends minimumStay and maximumStay per room, rate, and day, from 1 to 99 nights. |
| Do you manage closed to arrival and closed to departure? At which level? | If not, D-EDGE tells hotels the restriction is not available on your platform, and a workaround exists for closed to arrival. |
| At which level do you manage open and closed to sale: room type, rate, room and rate, or occupancy? | Every integration must handle isClosed; the tests send it to all. Occupancy-level closing matters under PerPerson and PerOccupancy. |
Bookings
| Question | What your answer decides |
|---|---|
| Do you return complete customer data (names, email, address, phone) and the guest details of each room, with one guest per person? | Decides which customer and guest checks apply. D-EDGE counts the guests of a room by ageRange. See Booking message. |
| Can one booking hold several room types? Several rooms of the same type? Several rates? | Decides the multi-room and multi-rate booking scenarios. |
| Do you allow booking modifications? Which ones: dates, rooms, guests, rates? | Decides the modification scenarios, and whether hotels can expect modifications from your platform. |
| Do you allow booking cancellations? | Decides the cancellation scenarios. |
| How do you manage cancellation policies, and do they differ per hotel or per rate? | Policies stay on your platform; a booking carries the one that applied as a distributor comment. |
| Which guarantee types do you apply: card guarantee, partial prepayment, full prepayment, virtual card? Can the guarantee differ per rate? | Decides how you fill the four booking amounts. |
| In which cases do you return card details: under which guarantee types, and always or only sometimes? | D-EDGE reviews these cases before it enables the PCI routing, and hotels need to know when to expect a card. |
| Do you return sellable or net prices in bookings, VAT and local taxes included or excluded? Does it depend on the guarantee? | See the price conventions below. |
| Do you sell anything other than rooms, such as extras or add-ons? How does a hotel configure them on your side? | Decides the extras scenarios, and where each extra belongs in the booking message. See Put extras where they belong. |
| Do you allow late bookings, after midnight hotel time, for the current night? | D-EDGE integrates them; the hotel needs to know they can arrive. |
| Is there any case where your platform accepts a booking on a closed room or rate? | Not recommended. If so, describe the feature behind it. |
| Is your booking identifier unique and never reused for another booking? | The id is the key of the whole booking lifecycle. |
Which distributor comments do you return, and under which names? | The hotel reads them as free text. |
| Do you send an email to the hotel when a booking is created, modified, or cancelled? | Hotels receive the booking from D-EDGE too; they need to know when to expect both. |
| How do you use the Confirm bookings acknowledgement? | Tells D-EDGE whether your retry logic relies on it, as recommended. |
Price conventions
For the prices D-EDGE sends you, and for the booking prices you send D-EDGE, state whether the amounts include or exclude the commission, VAT, and local and city taxes. Describe the cases where your platform allows several configurations.Next steps
Certification steps
The hand-over, the two test phases, and the pilot.
Test scenarios
Every scenario D-EDGE runs, what it sends, and what it expects.