Sign in

v1

latestOpenAPI 3.0.32026-07-248079274.0 KB
Account Updater

Create an Account Updater request for a card

Manually create an Account Updater request for a stored card, asking the scheme to refresh the credentials held for it. This is an alternative to Acquired.com's automatic Account Updater processes (rebill decline, retry advice and the monthly expiry sweep).

The request body is empty - the card is identified by card_id in the path. When the Mid header is omitted, the Mid is resolved automatically: the card's originating Mid if it is Account Updater capable, otherwise your company's first Account Updater capable Mid.

The request flows through the same send → scheme response → processing pipeline as automatically triggered requests. Use the list endpoint to track its status and outcome.

A card can only have one pending request at a time: if one already exists, it is returned with a 200 response instead of creating a new one.

post/cards/{card_id}/account-updater

Path parameters

card_idstring uuid required

Unique ID assigned by Acquired.com for the card.

Headers

Company-Idstring uuid

Unique ID assigned by Acquired.com for your company.

Midstring uuid

Unique ID assigned by Acquired.com connecting to a specific acquiring bank.

Response

OK - a pending Account Updater request already exists for this card and is returned unchanged.

idstring uuid

Unique ID assigned by Acquired.com for the Account Updater request.

card_idstring uuid

The stored card the request relates to.

customer_idstring uuid

The customer the card belongs to.

mid_idstring uuid

The Mid the request was submitted under.

initiated_by'manual' | 'decline' | 'retry_advice' | 'card_expiry' nullable

What created the request. manual indicates a manual request made through this API; the other values are set by Acquired.com's automatic Account Updater processes. May be null for some older requests, where the source was not recorded.

status'pending' | 'submitted' | 'completed' | 'failed'

The lifecycle state of the request.

  • pending - created and waiting to be sent to the scheme.
  • submitted - sent to the scheme, awaiting a response.
  • completed - the scheme returned a result.
  • failed - the scheme could not process the request.
outcome'card_updated' | 'card_expiry_updated' | 'no_change' | 'account_closed' | 'card_not_found' | 'provider_error' | 'unknown' nullable

The result of the request once it completes. null until the request reaches a terminal state.

  • card_updated - the card number (and usually expiry) changed.
  • card_expiry_updated - only the expiry date changed.
  • no_change - the card is still valid with no changes.
  • account_closed - the cardholder should be contacted (e.g. the account is closed).
  • card_not_found - the scheme did not recognise the card.
  • provider_error - the scheme could not process the request.
  • unknown - the result could not be determined. Shown for some older requests, for which the outcome and outcome_detail are not available.
created_datetimestring date-time

When the request was created.

submitted_datetimestring date-time nullable

When the request was sent to the scheme. null while the request is still pending.

completed_datetimestring date-time nullable

When the scheme response was received. null until the request is completed or failed.

Example response

{
  "id": "0190f9bd-2c4f-7000-9000-aabbccddeeff",
  "card_id": "a7e3fde5-5b83-44f4-9915-782bc7121717",
  "customer_id": "b1d4e0f2-7c3a-4e5b-9f6d-1a2b3c4d5e6f",
  "mid_id": "c2e5f1a3-8d4b-4f6c-a07e-2b3c4d5e6f70",
  "initiated_by": "manual",
  "status": "completed",
  "outcome": "card_updated",
  "outcome_detail": {
    "previous_bin": "492181",
    "previous_last4": "1234",
    "previous_expiry_month": 1,
    "previous_expiry_year": 26,
    "new_bin": "550000",
    "new_last4": "5678",
    "new_expiry_month": 4,
    "new_expiry_year": 31
  },
  "created_datetime": "2026-06-20T10:00:00Z",
  "submitted_datetime": "2026-06-20T10:05:00Z",
  "completed_datetime": "2026-06-21T02:45:00Z"
}