Integration flow

Preconditions

• Commercials are agreed

• Operator or platform provider is ready to start technical integration

Having integrated Unified Odds Feed is not a precondition to start MTS Integration. MTS Integration and UOF integration can be completed in parallel.

Step by step explanation:

1. The first interaction between an MTS client and the MTS service delivery team commences during the MTS kick-off call. This call is arranged by the relevant Betradar sales person after commercial details are agreed. Participants for the kick-off call should be the operator's representatives, representatives from the platform provider, MTS service delivery and MTS operational account manager (OAM) representatives. The following will be discussed during this call:

   1. The MTS integration flow;

   2. Date for starting integration and planned launch date. Please note resources are planned within the MTS client integration (CI) team based on these dates;

   3. Scheduling of the initial technical call with developers from the MTS client side and MTS CI engineers.

2. After the kick-off call the MTS service delivery manager:

   1. Creates a dedicated Skype or Slack channel which is used for communication with the MTS client integration team during the integration phase with MTS;

   2. Sends the latest version of the MTS ticket integration document and AMQP ticket feed documentation on the client;

   3. Sends MTS client questionnaires to the client;

   4. Introduces the client to the Betradar partner certification team. This team is responsible for UOF certification. Feed certification is one of the prerequisites for the launch of the MTS service.

3. Technical client integration starts from an initial Skype or Slack conference call. Participants of this call are the MTS CI team and a technical representative(s) from the client side. The following will be discussed during this call:

   1. Integration flow

   2. Ticket acceptance flow which is mentioned in THIS section

   3. Benefits of using MTS Java or .Net SDK

      - In case the MTS SDK cannot be used, AMQP communication concept between the client’s platform and MTS

   4. Possibility of sending production tickets to the MTS CI environment without following MTS suggestions/replies for testing purposes

   5. Frequently asked questions for integration or launch

Note

The client needs to implement their own validation system and shouldn't rely on MTS for validation. This is because MTS is primarily a risk management tool. In the rare cases where MTS is down, the client should be able to conduct their own validation, so that they don't lose ticket traffic during downtime. The following parameters fall under validation check for a ticket:

• ticket odds,

• markets (status),

• outcomes,

• specifiers

1. After the MTS CI lead receives a completed technical questionnaire and the client's public GPG certificate (OpenPGP format) from the client, the Client configuration on the MTS CI phase starts with:

   1. Client's bookmaker account (BMID) is subscribed to managed trading services

   2. Client's IPs are added to MTS CI environment whitelist (Note: Any additional white-listing IP requests have to be sent to MTS CI via email to [email protected])

   3. MTS CI team sets up RabbitMQ for the client's ticket feed to the MTS CI environment

   4. Appropriate limitID's are created on the MTS CI environment

Note

It might happen that several Limit IDs will be created for the same client. E.g. separate Limit IDs for different distribution channels. This fact must be taken into account during development.

1. Credentials encrypted with GPG are sent to the pre-agreed recipient. More about GPG encryption can be found here: https://www.gnupg.org/gph/en/manual/x110.html or http://www.gpg4win.org/

Note

In case of credentials being lost, they cannot be restored. If credentials are lost, new credentials will be created

1. After the client receives AMQP credentials and limitID's the client integrates the ticket feed to MTS with support from MTS CI team in a dedicated Skype chat. This phase is called Technical integration

2. In parallel to the ticket feed implementation, the MTS OAM manager is:

   1. Discussing risk limits setup and ticket cancellation configuration for the MTS production environment:

      1. Minimum stake limit

      2. Maximum stake limit

      3. Maximum payout limit

      4. Maximum liability limit

      5. Live and pre-match bet factors

      6. Live time delays

      7. Bet cancellation types

      8. Acknowledgement period

   2. Arranging Betradar Ctrl training. This training is regarding Betradar feeds configuration from a business and operational perspective (e.g., odds key/configuration)

Note

The prerequisite is the completion of the MTS client questionnaire by the client.

1. In parallel to the MTS CI and OAM activities, the Betradar Partner Certification team is performing the UOF certification on the client's platform

2. After the client has completed the MTS ticket feed implementation, an end-to-end test is performed by the MTS CI team, which includes:

   1. Placing bets on the client's sportsbook solution and verifying ticket JSON objects on the MTS side

   2. Verification of reaction on bet acceptance suggestion (bet accepted and rejected)

   3. Verification of the quality of UOF integration (if the client can send production tickets to the MTS CI environment)

Note

Issues found during the test will require correction by the client or provision of an estimated time for issue resolution.

Note

It is recommended to complete the feed (UOF) sportsbook test before the start of the MTS end-to-end testing. In exceptional circumstances, MTS E2E testing may start before the UOF sportsbook test if the testing slot has already been scheduled, but still needs to be done before the launch to production.

1. After successful completion of the end-to-end testing, launch preparation phase starts which includes:

   1. Review of MTS end-to-end test results by MTS service delivery manager

   2. Review of UOF certification results by Betradar partner certification team and MTS service delivery managers

   3. Contract finalization by MTS business development manager, assistant and Sportradar legal department

   4. Verification of Risk management limits

   5. Verification of UOF configuration by MTS OAM

   6. Client is configured on MTS production environment

2. With MTS end-to-end testing, UOF certification completed and a signed MTS contract, launch date is agreed upon with client and MTS service delivery manager

3. The launch confirmation email is followed by MTS production credentials encrypted with GPG

4. After agreed date and time MTS CI team assists operator to switch sportsbook to MTS production

5. For the first 48 hours after launch MTS CI supports and monitors the client directly. After 48 hours, client support is handed over to the Sportradar support team. Any issues should then be addressed directly to Sportradar support

Note

By default, all tickets coming to MTS production are assumed as genuine production tickets and will be invoiced accordingly. All testing, demos and training for any employee must be carried out via the MTS CI environment.