Maintenance and recovery

Keep pending work under control during a change

The bank and deployment operator need an agreed change window, a list of outstanding work and a clear decision on when the service can resume. The bank stops new submissions in its own connected application, while the operator performs the agreed environment changes.

Keep tracking instructions already accepted and preserve incoming outcomes where connectivity permits. Before resuming, verify access and notifications, establish what happened to pending work and reconcile the bank and token records. This procedure does not provide a platform-wide pause or a way to undo a settled payment.

Plan the change with the operator

This procedure describes customer adapter controls and coordination with the deployment operator. It does not introduce a platform-wide pause, transaction cancellation or backup API. Agree the change window, affected components, operational owners, rollback decision, notification route and recovery objectives before starting.

A contract/account status change is a business-resource control, not a general maintenance switch. It does not establish what happens to already accepted work. A token CANCEL instruction concerns an existing lock; it does not cancel arbitrary pending transactions.

1. Stop new work at the bank boundary

Pause new token submissions and provisioning requests in your adapter. Decide how customer requests are queued or refused under your bank's existing service process. Continue to retain incoming outcomes and, while connectivity permits, read pending instructions.

Inventory automations because they can continue independently of your adapter. Coordinate any ACTIVE-to-INACTIVE changes through the automation status endpoint; this is separate from pausing incoming customer requests. A paused automation does not prove that an execution already accepted has stopped.

2. Capture the pending-work inventory

Before the change, record unresolved transaction IDs and original idempotency keys, pending accounts, approval requests/tasks, known lock IDs, automation versions/statuses, webhook configuration and receiver processing checkpoints. Store balances with their asOf timestamps and account/asset references. Balance reads are current snapshots, not a point-in-time export across all accounts.

Identify who will investigate each pending instruction. Keep the webhook receiver available where possible. Making a destination INACTIVE can prevent new fan-out and is not a guaranteed way to retain every event for later replay. Store events durably before acknowledging them.

3. Perform the agreed deployment change

The operator owns infrastructure changes, backups, restore and custody/network configuration under the deployment operating model. The bank owns its adapter release and cash-posting systems. Use approved release artifacts and the agreed rollback procedure. The customer HTTP API does not supply cluster, database or ledger restore operations.

Do not alter signing authority, contract registration or bank references merely to make a delayed operation appear resolved. Record changes affecting the issuer, gateway, network, signing keys and trusted webhook verification configuration.

4. Verify the connection and recover outcomes

1. Confirm gateway and identity-provider connectivity and obtain the appropriate token for the restored environment.
2. Read the expected contract/account resources and compare their identifiers and statuses with the inventory.
3. Test webhook delivery and signature verification; repair receiver configuration before reactivation/replay.
4. Read every unresolved operation by its original transaction ID. Recover a lost submission response with its original key under Idempotency and retries; do not allocate a replacement key for the same uncertain intent.
5. Replay eligible stored webhook deliveries, deduplicate processing and reconcile state reads with the bank journal.
6. Reconcile confirmed movements, balances and known locks with bank records; investigate breaks with the operator.

A restored database or responsive gateway does not prove that in-flight ledger transactions failed. They may have settled while your adapter was unavailable.

5. Authorise resumption

Resume only after the responsible teams review unresolved exceptions, event intake, custody readiness and reconciliation evidence. Restore automations deliberately and check their configured version and trigger. Resume customer submissions gradually within the agreed request budget and monitor the first outcomes.

If connectivity, signing or reconciliation remains uncertain, keep affected submissions paused, follow the agreed rollback/escalation process and repeat the affected checks. Do not conceal pending work by closing its bank journal entry.

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Pause["Pause new adapter submissions"] --> Inventory["Capture pending work and checkpoints"]
    Inventory --> Change["Operator performs agreed change"]
    Change --> Verify["Verify access, resources and event receiver"]
    Verify --> Reconcile["Recover outcomes and reconcile"]
    Reconcile --> Ready{"Recovery accepted?"}
    Ready -->|Yes| Resume["Resume adapter and agreed automations"]
    Ready -->|No| Escalate["Keep affected traffic paused and escalate"]

Worked example

Illustrative request and response from the published contract. Replace identifiers and credentials with those assigned to your environment. This example is not a live test result.

GET /api/transactions/7d1e4c93-2a68-4f51-b0c7-3e95a4d81f26 HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0

HTTP/1.1 200 OK
Content-Type: application/json

{
  "transactionId": "7d1e4c93-2a68-4f51-b0c7-3e95a4d81f26",
  "txType": "MINT",
  "assetId": "GBP",
  "accountRef": "ACC-0001",
  "customerRef": "CUST-0001",
  "counterpartyRef": null,
  "amount": "10.50",
  "params": {},
  "state": "VALIDATED",
  "createdAt": "2026-08-06T09:29:10.285Z",
  "updatedAt": "2026-08-06T09:29:12.041Z"
}

View in API Reference

• Get one token operation · GET

VALIDATED is an intermediate state. Keep this instruction in the recovery inventory and read its later outcome; this response is not permission to repeat the mint with a new key.

Follow a Recipe

Step through the code in JavaScript or Python, inspect illustrative responses, and open the connected endpoint schemas.

• Recover a lost response or delayed outcome

API Reference

Open an endpoint for request fields, response examples and the interactive API console.

Related pages

• Service characteristics
• Daily operations and monitoring
• Idempotency and retries
• Webhooks