Ticket Acceptance Flow
By default, clients using the MTS service should agree with the MTS bet acceptance suggestions to ensure the correctness of liability validations.
This results in the following three main transaction flows:
MTS accepts a bet, and the same bet is accepted on the client's side.
MTS rejects a bet, the same bet is rejected on the client's side.
A bet cancellation request is accepted by MTS, cancellation for the same bet is completed on the client's side, an Acknowledgement message is sent by the client and an Acknowledgement Reply message in sent back from MTS.
A deviation from the expected flows (when the client does not want to process the MTS response as expected) should be treated as an exception and requires a non-acknowledgement message to be sent to MTS.
When a ticket is accepted by MTS but rejected by the client, the non-ack message would be a Cancellation request referring to the ticket in question. Details on Cancellation requests can be found here.
When a ticket is rejected by MTS but accepted by the client, the non-ack message would be an Acknowledgement message of "type": "ticket-ack" and with "acknowledgement": false. Details on Acknowledgement messages can be found here.
Please note that acknowledgement messages are expected to be received in a predefined period to be processed by MTS. (The acceptance period is 10 seconds).
Please get in touch with the MTS Client Integration team if non-acknowledgement messages are required and if the acceptance period is not appropriate.
Ticket acceptance flow (which is depicted in the diagram below) consists of the following steps:
A Ticket placement request is combined into a JSON object and sent to MTS
After the ticket is received, MTS replies with a Ticket placement response. This response includes a suggestion on whether the ticket should be accepted or rejected.
If the client does not receive a Ticket placement response within 3 seconds (pre-match bets) or 16 seconds (live bets), then the client should re-send the bet at least once (see the Ticket acceptance flow diagram below).
MTS can either accept or reject the ticket. Please see the continuation of the flow description below.
Ticket acceptance flow diagram
MTS accepts the ticket
By default, we expect that the client follows the MTS recommendation. In other words, when MTS accepts a ticket, the same ticket should also be accepted by the client. If there is a need to reject a ticket which MTS has accepted, then:
A Cancellation request should be sent to MTS.
If MTS has accepted a Cancellation request, then:
The client cancels the bet.
After the bet is cancelled on the client's side, an appropriate Acknowledgement message should be sent to MTS to confirm that the ticket has been cancelled. MTS will respond with an appropriate Acknowledgement Reply message.
If MTS has rejected a Cancellation request, the client should retain the bet in the accepted status and flag it in the database (as such bets need to be identifiable and the reason for the rejected cancellation could be discussed, i.e. code not active, cancelation of a settled bet, cancelation after the cut off time, etc.).
If the bet still has to be cancelled, the client should contact the MTS Operational Account Manager (OAM): [email protected] The client should keep the bet in accepted status until the OAM manually cancels the bet. After that, to maintain the same ticket status on both sides, the client should change the bet status to cancelled as well.
MTS rejects the ticket
If MTS rejects a ticket, MTS expects that the client will also reject the ticket. If the client still has to accept a bet that MTS has rejected, then the client should send an appropriate non-acknowledgement message to MTS (an Acknowledgment message of "type": "ticket-ack" and with "acknowledgement": false). In the cases when a ticket has been rejected for risk management reasons, MTS may offer (if agreed with the client and configured so) an alternative stake (for live and pre-match bets).
Last updated
Was this helpful?