The Axys platform's support ticket system is the canonical channel for any operational issue, platform query, or request that cannot be resolved through the self-service API. This guide covers when to raise a ticket, the ticket lifecycle, and the Account Management endpoints that allow Tenants to build their own support workflows — including surfacing platform support directly within their own cardholder-facing or partner-facing products.

📘
Account Management — production only. The support ticket endpoints described below are part of Account Management and are available exclusively to Tenants with production API keys. They are not part of the publicly documented OpenAPI reference. The data model and lifecycle described here reflect the design of the system; full Account Management operational documentation is provided to production Tenants separately.

When to raise a support ticket

Support tickets cover any operational matter that has no self-service endpoint in the published API. Common reasons include, but are not limited to:

Scenario	Notes
Changing compliance-locked fields on an Approved or Under Review cardholder	Fields such as name, date of birth, address, and nationality cannot be changed via `PUT /cardholders/{id}` once `status = 3` or `1`. A support ticket is the only mechanism — see Onboard a New Cardholder.
Compliance decline requiring manual review	A cardholder declined with `status = 2` may have been flagged by automated checks (biometric mismatch, address/IP discrepancy, etc.) that a manual compliance reviewer can assess and overturn.
Admin decline (`status = 7`)	Platform-side manual decisions require a support ticket for review — this status is not programmatically recoverable.
Closing a cardholder account	There is no published `DELETE /cardholders/{id}` endpoint — account closures are handled via support ticket.
Closing or permanently blocking a card	`PUT /cards/{cardId}/status` can only toggle between Active (`1`) and On Hold (`2`). Permanent card closure is handled via support ticket.
Reporting a lost, stolen, or potentially compromised card	No self-service lost/stolen card replacement endpoint exists. Raise a support ticket to trigger card blocking and replacement.
Suspected fraudulent transaction	Report via support ticket, referencing the `transId` and `cardId`.
PIN reset for a cardholder who has forgotten their PIN	`PUT /cards/{cardId}/pin` requires the `oldPIN` — it cannot be used for a forgotten PIN scenario. PIN reset via alternative identity verification is handled via support ticket.
Following up physical card delivery	No delivery tracking endpoint exists — raise a support ticket with the `cardId` and issuance date.
Card design or Program approval follow-up	Chasing the status of a submitted card design or Program configuration in Account Management.
General integration or technical queries	Questions about API behaviour, undocumented edge cases, or staging anomalies.

Support ticket endpoints (Account Management design)

Creating a new ticket

POST /support/tickets

Field	Required	Type	Notes
`programId`	Yes	integer	The Program to which the ticket relates
`message`	Yes	string	The initial message body
`subject`	No	string	Ticket subject line
`cardholderId`	No	integer	If the ticket relates to a specific cardholder
`cardId`	No	integer	If the ticket relates to a specific card
`priority`	No	integer enum	`1`–`5` per the ITIL Priority Matrix (Urgency × Impact). Defaults to `5` (lowest) if not set — see Priority levels

Response: { "status": "success", "ticketId": "TKT-00123" }

Adding a message to an existing ticket

PUT /support/tickets/{ticketId}

Field	Required	Type	Notes
`message`	Yes	string	New message to append to the ticket conversation
`subject`	No	string	Updated subject (overwrites existing)
`priority`	No	integer enum	Updated priority (overwrites current priority)

Tenants can add messages to a ticket in any status except closed.

Retrieving a ticket

GET /support/tickets/{ticketId}

Returns:

Field	Description
`ticketId`	Unique ticket reference
`status`	`open` · `pending` · `resolved` · `closed` — see Ticket lifecycle
`programId`	Associated Program
`cardholderId`	Associated cardholder (if set)
`cardId`	Associated card (if set)
`priority`	Current priority (`1`–`5`)
`subject`	Current subject
`conversation`	Chronological array of messages — each entry includes `sender`, `timestamp`, and `message`

Ticket lifecycle

stateDiagram-v2
    [*] --> Open: POST /support/tickets\n(Tenant awaiting platform response)
    Open --> Pending: Platform responds\n(Platform awaiting Tenant's reply)
    Pending --> Open: Tenant replies\n(Tenant awaiting next platform response)
    Pending --> Resolved: Platform marks ticket resolved
    Open --> Resolved: Platform marks ticket resolved
    Resolved --> Open: Tenant re-opens within 72 hours\n(sends a new message)
    Resolved --> Closed: 72 hours pass without\nTenant re-opening
    Closed --> [*]

    note right of Closed
        Closed tickets cannot be
        re-opened or replied to.
        Raise a new ticket if the
        issue recurs.
    end note

Status	Meaning	Who acts next
`open`	Ticket submitted — awaiting a response from Axys platform support	Axys
`pending`	Axys has responded — awaiting a reply or further information from the Tenant	Tenant
`resolved`	Axys has marked the ticket as resolved	Tenant (can re-open within 72 hours)
`closed`	Resolved without re-opening for 72 hours — ticket is permanently closed	—

📘
A ticket in resolved status is not automatically closed — the Tenant has a 72-hour window to re-open it by sending a reply message. If the issue recurs after a ticket is closed, raise a new ticket (referencing the original ticketId in the message body for context).

Priority levels

Tickets follow the ITIL Priority Matrix, where priority is a function of Urgency and Impact:

Priority	Level	Examples
`1`	Critical	Platform-wide service disruption; all cardholders unable to transact; data breach suspected
`2`	High	A production Program is entirely unable to process; multiple cardholders affected
`3`	Medium	A significant feature is degraded for a subset of cardholders; compliance processing blocked
`4`	Low	A single cardholder issue; minor UI or reporting discrepancy
`5`	Informational	General query; documentation question; non-urgent follow-up (default if not set)

🚧
Priority can be set or updated at any time via PUT /support/tickets/{ticketId}. A priority of 1 or 2 should be reserved for genuine production-impacting incidents — overuse will reduce the signal value of the priority field and may affect SLA application.

Callback notifications

When Axys responds to a ticket, a callback notification is delivered to the Tenant's registered webhook URL (configured via Account Management). The callback payload contains:

{
  "ticketId": "TKT-00123",
  "status": "pending"
}

On receiving this callback, retrieve the full updated conversation with GET /support/tickets/{ticketId}.

Building a support dashboard

The ticket endpoints are designed to allow Tenants to build support workflows directly into their own products — for example:

White-label client support portal: a Tenant can build a support interface for its white-label clients or Program partners, where partner-raised issues are automatically associated with the relevant programId and routed to Axys platform support on the partner's behalf.
Cardholder issue escalation: a Tenant's front-line cardholder support team can escalate issues (compliance declines, card delivery queries, PIN resets) directly from their internal tooling by posting support tickets with the relevant cardholderId or cardId.
Two-way conversation history: GET /support/tickets/{ticketId} returns the full chronological conversation, making it straightforward to surface the exchange in a Tenant's own CRM or ticketing interface alongside the platform's response.

When to raise a support ticket

Support ticket endpoints (Account Management design)

Creating a new ticket

Adding a message to an existing ticket

Retrieving a ticket

Ticket lifecycle

Priority levels

Callback notifications

Building a support dashboard

What's next