Order expiry

Both Connect and downstream Vista services running at cinema locations have a concept of Order Expiry. This concept defines a point whereby an order, if not completed, is considered abandoned and will be "cleaned up". The clean up process can occur at both Connect and/or cinema and will essentially cancel the order.

This should be the same result as a call to the CancelOrder endpoint which involves:

• Releasing any seats reserved as part of the in-progress order
• Releasing/cancelling any reserved 3rd party member tickets
• Removing the in-progress order from the system's databases

Note: This page only applies to orders that are abandoned before payments are taken. Orders abandoned after payments are taken require a more complicated cleanup process.

Expiry configuration

The expiry timeout value configuration is available both in Connect and at cinema and these values should be configured to be compatible with the Connect value ideally the same or earlier than the cinema.

Consult your Connect administrator for confirmation as to how this has been configured.

Expiry value

The order expiry value is returned by endpoints that return an Order, or directly by the ResetOrderExpiry endpoint.

The following example shows a standard GetOrder call returning the expiryDateUtc value.

GET: /orders/b47e5287860b9c906125343c8dab09c2

Response:

{
    "order": {
        "cinemaId": "0000000001",
        "userSessionId": "b47e5287860b9c906125343c8dab09c2",
        "orderTotalValueInCents": 0,
        "taxValueInCents": 0,
        "bookingFeeTotalValueInCents": 0,
        "bookingFeeTaxValueInCents": 0,
        "loyaltyPointsTotalCost": [],
        "sessions": [],
        "concessions": [],
        "createdDateUtc": "2018-10-07T19:50:40.0382165Z",
        "expiryDateUtc": "2018-10-07T20:00:40.0382165Z"
    },
    "suggestedDeals": []
}

Client expectations

Client user interfaces should indicate to their user when their order will expire in some form; for example, an order countdown or an interface that indicates how many minutes the user has to complete the order

When the expiry countdown hits zero the client should:

• Send the user to a 'session expired' page informing them that their order has expired and they must start again
• Ensure a new userSessionId is generated for the user if they choose to retry the order (as the existing order may still exist which could be confusing)

Optionally, the client may also:

• Cancel the order to release any seats selected by the expired session (alternatively it can rely on server-side processes to do this automatically)
• Offer the user the option to manually reset the order expiry before the countdown hits zero (see below)

Expiry calculation

Connect calculates the order expiry value as a number of minutes since the order was created. The value remains static until extended by one of the scenarios listed below.

Manually extending order expiry

Extending an order expiry can be done via the ResetOrderExpiry endpoint.

GET: /restticketing.svc/order/continue

{
  "UserSessionId": "b47e5287860b9c906125343c8dab09c2"
}

Response:

{
    "Result": 0,
    "OrderLastUpdated": "/Date(1533076111721+1200)/",
    "ErrorDescription": null,
    "OrderExpiryDate": "/Date(1533079711721+1200)/",
    "OrderExpiryDateUtc": "2018-07-31T23:28:31.7214728Z"
}

Automatic expiry extensions

Connect automatically extends an order’s expiry in the following scenarios:

• When the first ticket or concession is added to the order
• When a call is made to ExternalPaymentStarting. This may calculate a longer expiry window (based on configuration) to allow the customer to complete payment
• (OCAPI only) On any call that modifies the order, such as adding a ticket, when the system setting Ocapi_AutomaticallyExtendOrderExpiryTime is enabled.