API | Type | Latest version | Test account | Know how (s) |
---|---|---|---|---|
ExternalOrderService ExternalOrderFacade |
SOAP and REST | 1.33 | available | Sample queries |
File: all the ticketing operations concerning the demand of a given client. A file is made of one or many orders, which may be complete (all operations of the order are linked to the file) or partial (an order is dispatched amongst many files)
Order: Ticketing or service operations concerning a simultaneous request of a purchaser. An order can be associated to a cart.
It can be a booking/sale, refund order (upon request of the organization or public)…
Operation: Request of ticketing, associated with an order line that can regroup several operations.
For instance, an operation can correspond to a certain quantity of numbered seats or non numbered sold or refunded places, to a certain quantity of items of simple products (performances), to charges (simple, payment, delivery charges,…), etc.
The simples charges added when there is an order are represented by a specific operation, following the type of operation carried out (booking/sale, option).
An operation can be decomposed in a certain number of movements.
Link Operation: link between two operations. Such a link can be created for an operation of simple charges linked to the operation for which those charges have been calculated, as well as when an operation is resumed.
Movement: Line of an operation of an order, corresponding to a numbered seat, or to a place in a sale non numbered zone, or to a product request (other than of a family “Single ticket” type). An operation has as many movements as its established quantity.
The other entities of this model are part of the catalog detailed above in this document.
Reminder: In the whole document, the contingent is shown and it is possible to pass it as a parameter to some methods, but in a first version, the Resellers have access only to one contingent. Thus, if in those methods the contingent is not specified, the only authorized contingent for the channel will be automatically used.
The sale process is composed of several steps:
The validation of the order allows using the interface in a 2-phase commit mode. If the Reseller wishes, he can skip this step and directly call the closure of the order.
To verify the coherence, it is possible at any time to call the getOrderDetails method that makes a detailed list of the current content of a given order.
Note: In S-360 there is a timeout mechanism, thus, if an order is inactive for too long (the exact time is configured per sales channel in the S-360 administration), the order is cancelled.