Card Validation

Use a nexo Card Validity Check, also known as a Card Account Status Check, to verify that a card account is available for use without authorizing or capturing a financial amount.

The check is sent online to the acquiring route. It can use chip data, magnetic-stripe data, or manually entered card data. An approved check confirms the result only at the time it is performed; it does not reserve funds, guarantee approval of a later payment, or authenticate the person presenting the card.

Message flow

The examples in this guide use nexo version 6.

Use the nexo version and security profile agreed for the integration. The card-validation fields do not replace the standard header, merchant, payment-device, card, context, or message-security fields required by that profile.

Request fields

Set the following values in the Acceptor Authorisation Request:

m = mandatory, c = conditional

Do not include a cashback amount, supplementary amount, tip, or other non-zero amount. A Card Validity Check with a non-zero total amount is rejected.

Card data and entry mode

Supply card and payment-context data that accurately represents how the card was read:

• for a chip transaction, send the required chip and EMV data;
• for a magnetic-stripe transaction, send the required track data; or
• for a manually entered transaction, use the manual-entry context and protected card-data fields required by the merchant profile.

Do not label one entry method as another to bypass terminal, cardholder-verification, or acquiring controls. The exact card-data and cardholder-verification requirements depend on the certified terminal profile and acquiring route.

Request example

The following example shows the card-validation-specific structure of a caaa.001.001.06 request. Replace the placeholders and abbreviated blocks with the values required by the integration. nexo XML is order-sensitive.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:caaa.001.001.06">
  <AccptrAuthstnReq>
    <Hdr>
      <MsgFctn>AUTQ</MsgFctn>
      <PrtcolVrsn>6.0</PrtcolVrsn>
      <!-- Other required header fields -->
    </Hdr>
    <AuthstnReq>
      <Envt>
        <!-- Acquirer, merchant, POI, and protected card data -->
      </Envt>
      <Cntxt>
        <!-- Payment context matching the actual card-entry method -->
      </Cntxt>
      <Tx>
        <TxCaptr>false</TxCaptr>
        <TxTp>VALC</TxTp>
        <MrchntCtgyCd>5999</MrchntCtgyCd>
        <TxId>
          <TxDtTm>2026-08-26T10:15:30+02:00</TxDtTm>
          <TxRef>VAL-000001</TxRef>
        </TxId>
        <TxDtls>
          <Ccy>EUR</Ccy>
          <TtlAmt>0.00</TtlAmt>
        </TxDtls>
      </Tx>
    </AuthstnReq>
  </AccptrAuthstnReq>
</Document>

The merchant category code, currency, transaction reference, and timestamp above are illustrative. Use the values applicable to the merchant and target environment.

Card validation with token provisioning

To request a token while the card is being validated, add /request/token after TxDtls:

<Tx>
  <TxCaptr>false</TxCaptr>
  <TxTp>VALC</TxTp>
  <MrchntCtgyCd>5999</MrchntCtgyCd>
  <TxId>
    <TxDtTm>2026-08-26T10:15:30+02:00</TxDtTm>
    <TxRef>VAL-000002</TxRef>
  </TxId>
  <TxDtls>
    <Ccy>EUR</Ccy>
    <TtlAmt>0.00</TtlAmt>
  </TxDtls>
  <AddtlTxData>/request/token</AddtlTxData>
</Tx>

Token provisioning must be enabled for the store. The token response format follows the response profile agreed during onboarding. Always evaluate the authorization result independently; the presence of token data is not proof that the Card Validity Check was approved.

Response handling

Read the decision from:

Document/AccptrAuthstnRspn/AuthstnRspn/TxRspn/AuthstnRslt/RspnToAuthstn/Rspn

The response can also return:

Approved response example

The following is a focused caaa.002.001.06 response fragment:

<AuthstnRspn>
  <Envt>
    <!-- Returned acquirer, merchant, POI, and masked card information -->
  </Envt>
  <Tx>
    <TxId>
      <TxDtTm>2026-08-26T10:15:30+02:00</TxDtTm>
      <TxRef>VAL-000001</TxRef>
    </TxId>
    <RcptTxId>1234567890</RcptTxId>
    <TxDtls>
      <Ccy>EUR</Ccy>
      <TtlAmt>0.00</TtlAmt>
    </TxDtls>
  </Tx>
  <TxRspn>
    <AuthstnRslt>
      <RspnToAuthstn>
        <Rspn>APPR</Rspn>
        <RspnRsn>00:Function performed error-free</RspnRsn>
      </RspnToAuthstn>
      <CmpltnReqrd>false</CmpltnReqrd>
    </AuthstnRslt>
  </TxRspn>
</AuthstnRspn>

Response reason text and authorization-code availability can vary by acquiring route. Base the primary decision on Rspn, then retain the accompanying reason and references for support.

Operational guidance

• Do not submit a completion, capture, or settlement for a Card Validity Check.
• Do not treat approval as proof of sufficient funds for a later purchase.
• Do not treat approval as cardholder authentication or proof that the customer owns the card.
• Keep each transaction reference unique according to the integration's certified retry rules.
• On a timeout or connection loss, do not convert the check into a financial transaction.
• Tokenization, card validation, and any CVD result are separate outcomes; handle each explicitly.