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
resolvedstatus 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 isclosed, raise a new ticket (referencing the originalticketIdin 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 of1or2should 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
programIdand 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
cardholderIdorcardId. - 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.