Migration to Transaction 3.0
AMQP is no longer our primary protocol
AMQP has no longer been the primary protocol for interfacing with MTS since November 2024, when the initial notification was sent to clients. It has been replaced by the WebSocket protocol, which is more secure, performant, and easier to use. This protocol is already being used successfully by a large portion of our clients.
As part of our continued focus on security and modernization, official support for the legacy AMQP protocol (RabbitMQ-based) will be phased out by December 31, 2025. This decision is driven by the protocol's approaching end of life and associated security implications.
What this means for you
Starting in 2026, MTS will only provide limited support for AMQP over RabbitMQ.
Reduced SLAs, as we are no longer able to maintain the same level of system resilience and security in the legacy ingress stack.
We strongly recommend prioritizing the migration activities to a newer, ticket-based protocol as soon as possible. Please contact your OAM or Sales for more information or to plan/start integration activities.
What is the new ticket version?
Transaction 3.0 is an upgraded version of Ticket 2.X as it provides a concise, precise, and above all, extendable ticket format. It addresses the growing need for bookmakers to differentiate their offer and attract a larger customer base.
The minimal amount of information needed to place a ticket is: ticket ID, client information (which limits to take into account, punter data, etc.), and a list of bets. Bet potentially contains ID, validation flags, and size, but the most important fields are selections and stake, which are mandatory and define the bet.
Changing the stake field into a list provides the ability to uniformly handle various types of stakes (and combinations of them). Each stake type (given final/effective odds from the selections) must allow to calculate an amount and type of payout(s). The most common stake type is cash, others include free, free-cash, and bonus. In time, additional types (e.g., free-bonus, bonus-percentage, etc.) and/or attributes (e.g., managed, marketing campaign ID, suggestion ID, promo code, etc.) could be added.
The main purpose of selections is to eventually (e.g., after settlement, etc.) provide effective odds which are then used to calculate the payout. 2 pieces of information must be provided:
To which outcome in a feed is it bound, and how the result is applied when available
If multiple outcomes are combined, how they combine
As with stake, additional types and/or attributes (e.g., managed, marketing campaign ID, suggestion ID, promo code, etc.) can be added.
Example of ticket 3.x: Double Prematch Bet
{
  "operatorId": 9985,
  "content": {
    "type": "ticket",
    "ticketId": "Ticket_3668",
    "bets": [
      {
        "selections": [
          {
            "type": "uf",
            "productId": "3",
            "eventId": "sr:season:54837",
            "marketId": "534",
            "outcomeId": "pre:outcometext:9826",
            "specifiers": "variant=pre:markettext:62723",
            "odds": {
              "type": "decimal",
              "value": "1.36"
            }
          },
          {
            "type": "uf",
            "productId": "3",
            "eventId": "sr:match:14950205",
            "marketId": "14",
            "outcomeId": "1712",
            "specifiers": "hcp=1:0",
            "odds": {
              "type": "decimal",
              "value": "1.59"
            }
          }
        ],
        "stake": [
          {
            "type": "cash",
            "currency": "mBTC",
            "amount": "10"
          }
        ]
      }
    ],
    "context": {
      "channel": {
        "type": "internet",
        "ip": "212.9.11.2",
        "lang": "EN"
      },
      "endCustomer": {
        "id": "endCustomer_384d54"
      },
      "limitId": 1409
    }
  },
  "correlationId": "89Wekr38267",
  "timestampUtc": 1678883012000,
  "operation": "ticket-placement",
  "version": "3.0"
}
Example of ticket 2.4: Double Prematch Bet
{
    "timestampUtc": 1545044012850,
    "bets": [{
        "stake": {
            "value": 10000,
            "type": "total"
        },
        "id": "Ticket_3668_0",
        "selectedSystems": [2]
    }],
    "ticketId": "Ticket_3668",
    "selections": [{
        "eventId": "sr:season:54837",
        "id": "uof:3/sr:sport:4/534/pre:outcometext:9826?variant=pre:markettext:62723",
        "odds": 13600
    }, {
        "eventId": "sr:match:14950205",
        "id": "uof:3/sr:sport:1/14/1712?hcp=1:0",
        "odds": 40000
    }],
    "sender": {
        "currency": "mBTC",
        "channel": "internet",
        "bookmakerId": 9985,
        "endCustomer": {
            "ip": "127.0.0.1",
            "languageId": "EN",
            "id": "endCustomer_384d54"
        },
        "limitId": 1409
    },
    "version": "2.4"
}
Why is the ticket version 3.X better than 2.X?
The new ticket version - Transaction 3.0 is more understandable and comprehensive, and at the same time more compact. One of its main advantages is extendibility, meaning that it makes it easy to add new features and tailor it to the clients' needs.
Since the betting market is growing and bookmakers work hard to differentiate their offerings to attract a larger customer base, there is a need to facilitate advanced player management (custom content, player segmentation, lifetime value...), advanced offer management (sharper odds, custom offer, multiple feed support...), advanced ticket/bet management (advanced bet type, advanced settlement options, edit ticket/bet options), advanced risk management risk exposure limiting, advanced contingency detection, risk analysis, and simulation...) and advanced integration (import/export functionality, integration with other providers, integration with other systems).
New Transaction 3.0 benefits:
Advanced odds types: Malaysian Odds, Fractional, American, Lay (upcoming)
Increased odds precision: Up to 8 decimal places for Accounting-level precision
3rd party content support: Support for Risk Management, API services, Cashout on 3rd party provided content
Control of odds per bet: Fine-tuned control over betting odds.
PayCap per bet: Structure payouts with PayCaps.
Currency per bet: Flexibility to use different currencies for bets.
Multiple Custom Bets support: Combine multiple Custom Bets into accumulators or system bets.
Varied payout types: Options for cash out, free bets, and bonuses.
Why do I need to migrate my current solution?
Since September 1, 2023, WebSockets and Transaction 3.0 have become the new technological standards for MTS, replacing the AMQP communication protocol and the 2.X ticket format. As of November 1, 2024, all new features will be available in 3.0 and WebSockets only.
The new protocol allows all current and future transactions to be sent within the same channel. Additionally, the new ticket format enables further customization of betting operations and facilitates new functionalities, such as Player Profiling APIs, Live Time Delay APIs, and Cashout API.
Starting in 2026, MTS will offer limited support for AMQP over RabbitMQ.
Reduced SLA as we are no longer able to maintain the same level of system resilience and security in the legacy ingress stack
Is the new technology stable?
Yes, our models are powered by the latest AI and machine-learning technology, making them unrivaled in scale, depth, and speed when interrogating and interpreting vast sports databases. Our industry-leading betting and sports database is the largest in the world, ensuring that our models deliver unparalleled insights that can't be found anywhere else.
Active implementation of the models with existing MTS customers has proven their effectiveness across all areas, resulting in increased margins and reduced risks and volatility. With our extensive data set and industry expertise, we provide unparalleled insights and solutions to help our clients stay ahead of the competition.
How can I start the migration?
To ensure a smooth migration, please contact your dedicated Operational Account Manager or Sales representative to request an integration account and assistance. We have developed new SDKs (Java, .NET) to make the transition seamless. Our experienced Integration Managers will guide you through to completion and test your solution for a perfect launch.
Please note: We strongly recommend that you plan your migration activities early.
Process step-by-step explanation:
As an existing MTS client, you are already familiar with our integration process and have been benefiting from our AI model outputs in risk management operations.
The first step in the integration process begins with the kick-off call, scheduled by the Sportradar salesperson once the commercial details are finalized. In the kick-off call, topics such as integration flow, start date of the integration, and planned launch date will be discussed.
The technical call is the first step in the technical client integration process. This call involves the Client Integration (CI) team and technical representatives from the client’s side. This is an opportunity to discuss the integration flow, transaction format, and transaction ingress flow through the WebSocket protocol.
After the CI lead receives the client's public GPG certificate (OpenPGP format), the Client Configuration phase on the CI environment begins with subscribing the client's bookmaker account (BMID).
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.htmlor http://www.gpg4win.org/
After the client receives credentials (client_id and client_secret), bookmaker and limit IDs, the client proceeds with the technical integration phase. This phase involves integrating the ticket feed with the support of the CI team. The integration process takes place in a dedicated Slack or Teams channel specifically set up for the integration purpose.
After the client has completed the ticket feed integration, an end-to-end test is performed by the CI team, which includes placing bets on the client's sportsbook solution and verifying ticket JSON objects.
Note: Any issues found during the test will require correction by the client or the provision of an estimated time for issue resolution.
Insight Tech Services API integration can also be done in parallel with the ticket feed setup. Using the same credentials received in the ticket feed setup phase (client_id and client_secret), the client proceeds with the technical integration of the Insight Tech Services API. In this phase, after reviewing the documentation, the client selects which API endpoints they wish to use in their systems and starts with the integration with the support of the CI team. The integration process takes place in dedicated Slack or Teams channels specifically set up for the integration purpose.
The client also provides the list of users to whom they wish to grant access for the Insight Tech Services user interface. Clients can opt to leave the API integration into their own systems for the later stages if they determine that the user interface satisfies their current needs. In any case, Insight Tech Services UI can be used to validate that the received API responses reflect the actual state in Insight Tech Services databases.
After the successful completion of end-to-end testing, the launch (deployment) preparation phase starts. Note: By default, all tickets coming to the production environment are assumed to be genuine production tickets and will be invoiced accordingly. All testing, demos, and training must be conducted via the CI environment.
How long will it take and what do I have to consider for planning?
On average, the migration process takes around 10 weeks.
It is important to consider that any issues found during the testing phase will require correction by the client, so additional time should be estimated for resolving these issues.
Do I really need to use an SDK?
In case clients are using a Java or .NET backend, it is recommended to use the MBS SDK (Software Development Kit)
Can I go to production without any testing?
In the end-to-end testing phase of the integration process, the CI team will perform actions such as placing bets on the client's sportsbook solution and verifying ticket JSON objects. This is one of the most vital steps in the integration process as it ensures that the responses reflect the actual state of the databases. This step is required for both new and existing clients.
How do I save time doing the migration from 2.X to 3.X?
Plan migration activities ahead
Use one of our SDKs
Last updated
Was this helpful?