> For the complete documentation index, see [llms.txt](https://docs.sportradar.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sportradar.com/transaction30api/sandbox/user-manual/cancel_full_accepted.md).

# cancel\_full\_accepted

**Goal:** Send a full ticket cancel and receive an **accepted** cancel reply (sandbox also fills an accepted cancel-ack in the same underlying reply).

Sandbox module name: `cancel_full_accepted`.

## How to build the request (Java SDK)

{% stepper %}
{% step %}

## Build `CancelRequest` with a unique `cancellationId`

{% endstep %}

{% step %}

## Set full ticket cancel details

Use `CancelDetails.newTicketCancelDetailsBuilder()` (JSON type `"ticket"`) for a full cancel, not a partial cancel.
{% endstep %}

{% step %}

## Route the request

Use either:

* **Magic `ticketId`:** `"mock_cancel_accepted"` (preferred for pure Ticket 3.0 / SDK clients; no punter required), or
* **`meta.punter.id`:** `"customer_cancel_accepted"` with any normal `ticketId` (dataplane Transaction).
  {% endstep %}

{% step %}

## Set `ticketSignature`

Ticket 3.0 requires a ticket signature on cancel details.
{% endstep %}

{% step %}

## Send the request

```java
mbsSdk.getTicketProtocol().sendCancel(request)
```

{% endstep %}
{% endstepper %}

`CancelRequest` has no ticket `context` / mobile channel — those apply only when a nested ticket context appears (placement, max-stake, ticket-inform).

## Java example

```java
import com.sportradar.mbs.sdk.entities.cancellation.CancelDetails;
import com.sportradar.mbs.sdk.entities.common.AcceptanceStatus;
import com.sportradar.mbs.sdk.entities.request.CancelRequest;
import com.sportradar.mbs.sdk.entities.response.CancelResponse;

CancelRequest request = CancelRequest.newBuilder()
    .setCancellationId("cncl-1")
    .setDetails(CancelDetails.newTicketCancelDetailsBuilder()
        .setTicketId("mock_cancel_accepted")
        .setTicketSignature("sandbox-signature")
        .build())
    .build();

CancelResponse response = mbsSdk.getTicketProtocol().sendCancel(request);
// expect: response.getStatus() == AcceptanceStatus.ACCEPTED, getCode() == 0
```

Equivalent routing without a magic id: keep any `ticketId` and ensure the sandbox Transaction has `meta.punter.id` = `"customer_cancel_accepted"`.

## Wire JSON (what the SDK sends)

```json
{
  "operatorId": 9985,
  "correlationId": "corr-1",
  "timestampUtc": 1710000000000,
  "operation": "ticket-cancel",
  "version": "3.0",
  "content": {
    "type": "cancel",
    "cancellationId": "cncl-1",
    "details": {
      "type": "ticket",
      "ticketId": "mock_cancel_accepted",
      "ticketSignature": "sandbox-signature"
    }
  }
}
```

| Field name                        | Value                    | Mandatory / Optional | Data type | Ignored by sandbox                |
| --------------------------------- | ------------------------ | -------------------- | --------- | --------------------------------- |
| `operatorId`                      | `9985`                   | Mandatory            | integer   | Yes                               |
| `correlationId`                   | `"corr-1"`               | Mandatory            | string    | No (echoed in reply)              |
| `timestampUtc`                    | `1710000000000`          | Mandatory            | integer   | Yes                               |
| `operation`                       | `"ticket-cancel"`        | Mandatory            | string    | No                                |
| `version`                         | `"3.0"`                  | Mandatory            | string    | No (echoed in reply)              |
| `content.type`                    | `"cancel"`               | Mandatory            | string    | No                                |
| `content.cancellationId`          | `"cncl-1"`               | Mandatory            | string    | No (echoed in reply)              |
| `content.details.type`            | `"ticket"`               | Mandatory            | string    | No (routing: full cancel)         |
| `content.details.ticketId`        | `"mock_cancel_accepted"` | Mandatory (sandbox)  | string    | No (routing via magic id; echoed) |
| `content.details.ticketSignature` | `"sandbox-signature"`    | Mandatory            | string    | Yes                               |

**Ignored by sandbox** means the field is not used for routing and not used when building the reply (schema-only for the WebSocket / Ticket 3.0 envelope). Magic map: `mock_cancel_accepted` → `customer_cancel_accepted`.

## Expected response

On the Java client, assert against `CancelResponse` (`sendCancel`):

| Java getter           | Expected value                  |
| --------------------- | ------------------------------- |
| `getStatus()`         | `AcceptanceStatus.ACCEPTED`     |
| `getCode()`           | `0`                             |
| `getMessage()`        | `"accepted"` (sandbox)          |
| `getCancellationId()` | `"cncl-1"` (echo)               |
| `getTicketId()`       | `"mock_cancel_accepted"` (echo) |

Wire JSON (content type `"cancel-reply"`):

```json
{
  "correlationId": "corr-1",
  "timestampUtc": 1710000001000,
  "operation": "ticket-cancel",
  "version": "3.0",
  "content": {
    "type": "cancel-reply",
    "cancellationId": "cncl-1",
    "ticketId": "mock_cancel_accepted",
    "status": "accepted",
    "code": 0,
    "message": "accepted",
    "signature": "sandbox-signature"
  }
}
```

{% hint style="info" %}
The sandbox also fills an **accepted cancel-ack** (same `cancellationId` / `ticketId` / message) in the same internal reply. `sendCancel` surfaces the cancel-reply as `CancelResponse`.

Assert on `getStatus()`, `getCode()`, and `getMessage()`.
{% endhint %}

## Common mistakes

| Mistake                                                                               | Result                                                                                                                                          |
| ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Wrong / missing magic `ticketId` and no `meta.punter.id` = `customer_cancel_accepted` | Fallback rejection (`-999`)                                                                                                                     |
| Using `newTicketPartialCancelDetailsBuilder()`                                        | Routes to partial-cancel scenarios (or fallback)                                                                                                |
| Expecting reject `-2013`                                                              | That is [`cancel_full_rejected`](broken://pages/f20813d886ee30299880aca75bac1de68edf9013) (`mock_cancel_rejected` / `customer_cancel_rejected`) |

See also: [Error responses](broken://pages/3cdf760ce49fd6992d47d7772f4a4b9f67f0519f#error-responses) in the parent manual.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.sportradar.com/transaction30api/sandbox/user-manual/cancel_full_accepted.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.