---
title: "3D Secure Completion"
method: POST
path: "/3dsecure/completion"
tags: ["3D Secure"]
---

# 3D Secure Completion

`POST /3dsecure/completion`

This endpoint is utilized to send the status of the device fingerprint. This must be sent whenever the response to the [3D Secure Standalone](/apis/payments-platform-rest/openapi/3d-secure/3dsecurestandalone) results in a device fingerprint required.

**Integration Methods:**
- Host Direct

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.

## Headers

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

## Request body

- object
  - `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
  - `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, required
    - `invoice` string, required — 10-digit invoice number assigned by the interface to identify a transaction. An invoice number serves as a unique key that identifies a transaction within a batch in Shift4's Gateway. **Note: For US and Canadian processing: Although the invoice number is sent as a JSON string it is a numeric value. No alpha characters are allowed.** **For processing outside of the US and Canada alpha characters are allowed.**
  - `threeDSecure` object, required
    - `trxId` string, required — The assigned 3D Secure transaction ID
    - `compInd` 'Y' | 'N' | 'U', required — Indicates whether or not the device fingerprint was completed successfully. Value| Description -----|------------ Y | Yes N | No U | Unknown

## Response `200`

Transaction was processed

- union
  - object
    - `result` object[]
      - `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
      - `amount` Amount, required — Object containing information regarding the amount being requested. The `total` field within the object is required and specifies the amount being requested. All other fields are for informational purposes and must also be included in the `total` field. For example, a purchase of $100 with a $20 tip and $8 tax would be `128.00` in the `total` field, `20.00` in the `tip` field and `8.00` in the `tax` field. Note: For merchants that are configured to allow multiple currencies, the amount fields can specify up to three decimal places. However, the number of decimal places can not exceed the number allowed for the specified currency. See the [Currency Codes](/guides/appendices/currency-codes) section for details.
        - `total` number, required — The amount being charged for a particular transaction. If other amount fields are sent, they must be included in the total amount. Amount cannot be zero.
        - `tax` number, required — The amount of sales tax charged for a transaction. The tax amount is used by businesses to track tax expenses for accounting purposes. Identifying the tax amount also helps consumers understand the total amount that they were billed. This field is part of Level 2 card data.
        - `taxIndicator` 'Y' | 'N' — Value|Description -----|----------- Y | Tax is included N | Tax is not included
        - `cashback` number — Specifies the cashback amount in a transaction. When using a UTG-controlled PIN pad with the ALLOWCASHBACK API Option, this field will return the cashback amount requested by the consumer. The interface can also send the desired cashback amount in a request by adding it to the `amount.total` and including it in the `amount.cashback` field. This will bypass prompting the consumer for a cashback amount.
        - `iiasAmounts` IIASAmounts[] — **Conditional: Send in the request if processing for a health care merchant.** For Vision related charges you must send only `iiasAmounts.type = 4V` and the corresponding `iiasAmounts.amount` value. For all other charges, the first entry in the array should have an amount representing the total of all healthcare costs, and `iiasAmounts.type = 4S`. Any subsequent entries should contain the subtotal for each of the other expense types involved in this transaction.
          - `amount` number — The subtotal for this type of healthcare expenses.
          - `type` '4O' | '4S' | '4T' | '4U' | '4V' | '4W' | '4X' — This code classifies eligible healthcare expenses. Value|Description -----|----------- 4O | Cash Disbursement (Discover Only) – Amount of Cash Back Being Requested 4S | Healthcare (Visa/MC Only) – Qualified Medical Expenses or Over-the-Counter 4T | Transit (Visa Only) – Transit Fare Media (e.g., Commuter and Parking Passes, Mass Transit Vouchers, and Tickets) 4U | RX (Visa/MC Only) 4V | Vision (Visa Only) 4W | Clinical (Visa Only) 4X | Dental (Visa Only)
        - `surcharge` number — **Conditional: Send in the request if a surcharge was applied to the transaction.** In a sale or authorization transaction, the `surcharge` field specifies a fee amount that a consumer is charged in addition to the transaction amount. The fee amount is also added into `amount.total`. For example, if the transaction request had `amount.total = 100` and the `surcharge.percentage` was 1.5% the transaction would include `amount.total = 101.50` and `amount.surcharge = 1.50`
        - `tip` number — **Conditional: Send in the request if a tip is included.** The tip amount of the transaction.
        - `checkTotal` number — Optional field specifying the total amount of the entire bill/invoice that this transaction is part of. It can be larger than `amount.total` in scenarios where the check is being split or if a portion of the check was already paid in cash or another form of payment.
      - `currencyCode` string, ISO 4217 3 Character Alphabetic Code, required — 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.**
      - `card` CardResponse, required
        - `entryMode` '1' | '2' | 'C' | 'E' | 'M' | 'Q' | 'R' — **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
        - `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.
        - `levelResult` string — Classifies the type of card used in an authorization/sale request. This field is returned in a response if the data is provided by the processor. See [Card Level Results]/guides/appendices/card-level-results) for a complete list of values.
        - `number` string — The card number field will always be masked when returned in a response.
        - `present` 'Y' | 'N' — **Conditional: Send in the initial authorization/sale request** Indicates whether a card was present (‘Y’) or not (‘N’) at the time a transaction took place. This should be set appropriately in the initial authorization/sale request. In subsequent requests, this field should be left blank or should not be sent. **Note:** Subsequent request here does not apply to the secondary request for card on file type transactions or reuse of the same card. An example of a subsequent request would be a capture after an authorization. You would not include `card.present` in the capture, which is the subsequent request. Another example is when performing an incremental authorization where you perform an authorization, followed by an incremental authorization then a capture. The second authorization (incremental) and the capture are the subsequent requests where you would not include `card.present`.
        - `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
        - `balance` CardBalance
          - `amount` number — The balance remaining on the card. Depending on which processor is being used, the balance may be returned for a gift card, debit card, EBT card, or other stored value card.
        - `securityCode` CardSecurityCodeResponse — **Conditional: Returned if card.securityCode was sent in the request.**
          - `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.
        - `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.
        - `debitType` 'girocard' | 'eftpos' | 'Interac' | 'Visa Interlink' | 'Visa US Common Debit' | 'Maestro Int'l' | 'Maestro US Common Debit' | 'Amex US Common Debit' | 'Discover US Common Debit' | 'DNA Debit' | 'UnionPay' — Specifies the type of debit card that was used when processing a transaction. Only returned if `card.type` = `DB`
      - `customer` object, required
        - `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.
        - `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.
        - `phoneNumber` string — Customer phone number
        - `emailAddress` string — Customer email address.
        - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
        - `city` string — Customer address city.
        - `region` string — A level 2 country subdivision code according to ISO-3166-2.
        - `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**
        - `country` string — 2 character ISO Country Code. See the [ISO](https://www.iso.org/obp/ui/#search/code/) website for details.
        - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
      - `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, required
        - `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.
        - `authSource` 'E' | 'O' | 'A' | 'F' — In a response, a code returned by the processor to indicate which host issued the response. Value | Description -------|---------------------------- E | Engine (Online) O | Offline A | APM (Online) F | Payment Platform (Online)
        - `hostResponse` HostResponse — Returns the response code detailing why the transaction was declined. **Notes:** - **For Visa, the response codes are categorized, detailing how declined transactions may be re-attempted for approval. To avoid fees, merchants are responsible for preventing additional attempts based on the information returned.** - **Support for this field is dependent on the processor. Our demo environment does not return this field in the response.**
          - `reasonCode` string — Returns a response code from the host. Value |Category|Description ------|--------|----------- 04 | 1 | Pick Up Card 07 | 1 | Pick Up Card, Special Condition 12 | 1 | Invalid Transaction 15 | 1 | No Such Issuer 41 | 1 | Lost Card 43 | 1 | Stolen Card 46 | 1 | Closed Account 57 | 1 | Trans. not Permitted to Cardholder R0 | 1 | Stop Payment Order R1 | 1 | Revocation of Auth Order R3 | 1 | Revocation of all Authorization 03 | 2 | Invalid Merchant 19 | 2 | Re-enter Transaction 51 | 2 | Not sufficient funds 59 | 2 | Suspected Fraud 61 | 2 | Exceeds approval amount limit 62 | 2 | Restricted Card (card invalid in region or country) 65 | 2 | Exceeds withdrawal frequency limit 75 | 2 | Allowable number of PIN-entry tried exceeded 78 | 2 | Blocked, first used 86 | 2 | Cannot Verify PIN 91 | 2 | Issuer or switch inoperative 93 | 2 | Transaction cannot be completed - violation of law 96 | 2 | System malfunction N3 | 2 | Cash service not available N4 | 2 | Cash request exceeds issuer of approved limit 14 | 3 | Invalid Account 54 | 3 | Expired card or expiration date missing 55 | 3 | PIN incorrect or missing 70 | 3 | PIN data required 82 | 3 | Negative Online CAM, dCVV, iCVV, or CVV results 1A | 3 | Additional customer authentication required N7 | 3 | Decline for CVV2 Failure 05 | 4 | Do not honor 06 | 4 | General error 08 | 4 | Honor MasterCard with ID 13 | 4 | Invalid amount 21 | 4 | Invalid amount 30 | 4 | Format error 39 | 4 | No credit account 52 | 4 | No checking account 53 | 4 | No savings account 58 | 4 | Transaction not permitted-Terminal 63 | 4 | Security violation 66 | 4 | Card Acceptor call Acquirer’s security dept 67 | 4 | Hard capture (requires ATM pick-up) 68 | 4 | Response received too late 71 | 4 | PIN Not Changed 76 | 4 | Unsolicited reversal 77 | 4 | Invalid Data including AVS failures. 79 | 4 | Already reversed at switch 80 | 4 | No Financial impact 81 | 4 | Cryptographic error 92 | 4 | Unable to route transaction 94 | 4 | Duplicate Transaction B1 | 4 | Surcharge amount not permitted on debit cards or EBTfoodstamps B2 | 4 | Surcharge amount not supported by debit network issuer CV | 4 | Card Type VerificationError EA | 4 | Acct Length Err EB | 4 | Check Digit Err EC | 4 | CID Format Error HV | 4 | Hierarchy Verification Error N0 | 4 | Force STIP P5 | 4 | PIN Change/Unblock failed P6 | 4 | New PIN not accepted Z3 | 4 | Unable to go online; offline-declined \-38 | 4 | The transaction has been denied by the Gateway because 3D secure Authentication failed. Reason: {}<br><br>Note: The “Reason” part is optional and may appear according to detected reason. | D2 | 4 | Decline Retry Later All other, generic declines may be classified as a Category 4 response code.
          - `reasonDescription` string — Returns a description from the host.
          - `reattemptPermission` string — Returns one of the following values: Value |Description ----------------------------------------|----------- Reattempt not permitted | Returned when the reasonCode returned is classified as a Category 1 response code. Reattempt permitted 15 times in 30 days | Returned when the reasonCode returned is classified as a Category 2 or Category 3 response code. Reattempts permitted | Returned when the reasonCode returned is classified as a Category 4 response code.
        - `invoice` string — 10-digit invoice number assigned by the interface to identify a transaction. An invoice number serves as a unique key that identifies a transaction within a batch in Shift4's Gateway. **Note: For US and Canadian processing: Although the invoice number is sent as a JSON string it is a numeric value. No alpha characters are allowed.** **For processing outside of the US and Canada alpha characters are allowed.**
        - `responseCode` 'A' | 'C' | 'D' | 'e' | 'f' | 'P' | 'R' | 'S' — Code indicating the Shift4 host response. Value | Description | Details -------|---------------|-------- A | Approved | The 3D Secure process was approved. D | Declined | The 3D Secure process was declined.
        - `retrievalReference` string — Reference retrieval number assigned by the authorizing agency. This value is printed on some receipts.
        - `saleFlag` 'A' | 'C' | 'S' — Specifies a transaction is a sale (‘S’) or credit (‘C’). In an [Invoice Information](/apis/payments-platform-rest/openapi/transactions/getinvoice) request, an 'A' may be returned to differentiate an authorization from a sale.
        - `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**
      - `threeDSecure` object
        - `trxId` string — The assigned 3D Secure transaction ID
        - `cardholderInfo` string — Provides additional information to the customer in particular cases when 3D secure Authentication failed.
      - `receipt` Receipt[] — Array of receipt key/value pairs that should be printed on the receipt.
        - `key` string — The identifier the interface vendor can use to programmatically determine where to print a specific value.
        - `printName` string — The label that relates to the `printValue` field. When present in the response, this must be printed to the left of the `printValue`.
        - `printValue` string — The value that relates to the `printName` field. This must be printed to the right of the `printName`.
      - `server` Server
        - `name` string — The name of the server that processed the request.
      - `universalToken` UniversalToken
        - `value` string — An identifier for a card or payment account across all Shift4 merchants.
      - `cardBrandToken` CardBrandToken
        - `requestorId` string, required — This field uniquely identifies the pairing of token requestor with the token domain. It is assigned by the token service provider and is unique within the token vault. For Apple Pay requests, this is mapped from the `token.paymentData.data.deviceManufacturerIdentifier` field
        - `assuranceLevel` string — This is a response field defined by the token service provider. This Visa, Discover, or Mastercard value indicates the assigned confidence level of the token-to-PAN/cardholder binding.
        - `panLast4` string — This is a response field that contains 4 characters that represent the last 4 digits of the actual cardholder PAN.
        - `acctRangeStatus` string — This is a response field contains a one-character value that indicates the Visa regulatory status of the actual card number for which the token represents. Value| Description -----|------------ space| Blank/no value R | Regulated N | Non-Regulated
  - object
    - `result` object[]
      - `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
      - `amount` Amount, required — Object containing information regarding the amount being requested. The `total` field within the object is required and specifies the amount being requested. All other fields are for informational purposes and must also be included in the `total` field. For example, a purchase of $100 with a $20 tip and $8 tax would be `128.00` in the `total` field, `20.00` in the `tip` field and `8.00` in the `tax` field. Note: For merchants that are configured to allow multiple currencies, the amount fields can specify up to three decimal places. However, the number of decimal places can not exceed the number allowed for the specified currency. See the [Currency Codes](/guides/appendices/currency-codes) section for details.
        - `total` number, required — The amount being charged for a particular transaction. If other amount fields are sent, they must be included in the total amount. Amount cannot be zero.
        - `tax` number, required — The amount of sales tax charged for a transaction. The tax amount is used by businesses to track tax expenses for accounting purposes. Identifying the tax amount also helps consumers understand the total amount that they were billed. This field is part of Level 2 card data.
        - `taxIndicator` 'Y' | 'N' — Value|Description -----|----------- Y | Tax is included N | Tax is not included
        - `cashback` number — Specifies the cashback amount in a transaction. When using a UTG-controlled PIN pad with the ALLOWCASHBACK API Option, this field will return the cashback amount requested by the consumer. The interface can also send the desired cashback amount in a request by adding it to the `amount.total` and including it in the `amount.cashback` field. This will bypass prompting the consumer for a cashback amount.
        - `iiasAmounts` IIASAmounts[] — **Conditional: Send in the request if processing for a health care merchant.** For Vision related charges you must send only `iiasAmounts.type = 4V` and the corresponding `iiasAmounts.amount` value. For all other charges, the first entry in the array should have an amount representing the total of all healthcare costs, and `iiasAmounts.type = 4S`. Any subsequent entries should contain the subtotal for each of the other expense types involved in this transaction.
          - `amount` number — The subtotal for this type of healthcare expenses.
          - `type` '4O' | '4S' | '4T' | '4U' | '4V' | '4W' | '4X' — This code classifies eligible healthcare expenses. Value|Description -----|----------- 4O | Cash Disbursement (Discover Only) – Amount of Cash Back Being Requested 4S | Healthcare (Visa/MC Only) – Qualified Medical Expenses or Over-the-Counter 4T | Transit (Visa Only) – Transit Fare Media (e.g., Commuter and Parking Passes, Mass Transit Vouchers, and Tickets) 4U | RX (Visa/MC Only) 4V | Vision (Visa Only) 4W | Clinical (Visa Only) 4X | Dental (Visa Only)
        - `surcharge` number — **Conditional: Send in the request if a surcharge was applied to the transaction.** In a sale or authorization transaction, the `surcharge` field specifies a fee amount that a consumer is charged in addition to the transaction amount. The fee amount is also added into `amount.total`. For example, if the transaction request had `amount.total = 100` and the `surcharge.percentage` was 1.5% the transaction would include `amount.total = 101.50` and `amount.surcharge = 1.50`
        - `tip` number — **Conditional: Send in the request if a tip is included.** The tip amount of the transaction.
        - `checkTotal` number — Optional field specifying the total amount of the entire bill/invoice that this transaction is part of. It can be larger than `amount.total` in scenarios where the check is being split or if a portion of the check was already paid in cash or another form of payment.
      - `currencyCode` string, ISO 4217 3 Character Alphabetic Code, required — 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.**
      - `card` CardResponse3DSChallenge, required
        - `entryMode` '1' | '2' | 'C' | 'E' | 'M' | 'Q' | 'R' — **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
        - `number` string — The card number field will always be masked when returned in a response.
        - `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.
        - `present` 'Y' | 'N' — **Conditional: Send in the initial authorization/sale request** Indicates whether a card was present (‘Y’) or not (‘N’) at the time a transaction took place. This should be set appropriately in the initial authorization/sale request. In subsequent requests, this field should be left blank or should not be sent. **Note:** Subsequent request here does not apply to the secondary request for card on file type transactions or reuse of the same card. An example of a subsequent request would be a capture after an authorization. You would not include `card.present` in the capture, which is the subsequent request. Another example is when performing an incremental authorization where you perform an authorization, followed by an incremental authorization then a capture. The second authorization (incremental) and the capture are the subsequent requests where you would not include `card.present`.
        - `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
        - `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.
      - `customer` object, required
        - `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.
        - `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.
        - `phoneNumber` string — Customer phone number
        - `emailAddress` string — Customer email address.
        - `addressLine1` string — Cardholder’s street address exactly as it appears on their billing statement. This field is used in AVS.
        - `city` string — Customer address city.
        - `region` string — A level 2 country subdivision code according to ISO-3166-2.
        - `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**
        - `country` string — 2 character ISO Country Code. See the [ISO](https://www.iso.org/obp/ui/#search/code/) website for details.
        - `ipAddress` string — Public source IP Address where the request originates, not the IP Address of the web server.
      - `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, required
        - `authSource` 'E' | 'O' | 'A' | 'F' — In a response, a code returned by the processor to indicate which host issued the response. Value | Description -------|---------------------------- E | Engine (Online) O | Offline A | APM (Online) F | Payment Platform (Online)
        - `invoice` string — 10-digit invoice number assigned by the interface to identify a transaction. An invoice number serves as a unique key that identifies a transaction within a batch in Shift4's Gateway. **Note: For US and Canadian processing: Although the invoice number is sent as a JSON string it is a numeric value. No alpha characters are allowed.** **For processing outside of the US and Canada alpha characters are allowed.**
        - `responseCode` 'G' — Response code indicating that the 3D Secure transaction requires a challenge. Value |Description -------|----------- G | 3D Secure challenge required. Issuer challenge URL returned in the redirectURL field.
        - `retrievalReference` string — Reference retrieval number assigned by the authorizing agency. This value is printed on some receipts.
        - `saleFlag` 'A' | 'C' | 'S' — Specifies a transaction is a sale (‘S’) or credit (‘C’). In an [Invoice Information](/apis/payments-platform-rest/openapi/transactions/getinvoice) request, an 'A' may be returned to differentiate an authorization from a sale.
        - `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**
      - `threeDSecure` object, required
        - `trxId` string, required — The assigned 3D Secure transaction ID
      - `redirectUrl` string, required — URL to redirect the browser to the 3D Secure transaction response indicates a Device Fingerprint or 3D Secure challenge is required.
      - `server` Server
        - `name` string — The name of the server that processed the request.

## 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)