Support, SLAs and status
How WalletD support reaches a partner's data only with a recorded approval, the default severity targets, the escalation path, and where incidents are published.
Our staff cannot see your data without your recorded approval
This is the part of the support model that is enforced in code rather than promised in a contract, so it is worth stating precisely.
A WalletD support engineer signs in with a vendor-support identity. That identity has no standing access to your data. Every request it makes against your deployment is refused with 403 support_access_required until an administrator on your side has created a grant. There is exactly one exception: an engineer may ask whether they currently hold a grant, so the console can show "waiting for your approval" instead of an error page.
A grant is created by your administrator, from your operator console, and carries:
| Field | Rule |
|---|---|
| The engineer | Named individually. A grant authorises one person, not a role or a team |
ticket_reference | Required, up to 128 characters. There is no grant without a ticket |
reason | Required, up to 1000 characters, stated in free text |
expires_at | Required, in the future, and at most 24 hours from creation |
The 24 hour ceiling is checked in the service and again as a database constraint, so no configuration, no operator and no code path can extend a grant beyond a day. A longer engagement is a new grant against a new decision, which is the point.
One live grant per engineer. A second grant for someone who already holds one is refused with 409 support_access_already_active, so access cannot be quietly stacked or extended by re-approval.
Read-only. A vendor-support principal is minted with reading scopes and nothing else: users, balances, payments, merchants, rewards, subscriptions, top-ups, webhooks, the ledger and the audit log. There is no write scope to hold, so there is no configuration in which a support engineer moves your money, changes a limit or edits a record.
Every request is recorded against the grant. While a grant stands, each request the engineer makes writes an access-log row naming the exact approval that authorised it, including requests that the scope check then refuses. If that record cannot be written, the request is refused. Access does not proceed without an access record, which is the difference between an audit trail and an audit trail that is missing the interesting minute.
Revocation is immediate, and the evidence outlives the grant. Your administrator can end a grant at any moment; the engineer's next request is refused. Expired and revoked grants stay in the history, and so does everything recorded under them. The access log and the audit log are append-only: a database trigger refuses UPDATE and DELETE on both, and the audit log is additionally hash-chained per tenant so a rewrite that bypassed the trigger is still detectable.
This mechanism governs WalletD's staff. Your own support team's authority comes from their standing role in your tenant and is not affected by any of it, which is why nothing here should be read as a restriction on your first-line operations. Grant management lives in the operator console and is marked internal in the API description; it is not part of the integration surface you build against.
More broadly: no production PII, identity document, secret or ledger entry is copied into a central WalletD system by default. Remote support works inside your deployment, through your identity boundary. Emergency access uses the same grant mechanism. There is no standing bypass account.
Severity and response targets
These are WalletD's defaults unless your agreement says otherwise. Your order form names your SLA tier and its coverage, and where the two disagree the agreement governs.
| Severity | Definition | Acknowledge | Update cadence | Coverage |
|---|---|---|---|---|
| S1 | Money at risk or the API unavailable for the partner | 30 min | hourly | 24×7 |
| S2 | A money path degraded, workaround exists | 2 h | every 4 h | 24×7 |
| S3 | Non-money defect, integration blocked | 1 business day | daily | business hours |
| S4 | Question, documentation, enhancement | 2 business days | on change | business hours |
"Acknowledge" means a human has read the ticket, assigned a severity and told you what it is. It does not mean a fix or a root cause. "Update cadence" is the rhythm you can expect until the severity drops or the incident closes, whether or not there is news, because silence during an incident is itself a failure mode.
Severity is assigned by impact, not by feeling. A 429 on a batch job you can reschedule is not an S1. A payment path returning refusals for live customers is, even if the dashboard is green. If we disagree with your assessment we will say so in the acknowledgement rather than silently downgrade it.
A security vulnerability report is triaged on this same model. See Security for integrators for where to send one.
Escalation
- Support takes the ticket, assigns the severity and owns the updates.
- Engineering on-call is engaged for anything S1 or S2, and for an S3 that turns out to be a defect rather than an integration question.
- The founder is the final escalation, for a target missed, a severity disputed, or a commercial decision the support path cannot make.
Escalating is a request you make on the ticket, not a separate address. Raising the same issue through a second channel splits the history and slows it down.
Incident communication
Two different things are published in two different places, because they have two different audiences.
Shared services, meaning this documentation site, the identity endpoints, the public sites and the demo environment, are on the public status page:
Your own deployment is not on the public status page. It runs on your infrastructure, under your operations, and its health is not ours to publish. Incidents affecting it are communicated on the channel named in your agreement, on the cadence in the table above. If your deployment appears on the status page at all, it is as a private component group visible only to you.
The distinction matters during an incident: a green public status page says nothing about your deployment, and a red one does not necessarily mean your deployment is affected. Check the channel, not the page.
Next
- Security for integrators for credentials, signing, retention and vulnerability reporting.
- Architecture overview for what a deployment contains and who operates it.
- Errors before raising a ticket about a refusal. Most refusals are documented, deliberate and answered faster by the code table than by us.