---
title: "Verify Card with Processor"
method: POST
path: "/cards/verify"
tags: ["Cards"]
---

# Verify Card with Processor

`POST /cards/verify`

This function is used to request card validation by going online to verify the card information with the processor. If Address Verification System (AVS) and/or Card Security Code (CSC) data are sent in the request, that information will also be validated.

To process an Account Name Inquiry request the `USEANI` API Option and `customer.lastName` must be sent in the request. `customer.firstName` and `customer.middleName` are optional. Account Name Inquiry requests are currently limited to Visa cards.

**Integration Methods:**
- Host Direct
- Commerce Engine For On Premise
- Commerce Engine For Cloud
- Locally Installed UTG

See the [Integration Methods](/guides/quickstart#integration-methods) and [URLs Section](/guides/quickstart#urls) sections of the Development Quick Start guide for details regarding each processing option.

See the [JSON Body Schemas](/guides/quickstart#json-body-schemas) for more details on the various JSON body formats.

## Headers

- `InterfaceVersion` string, required
- `InterfaceName` string, required
- `CompanyName` string, required
- `AccessToken` string, uuid, required

## Request body

- union
  - CardsVerifyComengdevice
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `device` object
      - `terminalId` string — To prompt a specific UTG-controlled PIN pad in a request, the API Terminal ID configured in UTG TuneUp must be specified in this field.
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
    - `ui` object
      - `language` string — ISO 639-1 2-letter language code specifying the UI display language for the transaction (e.g. "en", "fr", "de"). When provided, overrides the device's configured default language for the duration of the session. Value persists across transactions until a new value is passed. Send default to reset the device back to its default language.
      - `mode` 'light' | 'dark' — Set the UI to light mode by sending `light` or dark mode by sending `dark`
      - `suppressFinalResult` boolean — When `true`, the terminal suppresses the final transaction result screen.
  - CardsVerifyComengcloud
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `device` object, required
      - `cloud` boolean, required — Indicates the transaction will be processed via the Commerce Engine solution for cloud based POS/PMS systems. Value must be sent as `true` in order to route the request to the payment device at the merchant location.
      - `manufacturer` 'Ingenico' | 'Innowi' | 'PAX' | 'Verifone' | 'Castles' | 'Miura', required — Specifies the company which manufactured the device.
      - `serialNumber` string, required — Specifies the serial number of the device.
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
    - `ui` object
      - `language` string — ISO 639-1 2-letter language code specifying the UI display language for the transaction (e.g. "en", "fr", "de"). When provided, overrides the device's configured default language for the duration of the session. Value persists across transactions until a new value is passed. Send default to reset the device back to its default language.
      - `mode` 'light' | 'dark' — Set the UI to light mode by sending `light` or dark mode by sending `dark`
      - `suppressFinalResult` boolean — When `true`, the terminal suppresses the final transaction result screen.
  - CardsVerifyUtgdevice
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `device` object, required
      - `terminalId` string, required — To prompt a specific UTG-controlled PIN pad in a request, the API Terminal ID configured in UTG TuneUp must be specified in this field.
      - `promptPostalCode` 'Y' | 'N' — When using a UTG-controlled PIN pad: Value|Description -----|----------- Y | Force the PIN pad to prompt the consumer for a ZIP/Postal Code. N | Do not force the PIN pad to prompt the consumer for a ZIP/Postal Code. **Note: Use only when you want to override MCE (Manual Card Entry) settings in UTG.**
      - `promptCardSecurityCode` 'Y' | 'N' — When using a UTG-controlled PIN pad: Value|Description -----|----------- Y | Force the PIN pad to prompt the consumer for a CSC. N | Do not force the PIN pad to prompt the consumer for a CSC. **Note: Use only when you want to override MCE (Manual Card Entry) settings in UTG.**
      - `promptStreetNumber` 'Y' | 'N' — When using a UTG-controlled PIN pad: Value|Description -----|----------- Y | Force the PIN pad to prompt the consumer for the street number of their billing address. N | Do not force the PIN pad to prompt the consumer for the street number of their billing address. **Note: Use only when you want to override MCE (Manual Card Entry) settings in UTG.**
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
  - CardsVerifyTokenGtv
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `card` object, required
      - `token` CardTokenRequired, required
        - `value` string, required — This field is used to specify a card token. Whenever CHD is sent in a request, a card token will be returned in this field. Your interface should be designed to store this card token for future use. The latest card token received should be used in any subsequent request that references the same card data.
      - `expirationDate` integer — **Conditional: Send only when card data is manually entered or when using a token. This field should not be specified when using an encrypted device.** Card expiration date in MMYY format. This value should only be populated in the initial sale/authorization request.
      - `securityCode` CardSecurityCode — **Conditional: Send only when card data is manually entered. This object should not be specified when using an encrypted device. This object should be sent for initial card on file request but is not required for subsequent merchant initiated charges.**
        - `indicator` '0' | '1' | '2' | '9', required — This field indicates the presence of a CSC. Value|Description -----|----------- 0 | CSC not provided by user. 1 | CSC provided. 2 | CSC illegible. 9 | CSC not on card, or card did not have a CSC.
        - `result` 'M' | 'N' | 'P' | 'S' | 'U' | 'Y' | '1' | '2' | '3' — **Conditional: Returned if `card.securityCode.indicator` and `card.securityCode.value` are sent in the request.** The result of a CSC check. This field will be used by Shift4 to determine the value sent in the `card.securityCode.valid` field (based on the merchant’s list of accepted verification results as configured with Shift4). Value|Description -----|------------ M | CSC matched. N | CSC did not match. P | CSC not processed. S | CSC should have been present. U | Issuer unable to process. Y | CVC1 incorrect. 1 | CSC Unavailable - processor / card type does not support this parameter. 2 | An unrecognised result code was returned by the processor. 3 | No result code was returned by the processor.
        - `valid` string — **Conditional: Returned if `card.securityCode.indicator` and `card.securityCode.value` are sent in the request.** A simplified CSC check result based on the value in the `card.securityCode.result` field and the merchant’s accepted verification results as configured with Shift4. The value returned will be ‘Y’ if CSC verification passed or ‘N’ if CSC verification did not pass.
        - `value` string, required — The three- or four-digit Card Security Code found on a payment card. This value should only be sent in an initial sale/authorization request. It should not be stored by the interface. When sending `card.securityCode.value`, `card.securityCode.indicator` must also be sent.
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
  - CardsVerifyTokenLegacy
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `card` object, required
      - `token` CardTokenRequiredLegacy, required
        - `value` string, required — This field is used to specify a card token. Whenever CHD is sent in a request, a card token will be returned in this field. Your interface should be designed to store this card token for future use. The latest card token received should be used in any subsequent request that references the same card data.
        - `serialNumber` string — In requests that require the use of a shared card token that is held by another merchant account, such as in a TokenStore or TokenShare®, this field is used to specify the serial number for the account where the card token is stored.
      - `expirationDate` integer — **Conditional: Send only when card data is manually entered or when using a token. This field should not be specified when using an encrypted device.** Card expiration date in MMYY format. This value should only be populated in the initial sale/authorization request.
      - `securityCode` CardSecurityCode — **Conditional: Send only when card data is manually entered. This object should not be specified when using an encrypted device. This object should be sent for initial card on file request but is not required for subsequent merchant initiated charges.**
        - `indicator` '0' | '1' | '2' | '9', required — This field indicates the presence of a CSC. Value|Description -----|----------- 0 | CSC not provided by user. 1 | CSC provided. 2 | CSC illegible. 9 | CSC not on card, or card did not have a CSC.
        - `result` 'M' | 'N' | 'P' | 'S' | 'U' | 'Y' | '1' | '2' | '3' — **Conditional: Returned if `card.securityCode.indicator` and `card.securityCode.value` are sent in the request.** The result of a CSC check. This field will be used by Shift4 to determine the value sent in the `card.securityCode.valid` field (based on the merchant’s list of accepted verification results as configured with Shift4). Value|Description -----|------------ M | CSC matched. N | CSC did not match. P | CSC not processed. S | CSC should have been present. U | Issuer unable to process. Y | CVC1 incorrect. 1 | CSC Unavailable - processor / card type does not support this parameter. 2 | An unrecognised result code was returned by the processor. 3 | No result code was returned by the processor.
        - `valid` string — **Conditional: Returned if `card.securityCode.indicator` and `card.securityCode.value` are sent in the request.** A simplified CSC check result based on the value in the `card.securityCode.result` field and the merchant’s accepted verification results as configured with Shift4. The value returned will be ‘Y’ if CSC verification passed or ‘N’ if CSC verification did not pass.
        - `value` string, required — The three- or four-digit Card Security Code found on a payment card. This value should only be sent in an initial sale/authorization request. It should not be stored by the interface. When sending `card.securityCode.value`, `card.securityCode.indicator` must also be sent.
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
  - CardsVerifyP2peIdtech
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `p2pe` P2PEType0102IDTECH, required
      - `data` string, required — The full output of a P2PE keypad/magnetic swipe reader (MSR).
      - `format` '01' | '02', required — Classifies the type of payment device being used for P2PE. Value|Description -----|----------- 01 | IDTech Enhanced Encryption format (Keyboard Mode) 02 | IDTech Enhanced Encryption format (USB HID Mode)
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
  - CardsVerifyP2peTdesdukptEmv
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `card` object, required
      - `entryMode` '1' | '2' | 'C' | 'E' | 'M' | 'Q' | 'R', required — **Conditional: The Card Entry Mode should be sent in an initial request; in subsequent requests, it should be left blank or not sent. When using a Universal Transaction Gateway® (UTG®)-controlled PIN pad, this field should be left blank or not sent in a request; the UTG will capture the card entry mode and return it in the response. When P2PE data is being sent from a non-UTG controlled device, this field is not needed** The method used to capture a payment card in an authorization/sale request. Value|Description -----|----------- 1 | Track 1 Only or Dual Track (Track 1 & 2) 2 | Track 2 Only C | EMV Contactless via card or mobile wallet E | EMV Chip M | Manual Entry Q | QR Code R | Contactless MSD
    - `device` object, required
      - `manufacturer` 'Ingenico' | 'Innowi' | 'PAX' | 'Verifone' | 'Castles' | 'Miura', required — Specifies the company which manufactured the device.
      - `model` string, required — **Conditional: Required when using a non-UTG-controlled device.** Specifies the model of the device.
      - `serialNumber` string, required — Specifies the serial number of the device.
      - `capability` DeviceCapability, required — **Conditional: Required when using a non-UTG-controlled device.**
        - `contactlessEMV` 'Y' | 'N' — Specifies whether or not the device supports contactless EMV. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `contactlessMSR` 'Y' | 'N' — Specifies whether or not the device supports contactless magstripe. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `EMV` 'Y' | 'N' — Specifies whether or not the device supports EMV. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `manualEntry` 'Y' | 'N' — Specifies whether or not the device supports manual entry. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `magstripe` 'Y' | 'N' — Specifies whether or not the device supports magstripe. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `PIN` 'Y' | 'N' — Specifies whether or not the device supports PIN entry (for debit or EMV). If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `quickChip` 'Y' | 'N' — Specifies whether or not the device supports quick chip. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `signature` 'Y' | 'N' — Specifies whether or not the device supports signature capture. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
    - `emv` object, required
      - `tlvData` string, required — This field will contain all EMV tags in standard TLV format including the P2PE encrypted tags (5A and 57). The P2PE encrypted tags (5A and 57) will have the entire TLV string encrypted and the encrypted data will be in a TLV format using the same tag. For example, tag 5A would look like the following: - Encrypted: 5A103737DA95D8062F647A0FF747CC496570 - Decrypted: 5A084761739001010010
    - `p2pe` P2PEType05TDESDUKPTEMV, required — See [P2PE Format 05 TDES DUKPT](/guides/core-concepts/p2pe-format#tdes-dukpt---format-05) for more information.
      - `format` '05', required — Classifies the type of payment device being used for P2PE. Value|Description -----|----------- 05 | [Shift4 TDES DUKPT format](/guides/core-concepts/p2pe-format#tdes-dukpt---format-05)
      - `ksn` string, required — The key serial number which was used to encrypt the P2PE data.
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
  - CardsVerifyP2peTdesdukptMsr
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `card` object, required
      - `entryMode` '1' | '2' | 'C' | 'E' | 'M' | 'Q' | 'R', required — **Conditional: The Card Entry Mode should be sent in an initial request; in subsequent requests, it should be left blank or not sent. When using a Universal Transaction Gateway® (UTG®)-controlled PIN pad, this field should be left blank or not sent in a request; the UTG will capture the card entry mode and return it in the response. When P2PE data is being sent from a non-UTG controlled device, this field is not needed** The method used to capture a payment card in an authorization/sale request. Value|Description -----|----------- 1 | Track 1 Only or Dual Track (Track 1 & 2) 2 | Track 2 Only C | EMV Contactless via card or mobile wallet E | EMV Chip M | Manual Entry Q | QR Code R | Contactless MSD
    - `device` object, required
      - `manufacturer` 'Ingenico' | 'Innowi' | 'PAX' | 'Verifone' | 'Castles' | 'Miura', required — Specifies the company which manufactured the device.
      - `model` string, required — **Conditional: Required when using a non-UTG-controlled device.** Specifies the model of the device.
      - `serialNumber` string, required — Specifies the serial number of the device.
      - `capability` DeviceCapability, required — **Conditional: Required when using a non-UTG-controlled device.**
        - `contactlessEMV` 'Y' | 'N' — Specifies whether or not the device supports contactless EMV. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `contactlessMSR` 'Y' | 'N' — Specifies whether or not the device supports contactless magstripe. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `EMV` 'Y' | 'N' — Specifies whether or not the device supports EMV. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `manualEntry` 'Y' | 'N' — Specifies whether or not the device supports manual entry. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `magstripe` 'Y' | 'N' — Specifies whether or not the device supports magstripe. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `PIN` 'Y' | 'N' — Specifies whether or not the device supports PIN entry (for debit or EMV). If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `quickChip` 'Y' | 'N' — Specifies whether or not the device supports quick chip. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `signature` 'Y' | 'N' — Specifies whether or not the device supports signature capture. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
    - `p2pe` P2PEType05TDESDUKPTMSR, required — See [P2PE Format 05 TDES DUKPT](/guides/core-concepts/p2pe-format#tdes-dukpt---format-05) for more information.
      - `data` string, required — The full output of a P2PE keypad/magnetic swipe reader (MSR).
      - `format` '05', required — Classifies the type of payment device being used for P2PE. Value|Description -----|----------- 05 | [Shift4 TDES DUKPT format](/guides/core-concepts/p2pe-format#tdes-dukpt---format-05)
      - `ksn` string, required — The key serial number which was used to encrypt the P2PE data.
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
  - CardsVerifyP2peOnguardsdeEmv
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `card` object, required
      - `entryMode` '1' | '2' | 'C' | 'E' | 'M' | 'Q' | 'R', required — **Conditional: The Card Entry Mode should be sent in an initial request; in subsequent requests, it should be left blank or not sent. When using a Universal Transaction Gateway® (UTG®)-controlled PIN pad, this field should be left blank or not sent in a request; the UTG will capture the card entry mode and return it in the response. When P2PE data is being sent from a non-UTG controlled device, this field is not needed** The method used to capture a payment card in an authorization/sale request. Value|Description -----|----------- 1 | Track 1 Only or Dual Track (Track 1 & 2) 2 | Track 2 Only C | EMV Contactless via card or mobile wallet E | EMV Chip M | Manual Entry Q | QR Code R | Contactless MSD
    - `device` object, required
      - `manufacturer` 'Ingenico' | 'Innowi' | 'PAX' | 'Verifone' | 'Castles' | 'Miura', required — Specifies the company which manufactured the device.
      - `model` string, required — **Conditional: Required when using a non-UTG-controlled device.** Specifies the model of the device.
      - `serialNumber` string, required — Specifies the serial number of the device.
      - `capability` DeviceCapability, required — **Conditional: Required when using a non-UTG-controlled device.**
        - `contactlessEMV` 'Y' | 'N' — Specifies whether or not the device supports contactless EMV. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `contactlessMSR` 'Y' | 'N' — Specifies whether or not the device supports contactless magstripe. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `EMV` 'Y' | 'N' — Specifies whether or not the device supports EMV. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `manualEntry` 'Y' | 'N' — Specifies whether or not the device supports manual entry. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `magstripe` 'Y' | 'N' — Specifies whether or not the device supports magstripe. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `PIN` 'Y' | 'N' — Specifies whether or not the device supports PIN entry (for debit or EMV). If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `quickChip` 'Y' | 'N' — Specifies whether or not the device supports quick chip. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `signature` 'Y' | 'N' — Specifies whether or not the device supports signature capture. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
    - `p2pe` P2PEType03OnguardSDEEMV, required — See [P2PE Format 03 Ingenico On-Guard SDE](/guides/core-concepts/p2pe-format#ingenico-on-guard-sde---format-03) for more information.
      - `data` string, required — EMV TLV Data for tags 5A and 57 encrypted with AES 256 DUKPT. Contains the following information, separated by colons: Value | Description ----------------|------------ ksn | The key serial number (24 byte hex) track indicator | `E` indicating EMV TLV Data length | The length of the encrypted data encrypted data | Encrypted TLV containing tags 57 and 5A Example: `FFFF495A0000000200000002:E:0032:E0AB94F7704E77AB37F81A7E236A1ABC1465C6DFCE43A506240D6E7D6DDA7EA9`
      - `format` '03', required — Classifies the type of payment device being used for P2PE. Value|Description -----|----------- 03 | Ingenico Onguard SDE Format
    - `emv` object, required
      - `tlvData` string, required — This field will contain all EMV tags in standard TLV format except tags 5A and 57, which will be sent encrypted in the `p2pe.data` field.
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
  - CardsVerifyP2peOnguardsdeMsr
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `card` object, required
      - `entryMode` '1' | '2' | 'C' | 'E' | 'M' | 'Q' | 'R', required — **Conditional: The Card Entry Mode should be sent in an initial request; in subsequent requests, it should be left blank or not sent. When using a Universal Transaction Gateway® (UTG®)-controlled PIN pad, this field should be left blank or not sent in a request; the UTG will capture the card entry mode and return it in the response. When P2PE data is being sent from a non-UTG controlled device, this field is not needed** The method used to capture a payment card in an authorization/sale request. Value|Description -----|----------- 1 | Track 1 Only or Dual Track (Track 1 & 2) 2 | Track 2 Only C | EMV Contactless via card or mobile wallet E | EMV Chip M | Manual Entry Q | QR Code R | Contactless MSD
    - `device` object, required
      - `manufacturer` 'Ingenico' | 'Innowi' | 'PAX' | 'Verifone' | 'Castles' | 'Miura', required — Specifies the company which manufactured the device.
      - `model` string, required — **Conditional: Required when using a non-UTG-controlled device.** Specifies the model of the device.
      - `serialNumber` string, required — Specifies the serial number of the device.
      - `capability` DeviceCapability, required — **Conditional: Required when using a non-UTG-controlled device.**
        - `contactlessEMV` 'Y' | 'N' — Specifies whether or not the device supports contactless EMV. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `contactlessMSR` 'Y' | 'N' — Specifies whether or not the device supports contactless magstripe. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `EMV` 'Y' | 'N' — Specifies whether or not the device supports EMV. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `manualEntry` 'Y' | 'N' — Specifies whether or not the device supports manual entry. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `magstripe` 'Y' | 'N' — Specifies whether or not the device supports magstripe. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `PIN` 'Y' | 'N' — Specifies whether or not the device supports PIN entry (for debit or EMV). If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `quickChip` 'Y' | 'N' — Specifies whether or not the device supports quick chip. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
        - `signature` 'Y' | 'N' — Specifies whether or not the device supports signature capture. If this input method can be supported by the device, but the input method is currently disabled for all transactions on the device, then the value 'N' should be sent.
    - `p2pe` P2PEType03OnguardSDEMSR, required — See [P2PE Format 03 Ingenico On-Guard SDE](/guides/core-concepts/p2pe-format#ingenico-on-guard-sde---format-03) for more information.
      - `data` string, required — Track information encrypted with AES 256 DUKPT. Contains the following information, separated by colons: |Value | Description |----------------|------------ |ksn | The key serial number (24 byte hex) |track indicator | `1` = track 1 only<br />`2` = track 2 only<br />`3` = manual entry<br />`4` = dual track<br /> |length | The length of the encrypted data |encrypted data | Encrypted track/manual entry data Dual Track Example: `FFFF495A0000000200000005:4:0128:F48C880DE0DAF549E642C5CC25E65ADF9947E7EB0636DB80C4A490B4C0930AEF64B7201505343CED533A2AE9AFABFE6453875F705519A8109362197CA3BD8DA0FE90DB3F954B9CDA0DB58BDA3330862ADD28CB31EFDA7C641575E33D395D8BFF72EBF0B1FF9630DB0EAB080FE8C9B2FAC28127CDC48CA9F7D532D5BDE4CCE270` Manual entry Example: `FFFF495A0000000200000006:3:0032:E394820DB97AF927B9B5E05F356750BBF5DFCCB3BC18B87E8FC3C9BC596229E7`
      - `format` '03', required — Classifies the type of payment device being used for P2PE. Value|Description -----|----------- 03 | Ingenico Onguard SDE Format
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.
  - CardsVerifyUnencryptedcard
    - `dateTime` string, ISO 8601, required — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `card` object, required
      - `number` string, required — The payment card number entered in an initial authorization/sale request. This field will always be masked when returned in a response.
      - `expirationDate` integer, required — **Conditional: Send only when card data is manually entered or when using a token. This field should not be specified when using an encrypted device.** Card expiration date in MMYY format. This value should only be populated in the initial sale/authorization request.
      - `securityCode` object
        - `indicator` '0' | '1' | '2' | '9' — This field indicates the presence of a CSC. Value|Description -----|----------- 0 | CSC not provided by user. 1 | CSC provided. 2 | CSC illegible. 9 | CSC not on card, or card did not have a CSC.
        - `value` string — The three- or four-digit Card Security Code found on a payment card. This value should only be sent in an initial sale/authorization request. It should not be stored by the interface. When sending `card.securityCode.value`, `card.securityCode.indicator` must also be sent.
    - `transaction` object
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
      - `purchaseCard` object
        - `customerReference` string — A unique value used to identify the consumer or transaction. If a merchant has a significant amount of revenue from purchasing card customers, the interface would use this field to collect the consumer’s purchase order or employee identification number. In lodging transactions, this may be unique transaction details, such as a reservation code or third-party booking source. This field is part of Level 2 card data.
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `currencyCode` string, ISO 4217 3 Character Alphabetic Code — Transaction currency code. See the [Currency Codes](/guides/appendices/currency-codes) section for details. **Note: This is currently supported when processing for a merchant outside of the US and Canada. If processing for a US or Canadian merchant then this field will be ignored and the transaction will process in the merchant's configured currency.**
    - `apiOptions` string[] — API Options modify the request being made. See the [API Options](/guides/appendices/api-options.md) section for more information.

## Response `200`

Request was processed

- object
  - `result` object[]
    - `dateTime` string, ISO 8601 — The date and time in ISO 8601 format including the timezone offset (yyyy-mm-ddThh:mm:ss.nnn+hh:mm). Must be sent as the local date/time of the merchant. For example, a request processed at a merchant in the Pacific time zone at 9:18am on April 15th 2021 would be sent as 2021-04-15T09:18:23.283-07:00
    - `customer` Customer
      - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
      - `firstName` string — Specifies a consumer’s first name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `middleName` string — Specifies a consumer’s middle name.
      - `lastName` string — Specifies a consumer’s last name. This field is used in AVS. If the interface sends this field, the value specified by the interface will be returned in the response, unless the API Option [USECARDNAME](/guides/appendices/api-options#usecardname) is included in the request and a Commerce Engine or UTG-controlled PIN pad is in use. If the interface does not send the `customer` object, the consumer's name will be returned in the `customer` object if the name is present in the card's EMV or track data.
      - `postalCode` string — Cardholder’s ZIP/postal code from their billing statement. This field is used in AVS. Do not include special characters. **Note: This field only allows alphanumeric characters (a-z, A-Z, 0-9). Special characters including - are not allowed. If you are sending in zip+4 you must not include the dash so 89134-1234 would be sent as 891341234**
      - `emailAddress` string — Customer email address.
      - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
    - `card` object
      - `expirationDate` integer — **Conditional: Requires API Option "RETURNEXPDATE".** Card expiration date in MMYY format. This value will only be populated if "RETURNEXPDATE" is included in the `apiOptions` array.
      - `number` string — The card number field will always be masked when returned in a response.
      - `type` 'AX' | 'AP' | 'BC' | 'CI' | 'DB' | 'GC' | 'JC' | 'MC' | 'NS' | 'PL' | 'SC' | 'VS' | 'WP' | 'YC' — An abbreviation used to specify the type of card that was used when processing a transaction. Value| Description -----|------------ AX | American Express AP | Alipay BC | Backed Card CI | Citgo DB | Debit card GC | Gift Card JC | JCB MC | Mastercard NS | Discover/JCB/Novus PL | Private Label SC | Sears Canada VS | Visa WP | WeChat Pay YC | IT’S YOUR CARD
      - `securityCode` CardSecurityCode — **Conditional: Send only when card data is manually entered. This object should not be specified when using an encrypted device. This object should be sent for initial card on file request but is not required for subsequent merchant initiated charges.**
        - `indicator` '0' | '1' | '2' | '9', required — This field indicates the presence of a CSC. Value|Description -----|----------- 0 | CSC not provided by user. 1 | CSC provided. 2 | CSC illegible. 9 | CSC not on card, or card did not have a CSC.
        - `result` 'M' | 'N' | 'P' | 'S' | 'U' | 'Y' | '1' | '2' | '3' — **Conditional: Returned if `card.securityCode.indicator` and `card.securityCode.value` are sent in the request.** The result of a CSC check. This field will be used by Shift4 to determine the value sent in the `card.securityCode.valid` field (based on the merchant’s list of accepted verification results as configured with Shift4). Value|Description -----|------------ M | CSC matched. N | CSC did not match. P | CSC not processed. S | CSC should have been present. U | Issuer unable to process. Y | CVC1 incorrect. 1 | CSC Unavailable - processor / card type does not support this parameter. 2 | An unrecognised result code was returned by the processor. 3 | No result code was returned by the processor.
        - `valid` string — **Conditional: Returned if `card.securityCode.indicator` and `card.securityCode.value` are sent in the request.** A simplified CSC check result based on the value in the `card.securityCode.result` field and the merchant’s accepted verification results as configured with Shift4. The value returned will be ‘Y’ if CSC verification passed or ‘N’ if CSC verification did not pass.
        - `value` string, required — The three- or four-digit Card Security Code found on a payment card. This value should only be sent in an initial sale/authorization request. It should not be stored by the interface. When sending `card.securityCode.value`, `card.securityCode.indicator` must also be sent.
      - `token` CardTokenResponse
        - `value` string — This field is used to specify a card token. Whenever CHD is sent in a request, a card token will be returned in this field. Your interface should be designed to store this card token for future use. The latest card token received should be used in any subsequent request that references the same card data.
    - `device` DeviceOnlyTIDResponse
      - `terminalId` string — To prompt a specific UTG-controlled PIN pad in a request, the API Terminal ID configured in UTG TuneUp must be specified in this field.
    - `merchant` MerchantResponse
      - `mid` number — The merchant ID associated with the merchant account.
      - `name` string — The merchant’s business name as configured with Shift4.
    - `transaction` object
      - `authorizationCode` string — The authorization code provided by the consumer’s issuing bank. It is provided in a response if an online authorization or sale request is approved. Following a referral response, it is also specified in [Manual Sale](/apis/payments-platform-rest/openapi/transactions/manualsale) requests.
      - `responseCode` 'A' | 'D' | 'e' | 'f' — Code indicating the Shift4 host response. Value | Description | Details -------|------------------------------------------------------------------|-------- A | Approved | The card was successfully verified. D | Declined | The card failed verification. e | [Error](/guides/appendices/error-codes) | There is an error condition. f | [AVS or CSC failure](/guides/response-handling/understanding-avs-and-csc-verification)| An AVS or CSC failure has occurred (credit card only). **Note: This value will only be returned if the [POSHANDLEAVSFAIL Api Option](/guides/appendices/api-options#poshandleavsfail) was sent in the request.**
      - `avs` AVS
        - `postalCodeVerified` 'Y' | 'N' — Identifies whether the ZIP/postal code was verified (‘Y’) or not (‘N’) in an AVS check with a processor.
        - `result` 'A' | 'E' | 'G' | 'N' | 'R' | 'S' | 'U' | 'W' | 'X' | 'Y' | 'Z' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' — Identifies the response code returned from an Address Verification System (AVS) check with a processor. Value|Description -----|----------- A | Street address matched, but ZIP/postal code did not match. E | Error (AVS data is invalid or not allowed). G | Card issuer does not participate in AVS. N | No street address and no ZIP/postal code match. R | Card issuer system is unavailable. S | AVS service not supported. U | Street address information unavailable. W | Street address did not match, but ZIP/postal code matched. X | Street address and 9-digit ZIP/postal code matched. Y | Street address and 5-digit ZIP code matched. Z | Only the ZIP/postal code matched. 1 | Cardholder name and ZIP match 2 | Cardholder name, address, and ZIP match 3 | Cardholder name, address match 4 | Cardholder name matches 5 | Cardholder name incorrect, ZIP matches 6 | Cardholder name incorrect; address and ZIP match 7 | Cardholder name incorrect; address matches 8 | Cardholder name, address, and ZIP do not match
        - `streetVerified` 'Y' | 'N' — Identifies whether the street number was verified (‘Y’) or not (‘N’) in an AVS check with a processor.
        - `valid` 'Y' | 'N' — Simplified AVS result based on the merchant’s list of accepted responses as configured with Shift4: (‘Y’) if accepted or (‘N’) if not accepted.
      - `cardOnFile` CardOnFile — **Conditional: Send this object when the transaction being performed is using a card on file or when the request will result in storing a card on file.** See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for more information.
        - `type` 'S01' | 'S02' | 'U01' | 'U02' | 'U03' | 'U04' | 'U05' | 'U06' | 'U07' | 'U08' | 'U09' — This field specifies the type of the card-on-file transaction. Below is a table showing the valid values for use cases where the cardholder is entering their card data to store on file. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | S01 | Cardholder | No | Yes | Used when the initial transaction/card verification request is not for a recurring payment. | | S02 | Cardholder | Yes | Yes | Used when the initial transaction/card verification request is for a recurring payment. Requires sending `cardOnFile.recurringFrequency` and `cardOnFile.recurringExpiry` | Below is a table showing the valid values for uses cases where you already have a card on file and are using that existing card to process a transaction. | Value | Initiator | Recurring | 3D Secure | Description | |--------|------------|-----------|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | U01 | Cardholder | No | Yes | Unscheduled transaction using the card on file initiated by the cardholder | | U02 | Merchant | No | No | Unscheduled transaction using the card on file initiated by the merchant | | U03 | Merchant | Yes | No | Merchant initiated recurring payment using the card on file | | U04 | Merchant | No | No | Identifies a transaction as a Reauthorization COF transaction. | | U05 | Merchant | No | No | Identifies a transaction as a Resubmission COF transaction. Only certain merchant categories are able to send a resubmission, and it can only be done if the original authorization attempt was declined due to insufficient funds. | | U06 | Merchant | No | No | Identifies a transaction as an Estimated Authorization COF transaction. | | U07 | Merchant | No | No | Identifies a transaction as a Delayed Charges COF transaction. For example, a hotel might charge a customer for room damages after the guest has already checked out. | | U08 | Merchant | No | No | Identifies a transaction as an Incremental COF transaction. For example, a hotel which authorized a customer’s card for one night at check-in might increase the authorization amount to cover two nights when the customer decides to extend their stay. Shift4 automatically detects this scenario and sends the appropriate value to the processor. | | U09 | Merchant | No | No | Identifies a transaction as a No Show COF transaction. For example, a hotel might charge a customer who does not show up for a booked stay. | See the [Card On File Transactions](/guides/advanced-concepts/card-on-file-transactions) section for additional details.
        - `recurringExpiry` string — Date after which no further authorizations shall be performed. This field is limited to 8 characters, and the accepted format is YYYYMMDD. **Conditional: This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `recurringFrequency` string — Indicates the minimum number of days between authorizations. **Conditional: 'This field is required if it's the first recurring transaction (`cardOnFile.type = S02`). This field is not needed if the transaction is not recurring or if the transaction is a subsequent recurring transaction.**
        - `transactionId` string — This field is returned in the initial COF response, and ties subsequent COF transactions to the original authorization. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
        - `transactionLinkId` string — A unique identifier assigned to each transaction to link related events throughout the transaction lifecycle. This field is supported for Mastercard brand only. For example, if a merchant runs a Sale on a card for the first time, they will receive a transactionLinkId back in the response. A month later, when the merchant wants to perform an additional Sale with the card on file, they would send a Sale request including the transactionLinkId they received from the first sale. **Conditional: Must be sent in subsequent COF requests if you are not processing with a Global Token Vault token. If using Global Token Vault tokens then this field is not required**
    - `server` Server
      - `name` string — The name of the server that processed the request.
    - `accountNameInquiry` AccountNameInquiryResponse
      - `aniResponseCode` 'E' | 'A' | 'B' | 'C' | 'D' | 'F' | 'G' | 'H' | 'I' | 'J' | 'N' | 'U' — Account Name Inquiry Response Code. Returned if the `USEANI` API Option and customer name information is sent in the request. | ANI Response Code | Description | | ----------------- | ---------------------------------------------------------------------- | | E | Full name: match | | A | First name: partial match, Last name: match | | B | First name: no match, Last name: match | | C | First name: match, Last name: partial match | | D | First name: match, Last name: no match | | F | First name: partial match, Last name: partial match | | G | First name: no match, Last name: partial match | | H | First name: partial match, Last name: no match | | I | Last name: match | | J | Last name: partial match | | N | First name: no match, Last name: no match<br>or<br>Last name: no match | | U | Name match not performed |

## Other responses

- `400` — Error
- `504` — Timeout

---

[API](https://skmtc.dev/shift4/apis/shift4-payment-api.md) · [All operations](https://skmtc.dev/shift4/apis/shift4-payment-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/shift4/shift4-payment-api/revisions/2f85c87cc9e5/schema)