Accreditation Criteria
To facilitate a smooth and efficient review, the following table details the specific criteria our team will check during the accreditation process.
API Settings
Credentials | Are the correct API credentials being used for all API requests? | ℹ️ The credentials are unique and are shared by your Partnership Manager at the start of the project. | ✅ Required |
PCI compliance | Are you PCI compliant? | ℹ️ When handling credit card payments you must be PCI compliant. | ⚠️ Required by National Rail |
Search Parameters
Location search | Can the user clearly search by selecting cities or stations? | ℹ️ Users must have the option to search both by city and station. If this dual-search capability cannot be provided, it is acceptable to offer at least one of these search options: either by city or by station. | 🟢 Required ⚠️ If trading Trenitalia, both are mandatory |
Single & return trips offered | Can the user select either a single trip or a return trip? | ℹ️ Users must be offered both single and return trips, whether they are built as one single API flow or two flows. | 🟢 Required |
Passenger types offered | Can the user select passenger types beyond adult (PNOS)? | ℹ️ Users should be allowed to set their accurate passenger type or age. You should try to cover all possible passenger types as much as possible by sending the exact age of each passenger, or group into your own passenger categories, but always ensuring that all ages are covered. | 🟡 Strongly Recommended |
Departure time | Can the user define the departure time of the trip? | ℹ️ Users could be offered the option to define the departure start time for more precise results. | ⚪️ Optional ⚠️ Required by Trenitalia, SNCF, DB, SBB |
Search Results
Loading speed | Do the search results load within 3 seconds? | ℹ️ Results must be presented to users quickly, but should not be cached on your side. | 🟢 Required |
Station naming | Can the user clearly identify the stations within the search results? | ℹ️ Results must clearly display the names of both the departure and arrival stations for each departure item. | 🟢 Required |
Content parity | Are all departures for the specified trip displayed in the search results? | ℹ️ Results must include all departures presented by the carriers in the API response. | 🟢 Required |
Coverage parity | Are all routes offered by carriers available in the search results? | ℹ️ Results must include the full content available from carriers. | 🟡 Strongly Recommended ⚠️ Required by Trenitalia |
Price | Are prices correctly displayed for one and multiple passengers, including different passenger types? | ℹ️ The API request must specify the passenger's age e.g. a pax group of one person aged 40, two people aged 16, and one person aged 10 would require a /connections/find request with parameters | 🟢 Required |
Number of free seats | Can the user see how many seats are still available for each departure or fare class? | ℹ️ Results could show the number of seats available per departure or fare class when available by the carrier. | ⚪️ Optional |
Trip duration | Can the user see how long the journey duration is? Is the value correct? | ℹ️ Results must show the duration of the trip from departure to arrival station. | 🟢 Required |
Departure & arrival time | Can the user clearly see departure and arrival times? Are the values correct? | ℹ️ Results must show the exact departure and arrival times of the trip. | 🟢 Required |
Multi-segment | Can the user clearly see if the trip is multi-segment and if so, where the change of vehicle will take place? | ℹ️ Results must show all the segments of the trip, and when multi-segment trips are offered by carriers, include the connecting times and stations. | 🟢 Required |
Vehicle type | Is the vehicle type clear to the user? | ℹ️ Results should show the vehicle type used by the carrier to run the trip such as bus or train using clear icons and/or text labels. | 🟡 Strongly Recommended |
Line details | Is the line number displayed to the user? | ℹ️ Results should include the line details of each trip including the number and the prefix of the line. The line details help passengers identify the line and brand of the vehicle they are booking, which is also helpful information at the time of travel. | 🟡 Strongly Recommended ⚠️ Required by SNCF, LTG Link, DB, Trenitalia, European Sleeper |
Carrier logo | Is the carrier logo clearly displayed to the user? | ℹ️ Results must show the official logo of the carrier operating the trip. | 🟢 Required |
Operating carriers | Can the user identify the operating carrier of each trip segment? | ℹ️ Results could show the name and logo of the carrier operating the segments of each trip if that differs from the marketing carrier. In most cases the marketing carrier matches the operating carrier. However, some carriers might use different brands/partners for specific trips or trip segments. | ⚪️ Optional ⚠️ Required by Trenitalia, SNCF |
Amenities & features | Can the user see which fare features and amenities are available on the trip? | ℹ️ Results must show the fare features/amenities included in the fare class. Carriers differentiate their fares by providing varying fare features and amenities, which should be displayed with labels or icons, including full descriptions. These include features such as wifi, toilet and snacks. | 🟢 Required |
Fare classes | Are fare class options clearly displayed? | ℹ️ Results should show the full list of fares available from each carrier per trip. | 🟡 Strongly Recommended ⚠️ Required by Trenitalia, SNCF |
Carrier fare names | Are the original fare names displayed for each fare? | ℹ️ Results must display the official and full fare names from carriers, also in the whole booking flow. The fare names set by carriers include important details that must be made available to users. | 🟢 Required |
Cancellation & refund policy | Is the carrier's cancellation and refund policy clearly displayed to the user? | ℹ️ Results must show the specific fare feature related to the cancellation, amendment and refund policy included in the fare class. | 🟢 Required |
Fare conditions | Are the specific fare conditions clearly displayed next to each fare class? | ℹ️ Results from some carriers must display the specific fare conditions (after-sales rules) for each fare in the search results page. In this case they present their fare conditions (such as cancellation and refund policies) attached to each fare-class and segment in a different field than other carriers. | ⚠️ Required by SNCF and National Rail |
Check-out
Ticket validity | Can the user clearly see how long the ticket is valid for? | ℹ️ Users should be able to see the validity time of the ticket. Some carriers offer tickets that are non-fixed departure and can be used for a set period of time. This is common for tickets that allow passengers to travel multiple times or start their trip at a different time other than the set departure time. | 🟡 Strongly Recommended ⚠️ Required by SBB, DB, NS |
Marketing carrier Terms & Conditions | Can the user find the carrier’s Terms & Conditions with links to the carrier website? | ℹ️ Users must be presented with the official Terms & Conditions of the carrier. In most cases, the carriers have one link for all T&Cs but some carriers might have multiple links. In this case, it is required that all links are displayed to users in the UI. | 🟢 Required |
Price markup | If there is a price markup, can the user identify this as separate from the ticket price? | ℹ️ Users must have full visibility of any mark-up added to fares in the check-out page. Mark-ups (e.g. service fees) can be added by you, but they must be clearly differentiated from the carrier offering and price. 🔗 Fees | 🟢 Required |
Price and vacancy check | Has the /connections/vacancy endpoint been implemented as intended, prior to booking? | ℹ️ Users should always see the most updated price and availability before completing the booking. This is important to confirm the availability and price for the requested combination of passengers on the selected trip, as the content from the /connections/find response is cached. | 🟢 Required |
Reservation & Booking
Parameters from schema | If a carrier requires certain passenger parameters, are these being collected on the frontend and passed in the /reservations/create and /reservations/confirm request? | ℹ️ Users should be asked for all relevant details at the time of booking and the details captured must be included in the /reservations/create and /reservations/confirm request. 🔗 Creating Reservation, Confirming Reservation, Dynamic Passenger Details & Required Passenger Detail | 🟢 Required |
Reservation parameters | Does the reservation request include all the correct parameters (including stations, times, RPN, price, passenger info etc.)? | ℹ️ Details captured during the flow must be correctly included in the /reservations/create request. | 🟢 Required |
Passenger details | Does the reservation include real passenger details? | ℹ️ The passenger’s real information must be included eg. first & last names, email, government ID in the /reservations/create and /reservations/confirm requests, instead of using dummy data or the agent’s booking email. | 🟢 Required |
Custom passenger details | Does the reservation include the country of the user IP and country of card payment? | ℹ️ National Rail differentiates the commission level based on the location of the passenger. Therefore, the | ⚠️ Required by National Rail |
Cancellation of reservations | If the checkout is aborted by the user before a reservation is confirmed, are you cancelling the reservation with /reservations/cancel? | ℹ️ When the user indicates that they are not interested in completing a reservation by leaving the check-out page or cancelling the request, the reservation must be cancelled to ensure the seats are not blocked with the carrier. | 🟢 Required |
Cancellation after confirmation | Ater a /reservations/confirm is initiated, are you preventing your flow from sending a request to /reservations/cancel? | ℹ️ When the process of confirming a reservation is triggered it can't be stopped, so it is important that no requests to /reservations/cancel are sent after one to /reservations/confirm. If a cancellation is needed at this point, you must wait for the confirmation from the carrier and initiate the cancellation flow. | 🟢 Required |
Prices validation | Are you ensuring that the price displayed to users for each step is always taken from the previous API response? | ℹ️ Users should always see the most recent price information before proceeding to the next step. It means that after each API request, the price information should be checked and if any changes occur the new price should be displayed to the user. For example, the final price displayed on the checkout and payment pages must be taken from /reservations/create. | 🟢 Required |
Reservation processing deadline | Are you calling the /reservations/{reservation_id} endpoint repetitively until getting a | ℹ️ Carriers usually take a few seconds to respond to a reservation, with most responding within 10-15 seconds. However, in a few exceptional cases it can take longer so it is critical to keep checking the status until | 🟢 Required |
Reservation status check frequency | Are you calling the /reservations/{reservation_id} endpoint every 3-10 seconds? | ℹ️ To optimise the user experience and to prevent spamming carriers with requests we suggest calling the /reservations/{reservation_id} endpoint regularly in intervals of 3 to 10 seconds depending on your needs. | 🟢 Required |
Reservation confirm | Are you calling the /reservations/confirm endpoint only once during the flow? | ℹ️ A reservation should only be confirmed once, and making additional call does not speed up the process. | 🟢 Required |
Convenience fee | Are you displaying the covenience fee in the checkout page before user completes the booking? | ℹ️ Users should be able to view the convenience fee in the checkout. PT Kereta Api Indonesia is one of the only carriers that includes it with every booking. | ⚠️ Required by Indonesia Railways (PT Kereta Api Indonesia) |
Ticketing
Confirmation email with ticket | Does the customer receive a confirmation email including the pdf ticket? | ℹ️ Users must receive a confirmation email with a copy of the pdf ticket right after booking. | 🟢 Required |
Ticket printing requirement | Is it visible to the user that the ticket can be displayed digitally? | ℹ️ Users should be clearly informed if a ticket has to be presented for boarding in a printed format. | 🟡 Strongly Recommended |
Availability of ticket options | Does the user receive other ticket types where available? | ℹ️ Users should receive other options of tickets such as Google Wallet or Apple Wallet. | 🟡 Strongly Recommended |
Cancellation and amendment policy in email | Does the user receive an email with detailed information on cancellations and amendments? | ℹ️ Users should have clear information on cancellation and amendment policies in the confirmation email or in your platform. Email to customer which includes the ticket should display the text as obtained from the API. If using the standard Distribusion email, this information is available. This can also be displayed in your platform, and user needs to be informed about how to amend a ticket. | 🟡 Strongly Recommended ⚠️ Required by Trenitalia |
Provisional ticket | Is the user informed about how to get permanent tickets? | ℹ️ Tickets deliverd by Trenitalia for their regional network are not valid for travel. This is stated directly on their PDF ticket. When using your own email format, passengers must be informed in the body of the booking confirmation email and a link to the Trenitalia website where the permanent ticket can be retrieved must be included. | ⚠️ Required by Trenitalia |
Post Sales
Cancellations | Can users cancel a booking? | ℹ️ Users should be able to cancel a booking directly with you. Ideally, you should offer the ability for users to cancel a booking via your interface. This flow is fully supported by Distribusion API and allows users to view cancellation conditions and cancel a trip. If not supported via your API, you can use the Distribusion Agent Portal to cancel trips. | 🟡 Strongly Recommended ⚠️ Required by DB, Trenitalia, Amtrak |
Asynchronous cancellations | Can users see the status of the cancellation after the cancellation is requested? | Depending on the cancellation conditions and if the booking is flagged as potentially fraud on the SNCF side, the cancellation might be marked as "pending". To support this scenario, an asynchronous cancellation process must be implemented and managed on the retailer side. | ⚠️ Required by SNCF |
Amendments | Can users amend a booking? | ℹ️ Users should be able to amend a booking directly with you when supported by the carrier. This flow is supported by Distribusion API and allows users to view amend a trip. If not supported via your API, you can use the Distribusion Agent Portal to amend trips. | ⚪️ Optional ⚠️ Required by SNCF, Trenitalia |
Other Features
Seat Map | Can the user select their seat on a seat map? | ℹ️ Users should be able to view the vehicle seat map and select their seat. | ⚪️ Optional ⚠️ Required by Trenitalia (when selling to Italian customers), Vietnam Railways |
National Rail accreditation mark | Can the user see the National Rail accreditation mark on your website? | ℹ️ Users should be able to see the National Rail accreditation mark on your website alognside the booking flow. Request the file from your Partnership Manager. | ⚠️ Required by National Rail |
What made this section unhelpful for you?
On this page
- Accreditation Criteria