Stop a device from approving future payments

Use this operation when a customer no longer wants a registered device to approve payments from their bank account. The bank disables the device-account relationship created during setup. This operation does not move money or reverse a completed payment; it only stops the device from being used for future Debit Authorization requests.

Before you begin

The customer must have completed device credential provisioning.
Use the deviceCredentialProvisionId returned by the bank after successful setup. It identifies the device-account relationship to disable.
Do not use the short-lived customer consent token. That token was used only to create the relationship and must not be reused.

Request

Blinc sends an encrypted POST request to /device-credential-unprovisioning. The request uses the security headers described in Set up security and keys and identifies the device-account relationship with deviceCredentialProvisionId.

The request and response follow the approved device-credential unprovisioning contract agreed during bank onboarding. Do not use the old account-linking request or send a consent token for this operation.

Request body

After the bank decrypts the request, the business payload contains the identifier of the device-account relationship to disable:

{
  "clientReference": "1f2e3d4c-5b6a-7980-1234-56789abcdef0",
  "deviceCredentialProvisionId": "7f2c1a9e-3b44-4d21-9c66-0a1b2c3d4e5f",
  "reasonCode": "CUSTOMER_REQUEST",
  "reason": "Customer changed phones"
}

Property	Why it is needed
`clientReference`	Gives Blinc and the bank a reference for this unprovisioning request and its outcome. It must be a UUID.
`deviceCredentialProvisionId`	Identifies the existing device-account relationship created during provisioning. The bank uses it to find the relationship that must be disabled. It is not the customer's consent token.
`reasonCode`	States why the customer wants the device-account relationship disabled. The bank and Blinc agree the supported reason codes during onboarding.
`reason`	Gives the bank a human-readable explanation of the customer's reason.

What happens at the bank

Check the security headers and decrypt the request.
Verify that the request signature is valid and that the request is recent.
Find the device-account relationship identified by deviceCredentialProvisionId.
Confirm that the relationship belongs to the relevant institution and may be disabled.
Disable the relationship once. Do not create a new relationship and do not change any completed payment.
Return the approved protected response explaining whether the device was successfully disabled or why the request could not be completed.

Response from the bank

A successful response confirms that the device can no longer approve payments from the account. A rejected response explains why the relationship was not changed. The response uses the status and reference fields defined in the approved unprovisioning contract so Blinc can show the customer what happened.

Successful response

{
  "clientReference": "1f2e3d4c-5b6a-7980-1234-56789abcdef0",
  "deviceCredentialProvisionId": "7f2c1a9e-3b44-4d21-9c66-0a1b2c3d4e5f",
  "status": "unprovisioned",
  "reasonCode": null,
  "reason": null,
  "unprovisioningTimestamp": "2026-09-17T12:00:00Z"
}

Rejected response

{
  "clientReference": "1f2e3d4c-5b6a-7980-1234-56789abcdef0",
  "deviceCredentialProvisionId": "7f2c1a9e-3b44-4d21-9c66-0a1b2c3d4e5f",
  "status": "rejected",
  "reasonCode": "MD01",
  "reason": "The device credential was not found.",
  "unprovisioningTimestamp": "2026-09-17T12:00:00Z"
}

Property	Why it is needed
`deviceCredentialProvisionId`	Tells Blinc which device-account relationship the bank evaluated.
`status`	States the result of the request. `unprovisioned` means the relationship was disabled; `rejected` means it was left unchanged.
`reasonCode`	Identifies why the bank rejected the request. It is empty on a successful response.
`reason`	Explains in plain language why the bank rejected the request. It is empty on a successful response.
`unprovisioningTimestamp`	Records when the bank produced the response, using a UTC timestamp.

When the request fails or times out

The bank rejects the request when the identifier is missing, unknown, belongs to another institution, or cannot be disabled. It also rejects an invalid or unauthorised request before changing the relationship.

If the response is lost, do not assume that the device was disabled and do not create a new device-account relationship. Follow the agreed status-check or retry procedure so the relationship is not changed twice.

What happens next

After successful unprovisioning, the customer must complete device credential provisioning again before that device can approve payments from the account. A completed payment is unaffected; use Reversal when money from an accepted Debit Authorization must be returned.