---
title: "Send test authorization request"
method: POST
path: "/v1/authorizations/request"
tags: ["test-authorizations"]
---

# Send test authorization request

`POST /v1/authorizations/request`

## Query parameters

- `auditUser` string, required

## Request body

- AuthRequest — Request for generating ISO-8583 message and sending it immediately to processing system of Enfuce.
  - `card` Card, required — Data of the card with which the transaction is done with.
    - `cardId` string, required — Unique ID of the card.
    - `applicationSelection` 'credit' | 'debit' — Describes what card application type was selected for the transaction (for combo cards). Possible values: * `credit` - the credit card must be used. * `debit` - the debit card must be used.
  - `transactionData` TransactionData, required
    - `transactionAmount` Money, required — Amount including currency
      - `amount` number
      - `currency` string — A valid ISO 4217 currency code
    - `settlementAmount` Money — Amount including currency
      - `amount` number
      - `currency` string — A valid ISO 4217 currency code
    - `transactionType` 'RETAIL' | 'CASH' | 'ATM' | 'CREDIT' | 'UNIQUE' | 'P2P_CREDIT' | 'P2P_DEBIT' | 'BALANCE_INQUIRY' | 'CASH_DISBURSEMENT', required — The transaction type. The only fully supported type is RETAIL. Other transaction types may be used, but no guarantees are made about their behaviour. Some transaction types have specific limitations: * `ATM` - In order to create ATM transactions, `merchantData.merchantCategoryCode` must be `6011`. This behaviour is downstream from the VISA and MC authorization systems. If a different code is used, transactions will be treated as `CASH`
    - `cardEntryMode` 'MANUAL_ENTRY' | 'MAGNETIC_STRIPE_READ' | 'CHIP_READ' | 'CONTACTLESS' | 'ELECTRONIC_COMMERCE', required — Describes how the card credentials were captured. Possible values: * `MANUAL_ENTRY` - the card credentials were manually entered by the merchant. * `MAGNETIC_STRIPE_READ` - the magnetic stripe of the card was read by a terminal. * `CHIP_READ` - the EMV chip of the card was read by a terminal * `CONTACTLESS` - contactless transactions, i.e. the card credentials were read with near field communication (NFC) either from chip or digital wallet. * `ELECTRONIC_COMMERCE` - the cardholder entered the card credentials as an e-com merchant.
  - `threeDsData` ThreeDsData
    - `authenticationValue` string — The cryptographic authentication value returned from 3DS authentication.
    - `eci` string — E-Commerce indicator representing the level of security and authentication achieved during the cardholder verification process
    - `dsTransactionId` string — Directory Server Transaction Id
    - `protocolVersion` '2.1.0' | '2.2.0' — 3DS protocol version
  - `merchantData` MerchantData, required
    - `merchantId` string, required — A code that uniquely identifies a particular card acceptor, i.e. a merchant or a bank.
    - `subMerchantId` string — A code that, when combined with the merchant and acquirer ids, uniquely identifies a particular card acceptor, i.e. a merchant or a bank.
    - `merchantName` string, required — Merchant name.
    - `merchantCity` string, required — The city where the transaction or withdrawal occurs.
    - `merchantCountry` string, required — A valid ISO 3166-1 alpha-3 country code, except for QZZ (UNMIK in Kosovo) and ROM for Romania.
    - `merchantCategoryCode` string, required — Merchant category code as per card scheme classification. Merchants classification is done based on the type of business or service they sell.
    - `acquirerId` string, required — This code identifies the financial institution acting as the acquirer for the merchant.
    - `acquirerCountry` string, required — A valid ISO 3166-1 alpha-3 country code, except for QZZ (UNMIK in Kosovo) and ROM for Romania.
    - `terminalId` string, required — A code that uniquely identifies a particular terminal at the merchant.
    - `partialApprovalCapable` boolean, required — Indicates if merchant will accept partial approval of amount. E.g. at a fuel pump the initial authorisation might be a predefined flat amount to which the issuer can respond an available amount smaller than the actual authorisation request. Note that this functionality is only available when card account balance resides at issuer.

## Response `200`

Authorization sent

- AuthResponse — Response on the authorisation request.
  - `metadata` object, required
    - `mti` string, required — Message type indicator for authorisation message.
    - `id` string, required — Unique identifier of authorisation request.
  - `transactionData` object, required
    - `authResponseCode` string, required — Response to the authorisation. Indicates to the merchant if the authorisation was approved or declined.
    - `retrievalReferenceNumber` string, required — Merchant/acquiring generated reference number for a purchase. Commonly used as the one of the main variables, in addition to cardId, to uniquely identify a transaction. Reference number is expected to remain the same for all messages during the transaction lifecycle (authorisation, clearing, reversals). This information can be used as one variable to match the authorisation message to purchase receipt data.

## Other responses

- `400` — Bad request
- `401` — Unauthorized
- `403` — Forbidden
- `404` — Not Found
- `500` — API is having problems

---

[API](https://skmtc.net/enfuce/apis/transfer-api.md) · [All operations](https://skmtc.net/enfuce/apis/transfer-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/enfuce/transfer-api/revisions/dc4a41118f80/schema)