Errors

CARD_EXPIRED

The card has expired, or the expiry date supplied with it is not a real date. A card is valid through the end of its stated month.

Summary

Field	Value
HTTP status	`422`
`errorCategory`	`validation`
`retryable`	`false`

This code appears in both error vocabularies

CARD_EXPIRED is the only code that is both:

a top-level ProblemDetail.errorCode — the 422 documented here, raised when a card is vaulted or when a stored token is resolved for an order; and
an errors[].code reason on an order, alongside the other decline reasons, when a commerce partner declines the payment for an expired card. In that form it arrives on an HTTP 200 Order with isValid: false and carries no status, category or retryable of its own.

The summary above describes the first form only.

When This Fires

POST /v1/marketfront/payment-methods — the card being vaulted has already expired, or card.expiryMonth / card.expiryYear is not a valid date.
POST /v1/marketfront/orders/place — the card behind the supplied paymentToken was valid when it was vaulted and expired while stored.

The second case is the one worth handling explicitly. A stored card can pass validation on the day it is vaulted and fail months later on an order, with nothing about the request having changed.

Recommended Action

Collect a new card from the customer, vault it, and quote the new token. Nothing about the order needs to change — this is a payment-instrument problem, not a cart or fulfillment problem.

This is not retryable with the same payload.

Example


Code
{
  "type": "https://developer.gett-tech.com/errors/CARD_EXPIRED",
  "title": "Unprocessable Entity",
  "status": 422,
  "detail": "The card behind this paymentToken has expired. Vault a new card and quote the token it returns.",
  "instance": "/v1/marketfront/orders/place",
  "requestId": "req_abc123",
  "timestamp": "2026-09-01T14:30:00.000Z",
  "errorCode": "CARD_EXPIRED",
  "errorCategory": "validation",
  "retryable": false
}

PRECISION_EXCEEDED CARD_LOST_OR_STOLEN

Summary

Field

Value

HTTP status

422

errorCategory

validation

retryable

false

This code appears in both error vocabularies

CARD_EXPIRED is the only code that is both:

a top-level ProblemDetail.errorCode — the 422 documented here, raised when a card is vaulted or when a stored token is resolved for an order; and
an errors[].code reason on an order, alongside the other decline reasons, when a commerce partner declines the payment for an expired card. In that form it arrives on an HTTP 200 Order with isValid: false and carries no status, category or retryable of its own.

The summary above describes the first form only.

When This Fires

POST /v1/marketfront/payment-methods — the card being vaulted has already expired, or card.expiryMonth / card.expiryYear is not a valid date.

POST /v1/marketfront/orders/place — the card behind the supplied paymentToken was valid when it was vaulted and expired while stored.

The second case is the one worth handling explicitly. A stored card can pass validation on the day it is vaulted and fail months later on an order, with nothing about the request having changed.

Example

Code

{
  "type": "https://developer.gett-tech.com/errors/CARD_EXPIRED",
  "title": "Unprocessable Entity",
  "status": 422,
  "detail": "The card behind this paymentToken has expired. Vault a new card and quote the token it returns.",
  "instance": "/v1/marketfront/orders/place",
  "requestId": "req_abc123",
  "timestamp": "2026-09-01T14:30:00.000Z",
  "errorCode": "CARD_EXPIRED",
  "errorCategory": "validation",
  "retryable": false
}