Skip to main content
DELETE

Delete Tokens Guide

Permanently remove tokens from the system
Deleting a token is permanent and cannot be undone.
Permanently deletes a token and all associated card data from PCI Booking. Use this to remove cards that are no longer needed, such as expired reservations or cancelled bookings, to stop incurring monthly storage fees.

Error Responses

Error detail

Each condition below gives the exact moreInfo text, why it happens and how to resolve it. The full set is on the Error Handling page.
HTTP status: 404message: Uri not foundmoreInfo:
Reason. The token is well formed but no card is stored against it. Either it never existed, or it was deleted. Deletion is permanent and cannot be undone.How to resolve.
  1. Confirm the tokenization call that should have created it returned success and returned this exact token.
  2. Check whether the token was deleted, either explicitly or by a CVV retention policy configured to delete the card on cleanup.
  3. Check the environment. A token from one environment is not visible in the other.
Some endpoints report a deleted token as -1003 rather than -160. Treat the two as the same investigation and start with whether the token still exists.
HTTP status: 401message: You are not authorized to access this resource. Please contact customer support.moreInfo: one of the following, depending on which check failed:
Reason. The credential authenticated fine, but it is not allowed to act on the token in the request. The generic wording makes this the single most misread error in the API. On a token call it is far more often one of the causes below than an actual permissions problem.How to resolve.
  1. Check the token was not deleted. This is the most common cause. Deletion is permanent, and every later call on that token returns -1003 rather than a not-found error. Support can confirm when and by which user a token was deleted.
  2. Check the tokenization actually succeeded. If the call that should have created the token failed, the token never existed, and the first call that uses it reports -1003.
  3. Check the environment. A sandbox token cannot be used from production, or the reverse.
  4. Check ownership and association. See the rules below.
Ownership and association.A token is owned by the account that created it. Another account can use the token only if the token was explicitly associated with it:
  • At tokenization, by passing merchantId on the tokenizing call.
  • After tokenization, by associating the token with the merchant.
Two rules catch people out:
  • An association can only target a primary account. If you pass the ID of a sub-user or a secondary property, the request is rejected and you must associate the token with the parent account instead.
  • Tokens never cross environments. A token created in sandbox cannot be used from production, and the reverse is also true.
Account level blocks.An account that has exceeded its processing allowance is blocked, and every billable API call from it then fails with -1003 even though the credentials are still valid and can still sign in to the portal. The response carries no moreInfo explaining this, so it is indistinguishable from a permissions failure by looking at the response alone.This is a common cause on sandbox accounts, which have a lower allowance than production.Check for it when -1003 appears suddenly across calls that used to work, on more than one token. A block affects every billable call on the account at once, whereas a genuine ownership problem affects only the specific token. Contact support with your account name to have the allowance reviewed and the block lifted.

Parameters

Headers

string
required
Your API key prefixed with APIKEY. Example: APIKEY your-api-key. See the Authentication guide.

Path Parameters

string
required
The token ID as returned by one of the tokenization methods. For example, 2821a46d80e14d1b96a7f18f1b81926d.

Response

200 - Token deleted. Empty response body.