Field Reference
Every field you can send to TransactDirect, and every field it sends back. This applies to the Checkout Page, Prepared Payments and the Payments API.
If you're getting started, follow the Checkout Page or Payments API guide first and come back here when you need the detail.
M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric
All request and response fields are case insensitive, and their casing may vary depending on the response type and TransactDirect version. Make sure your response handling doesn't depend on a specific casing.
Request fields
Send requests as a standard HTML form post (Content-Type: application/x-www-form-urlencoded). JSON and XML request bodies are not supported.
Mandatory fields
Send these on every request.
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| Amount | The transaction amount, numeric, in minor currency i.e. pence/cents etc. No decimal point. e.g. £10.02 = 1002 | M | 10 max. | N |
| ApiKey | The API Key used to authenticate transaction requests for this MerchantID. Required on direct Payments API requests. Never send it from a web page or on a Checkout Page redirect. | M* | 32 | A |
| CountryCode | ISO standard country code for merchant location. Use 826 for UK based merchants. Other options available on request. | M | 3 | N |
| CurrencyCode | ISO standard currency code of transaction. Use 826 for Sterling transactions. Other options available on request. | M | 3 | N |
| Dispatch | Used for Deferred Dispatch. Options are NOW or LATER. | M | 5 max. | A |
| MerchantID | Monek merchant ID. Test accounts are available on request. | M | 7 | N |
| MessageType | Indicates the transaction type for the request.See later table for acceptable message types. | M | V | A |
| ResponseAction | Specifies the return method for the transaction response data. Options are HTMLQS, XML, REDIRECT, or JSON | M | V | A |
* Payments API only.
ApiKey is replacing ValidityID and will be required for all direct server to server transaction requests. All new integrations should ensure ApiKey is populated in preparation for this change.
If you have already been issued a ValidityID you can continue to use this value as your ApiKey.
ApiKey and ValidityID must be kept private and should only be used on direct API calls. ApiKeyDigest will be available soon for use on public hosted page redirects.
Card details
Payments API only. On the Checkout Page the customer enters their card details on Monek's page, so you never send them. Sending card details directly requires PCI DSS accreditation.
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| CardNumber | Card number. | M | 20 max. | N |
| ExpiryMonth | Expiry month. | M | 2 | N |
| ExpiryYear | Expiry year. | M | 2 | N |
| ExpiryDate | Expiry date in MM/YY format. Can be supplied in place of ExpiryMonth and ExpiryYear. | M | 4 | N |
| StartMonth | Start month. | O | 2 | N |
| StartYear | Start year. | O | 2 | N |
| StartDate | Start date in MM/YY format. Can be supplied in place of StartMonth and StartYear. | O | 4 | N |
| CV2 | Card Verification Value normally printed after the card number on the card's magnetic strip. Note: The CV2 value must not be stored under any circumstances. | O | 3 or 4 | N |
M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric
Stored card fields
Send CrossReference in place of card details to charge, refund or complete a previous transaction. These requests must include your ApiKey. See Recurring Payments.
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| CrossReference | This is sent in lieu of the card details (card number, expiry month and year, start month and year) and is typically used for completing transactions that were originally submitted as Dispatch = LATER, processing referrals, re-billing or refunding previous transactions. | O | 50 max. | A |
3-D Secure fields
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| Ret3DSAddress | If ThreeDSAction = REDIRECT is used, this is the address (URL) to which the web client will be redirected with ACS information. The fields required to perform payer authentication are appended to this address as query string fields. | O | V | A |
| PurchaseDescription | Summary description of purchase. Passed to 3-D Secure. | O | 125 max. | A |
| ThreeDSAction | Used to indicate requirement of 3-D Secure processing and to tell TransactDirect which method to use for the return of ACS data. Options are: - NONE (default) - HTMLQS - XML - REDIRECT - ACSDIRECT | M | V | A |
| ThreeDSPAContinueOnError | Options are YES or NO (default).If set to YES, TransactDirect will allow a transaction to continue if an error occurred processing payer authentication details. | O | 2 or 3 | A |
| ThreeDSVEContinueOnError | Options are YES or NO (default). If set to YES, TransactDirect will allow a transaction to continue if an error occurred verifying card enrolment details. | O | 2 or 3 | A |
M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric
Cardholder fields
On the Checkout Page, any details you send are shown to the customer to confirm, and anything missing can be entered on the page.
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| CardholderName | Customer's name. Note: Mandatory for 3DS v2 transactions. | O | 30 max. | A |
| EmailAddress | Customer's email address. Note: email or phone number is mandatory for Visa 3-D Secure. | O | 50 max. | A |
| PhoneNumber | Customer's telephone number. Note: email or phone number is mandatory for Visa 3-D Secure. | O | 30 max. | A |
| BillingName | Customer's name for billing purposes. | O | 200 max. | A |
| BillingCompany | Company name for billing purposes. | O | 200 max. | A |
| BillingLine1 | Billing address line 1 | O | 200 max. | A |
| BillingLine2 | Billing address line 2 | O | 200 max. | A |
| BillingLine3 | Billing address line 3 | O | 200 max. | A |
| BillingCity | Billing city | O | 100 max. | A |
| BillingCounty | Billing county | O | 100 max. | A |
| BillingPostcode | The billing postcode | O | 20 max. | A |
| BillingCountry | The billing country name | O | 100 max. | A |
| BillingCountryCode | The 3 digit country code for billing country | O | 3 | A |
| DeliveryIsBilling | Indicates if the delivery address is also the billing address. YES or NO (default) | O | 3 | A |
| DeliveryName | Customer's name for delivery purposes. | O | 200 max. | A |
| DeliveryCompany | Company name for delivery purposes. | O | 200 max. | A |
| DeliveryLine1 | Delivery address line 1 | O | 200 max. | A |
| DeliveryLine2 | Delivery address line 2 | O | 200 max. | A |
| DeliveryLine3 | Delivery address line 3 | O | 200 max. | A |
| DeliveryCity | Delivery city | O | 100 max. | A |
| DeliveryCounty | Delivery county | O | 100 max. | A |
| DeliveryPostcode | The delivery postcode | O | 20 max. | A |
| DeliveryCountry | The delivery country name | O | 100 max. | A |
| DeliveryCountryCode | The 3 digit country code for delivery country | O | 3 | A |
M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric
Additional fields
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| AcceptCOF | Set by the merchant to confirm the cardholder has been informed and has accepted that their card details will be stored for future use, e.g. in your subscription terms. Options are YES or NO. To collect consent on the checkout page instead, use ShowSaveCard. Storing a card requests a 3-D Secure challenge. See Recurring Payments. | O | 2 or 3 | A |
| AuthorisationCode | Required when MessageType is prefixed with PAYMENT_ONLY_ (ignored if sent with any other MessageType) indicating that prior authorisation has been given by the merchant's acquiring bank. e.g. following a referral when the merchant has contacted the bank's voice authorisation centre. | O | 8 max. | A |
| Basket | Contains basket details for this transactions. Replaces Line Item structures noted in Accepting Amex. See Basket Details for further information. | O | 1000 max. | A |
| CAType | Specifies the type of cardholder agreement in place for the transaction. see Cardholder Agreement Types for details. | O | 15 max. | A |
| COFInitiatedBy | Indicates if a Credentials on File (COF) transaction was initiated by the cardholder or by the merchant. Options are CARDHOLDER or MERCHANT. | O | 10 max. | A |
| EchoReceiptInformation | Passes back all the information that a merchant needs to produce a customer's receipt. Options are YES or NO (default). If set to YES, the receipt information is returned as the additional field ReceiptInformation. | O | 2 or 3 | A |
| FailureUrl | If ResponseAction = REDIRECT is used, this is the address (URL) to which the web client will be redirected following an unsuccessful transaction. If not supplied SuccessUrl will be used for all responses. Replaces RetNotOkAddress. | O | V | A |
| IdempotencyToken | Specifies a merchant wide unique identifier for this transaction. Note: Use with caution. See Transaction Idempotency for details. Note: IdempotencyToken should be kept private and only used on direct API calls or Prepared Payments. | O | 50 max. | A |
| IntegritySecret | Provides a secret only known to the merchant. Used to support the Integrity Digest functionality | O | 50 max. | A |
| IsDebtRepayment | Indicates if the payment forms part of a debt repayment. Options are YES or NO (default). | O | 2 or 3 | A |
| OperatorId | The operator identifier for the user initiating this transaction. Used to allow a merchant to track which user initiated transactions. | O | 100 max. | A |
| OperatorName | The operator name for the user initiating this transaction. Used to allow a merchant to track which user initiated transactions. | O | 100 max. | A |
| OriginId | GUID used by Monek to provide additional insight and support for key integration partners and solutions. Contact Monek for more information | O | 40 max. | A |
| ProvisionNpt | Instructs the authorisation platform to provision a Network Payment Token for this transaction. Requires merchant enablement for Network Token support. Options are YES or NO (default). | O | 2 or 3 | A |
| RedirectUrl | If ResponseAction = REDIRECT is used, this is a single URL to which the web client will be redirected following any transaction result. The transaction result can be identified by the ResponseCode parameter. Typically used in place of the distinct SuccessUrl and FailureUrl redirect URLs. | O | V | A |
| SuccessUrl | If ResponseAction = REDIRECT is used, this is the address (URL) to which the web client will be redirected following a successful transaction. If FailureUrl is not specified SuccessUrl will be used for all results. Replaces RetOkAddress. | O | V | A |
| WebhookUrl | The secure URL (https) to send a transaction summary to on completion of the transaction. See Webhooks for more information. | O | 100 max. | A |
M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric
Merchant data fields
Additional merchant specific data should be sent in the PaymentDetail or MerchantData fields.
Use of these fields for merchant data ensures there are no clashes with fieldnames that may be required to support future functionality on the TransactDirect API.
These fields can be used to store a simple value, complex encoded data (such as JSON) or raw binary data (base64 encoded). When using plain text please be sure to remove all non-printable and control characters as these are prohibited.
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| PaymentReference | ID created by the merchant to identify the transaction. Replaces TransactionIdentifier. | O | 50 max. | A |
| PaymentChannel | Payment channel description as required by the merchant. | O | 50 max. | A |
| PaymentDetail | Additional custom payment details for this transaction. | O | 1500 max. | A/JSON/Base64 |
| MerchantData | Additional custom merchant data for this transaction. | O | 1500 max. | A/JSON/Base64 |
Base64 encoding supports the following key goals:
- Supports any underlying data format required by the merchant.
- Data can be returned unaltered without encoding complications.
- Ensures maximum compatibility with security mechanisms.
Please note that Base64 will require URL encoding, or you can use the Base64URL variant by applying the following changes.
- Replace + with -.
- Replace / with _.
- Remove any trailing = padding characters.
Checkout Page options
Fields that change what the customer sees on the Checkout Page, such as styling, Apple Pay, Google Pay and the save-card option, are listed on the Checkout Page guide.
Message types
MessageType sets the kind of transaction. All message types work with the Payments API; the Checkout Page column shows which can also be used there.
| MessageType | Checkout Page | Description |
|---|---|---|
ESALE_KEYED | Yes | E-Commerce (Internet) sale transaction, card keyed by cardholder. |
EVERIFY_KEYED | Yes | E-Commerce (Internet) account verification transaction, card keyed by cardholder. Note: Transaction amount must be ZERO (0). |
SALE_CNP_MO | Yes | Sale transaction, cardholder not present, mail order. Replaces SALE_CNP. |
SALE_CNP_TO | Yes | Sale transaction, cardholder not present, telephone order. Replaces SALE_CNP. |
VERIFY_CNP | No | Account verification transaction, cardholder not present (typically from call-centre i.e. telephone, mail order, etc.). Note: Transaction amount must be ZERO (0). |
SALE_CA | No | Sale transaction with continuous authority. |
REFUND_CNP | No | Refund transaction, cardholder not present (typically from call-centre or merchant back-office i.e. telephone, mail order, etc.). |
REVERSAL_KEYED | No | Reverses a previous transaction. Note: Must be performed by Cross Reference. Original transaction MUST be from same day. |
Notes:
- These transactions must include your
ApiKey:- Transactions using a
CrossReferencein place of card details. - Refunds and reversals.
- Transactions prefixed with
PAYMENT_ONLY_.
- Transactions using a
- Continuous authority (
SALE_CA) and other stored-card arrangements must be enabled on your account by Monek first. - Standard internet sales, such as purchases from a web site or online store, use
ESALE_KEYED. If the internet is only used to carry information from your systems to the gateway, use the matching cardholder present or not present message type. - Apple Pay, Google Pay and PayPal are only available for e-commerce message types.
Payment only transactions
TransactDirect Message Types can be prefixed with PAYMENT_ONLY_ to indicate that no authorisation is required. Such transactions are not forwarded to the bank for authorisation and are sent for settlement on the assumption that the merchant has obtained authorisation from some other source. Typical scenarios where this may be appropriate are:
- The original transaction resulted in a referral and the settlement confirmation is being sent following a call to the bank's voice authorisation centre.
- When presenting transactions to TransactDirect following a period of communications failure.
- Where the original transaction was sent as
DISPATCH = LATERand is now ready for settlement.
The following standard fields have particular importance for a PAYMENT_ONLY_ transaction:
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| AuthorisationCode | Must contain the authorisation code obtained during the referral process or original authorisation. | M | 8 max. | A |
| CrossReference | When processing a PAYMENT_ONLY_ request following an authorisation only or referral transaction the CrossReference from the original transaction should always be used.Not required when a presenting an offline transaction following a period of communications failure. In this scenario the full card details would be required. | O | 50 max. | A |
| ApiKey | Required. Your API key authenticates the transaction. Keep it private and only use it on direct API calls. | M | 32 | A |
Cardholder Agreement Types
TransactDirect allows a transaction to be identified as part of a continuous authority agreement with the cardholder.
This should be specified as appropriate in the CAType field in the transaction request for the initiating transaction and all subsequent payment requests.
| CA Type | Usage | Description |
|---|---|---|
A or Reauthorisation | Additional Only | Indicates a reauthorisation made after the original purchase. Common scenarios include delayed/split shipments and extended stays/rentals. |
C or Unscheduled | Additional Only | Indicates a transaction using a stored credential for a fixed or variable amount that does not occur on a scheduled or regularly occurring transaction date. This includes account top-ups triggered by balance thresholds. |
D or Delayed | Additional Only | Indicates a delayed charge. Typically used in hotels, cruise lines and vehicle rental environments to perform a supplemental account charge after original services are rendered. |
I or Instalment | Initiating or Additional | Indicates that this transaction is part of an instalment agreement. Instalment transactions should be used to charge a predictable amount at regular intervals. |
L or Incremental | Additional Only | Indicates an incremental authorisation. Typically found in hotel and car rental environments, where the cardholder has agreed to pay for any service incurred during the duration of the contract. |
N or NA | Initiating or Additional | Indicates that no specific cardholder agreement is in place. |
R or Recurring | Initiating or Additional | Indicates that this transaction is part of a recurring agreement. Recurring payment transactions may be recharged as required by the merchant to satisfy future purchases. Note: For PayPal Express Checkout integrations this must be set to indicate the requirement for a PayPal recurring payment billing agreement. |
S or Resubmission | Additional Only | Indicates a resubmission for a transaction that occurred with the original purchase, but where the card acceptor was not able to get authorisation at the time the goods or services were provided. |
X or NoShow | Additional Only | Indicates a transaction where the cardholder entered into an agreement to purchase but did not meet the terms of the agreement. |
Common Currency Codes
| Currency | ISO-4217 Code |
|---|---|
| Australian Dollar | 036 |
| Canadian Dollar | 124 |
| Czech Koruna | 203 |
| Danish Krone | 208 |
| Hong Kong Dollars | 344 |
| Icelandic Krona | 352 |
| Japanese Yen | 392 |
| Norwegian Krone | 578 |
| Singapore Dollars | 702 |
| Swedish Krona | 752 |
| Swiss Franc | 756 |
| Pound Sterling | 826 |
| US Dollars | 840 |
| Euro | 978 |
Note:
- Multi-currency processing must be enabled on your account before you accept other currencies.
- Certain acquirers will require separate merchant numbers to be issued.
- Not all acquirers accept all of these currencies whilst some accept many more.
- Multi-currency transactions must be identified by their numeric three-digit currency code, as per ISO-4217.
Response fields
Response formats
The response format will depend on the ResponseAction requested when initiating the transaction.
- JSON
- HTMLQS
- XML
- REDIRECT
If the ResponseAction field was set to JSON the response fields are sent to the client as a JSON formatted structure. The new JSON return format is recommended and contains a much richer level of details for the completed transaction.
{
"transactionDateTime": "2024-04-01T10:11:12.9798042+01:00",
"requestDateTime": "2024-04-01T10:11:12.4217561+01:00",
"amount": "2500",
"currencyCode": "826",
"countryCode": "826",
"result": {
"paymentMethod": "TransactDirect",
"crossReference": "240401101112457459X2R",
"responseCode": "00",
"responseMessage": "AUTHCODE:457459",
"authorisationCode": "457459",
"avsCv2Code": "244100",
"avsCv2Message": "SECURITY CODE MATCH ONLY",
"threeDSecure": {
"enrolled": "Y",
"authenticated": "Y",
"eci": "05",
"cavv": "AAACAkl2BRkiFiFSYHYFEwAAAAA=",
"transactionId": "83726342788159100000"
},
"terminalId": "22080001",
"messageNumber": "2903"
},
"merchant": {
"monekId": "0000893",
"merchantNumber": "123456789",
"name": "Monek Test Account",
"location": "Lichfield"
},
"cardholder": {
"address": "155",
"postcode": "16"
},
"card": {
"maskedCard": "401200******1112",
"expiryDate": "2412",
"cardType": "VC",
"cardDescription": "Visa Credit"
}
}
If the ResponseAction field was set to HTMLQS the response fields are sent to the client as a list of field names and values in the body of the HTTP response. e.g.
ResponseCode=00&Message=AUTHCODE:01223&CrossReference=03050711535801223303
If the ResponseAction field was set to XML the response fields are sent to the client as XML 1.0 formatted tags and values. e.g.
<?xml version="1.0" ?>
<transactionresponse>
<responsecode>00</responsecode>
<message>AUTHCODE:06166</message>
<crossreference>03050711584106166163</crossreference>
</transactionresponse>
If the ResponseAction field was set to REDIRECT TransactDirect issues a redirect to the web client with the response fields sent as query string attachments to the redirect URL e.g.
http://www.myURL.com/SuccessUrl.asp?ResponseCode=00&Message=AUTHCODE%3A01223&CrossReference=03050711535801223303
Redirecting to the RetOKAddress or RetNotOKAddress depends upon the transaction outcome:
| Transaction Outcome | Redirection URL |
|---|---|
| Successful transaction | SuccessUrl |
| Card referred | FailureUrl |
| Card declined | FailureUrl |
| Problem with card. e.g. invalid card number, expired card, etc. | FailureUrl |
| Processing error | FailureUrl |
Standard Response Fields
The result of the transaction is passed back in the following fields.
| Field Name | Contents | Size | Type |
|---|---|---|---|
| Amount | Amount sent with transaction request to acquiring bank or, in the event of a payment only transaction, accepted by TransactDirect. Value returned in minor currency i.e. pence/cents etc. | 10 max. | N |
| AuthorisationCode | The authorisation code issued for a successful transaction. Normally this is 2 digits for American Express and 6 for other card schemes. Note: An authorisation code is strictly alphanumeric. While typically numeric an authorisation code may also contain letters. | 2-8 | A |
| AVSCV2Check | AVS/CV2 check response. See following table. | 30 max. | A |
| AVSCV2ResponseCode | The raw AVS/CV2 code returned by the acquiring bank. See following tables. | 6 | N |
| CardType | The card type code indicating the card type used for the transaction. See following table. | 2 | A |
| CrossReference | The unique character string returned by TransactDirect to identify this transaction. | 50 max. | A |
| CurrencyCode | The currency code used for the transaction. | 3 | N |
| DuplicateIndicator | Contains the reason for a duplicate transaction response. DUPLICATE or IDEMPOTENCY | 20 max. | A |
| ErrorCode | May contain an additional error detail code where standard response code indicate and error "30". This code can be used by Monek to further diagnose the cause of an error. | 4 | N |
| Message | The transaction message either as delivered by the bank or by TransactDirect. This is the message that should be displayed to the merchant on an EPOS system or call centre application and to the cardholder on an Internet web site implementation. Typical examples are: AUTHCODE:123456 CARD EXPIRED CARD REFERRED CARD DECLINED CARD DECLINED – KEEP CARD AVS CV2 DECLINED ERROR XXXX | 80 max. | A |
| PaymentMethod | The payment method used to process the transaction: TransactDirect or PayPal | 50 max. | A |
| ReferralTelephoneNumber | The referral telephone number passed to TransactDirect by the merchant's acquirer in the event of a transaction being referred. Note: In most circumstances the merchants will have been provided with a standard referral telephone number by their acquiring bank and should primarily use that number in the event of a referral. | 16 max. | N |
| RequestTime | The time the transaction request was initiated in ISO 8601 format. | 33 | A |
| ResponseCode | The TransactDirect response code. See following table. | 2 | N |
| TrackingToken | A unique tracking token for the payment card used. Note: Only returned by prior partner arrangement. | 32 | A |
Response Code Values
| Response Code | Description |
|---|---|
| 00 | Transaction successful / authorised |
| 02 | Card referred |
| 03 | Retailer unknown |
| 04 | Keep card decline |
| 05 | Card declined |
| 11 | Invalid card details |
| 12 | Invalid request |
| 30 | Exception |
AVS/CV2 Response Values
AVS/CV2 Response Code Values
The AVS/CV2 Response Code is made up of six characters and is sent back in the raw form that is received from the acquiring bank.
- Position 1
- Position 2
- Position 3
- Position 4
- Position 5
- Position 6
| Position 1 Value | Position 1 Description |
|---|---|
| 0 | No additional information available |
| 1 | CV2 not checked |
| 2 | CV2 matched |
| 4 | CV2 not matched |
| 8 | Reserved |
| Position 2 Value | Position 2 Description |
|---|---|
| 0 | No additional information available |
| 1 | Postcode not checked |
| 2 | Postcode matched |
| 4 | Postcode not matched |
| 8 | Postcode partially matched |
| Position 3 Value | Position 3 Description |
|---|---|
| 0 | No additional information available |
| 1 | Address not checked |
| 2 | Address matched |
| 4 | Address not matched |
| 8 | Address partially matched |
| Position 4 Value | Position 4 Description |
|---|---|
| 0 | Authorising entity not known |
| 1 | Authorising entity – Merchant host |
| 2 | Authorising entity – Acquirer host |
| 4 | Authorising entity – Card Scheme |
| 8 | Authorising entity – Issuer |
| Position 5 Value | Position 5 Description |
|---|---|
| 0 | Reserved |
| 1 | Reserved |
| 2 | Reserved |
| 4 | Reserved |
| 8 | Reserved |
| Position 6 Value | Position 6 Description |
|---|---|
| 0 | Reserved |
| 1 | Reserved |
| 2 | Reserved |
| 4 | Reserved |
| 8 | Reserved |
Note:
- Values other than 0, 1, 2, 4 or 8 are not valid in character positions 1 to 4.
- A value of zero in any character position indicates that no additional information is available.
- If the Authorising Entity is not known, then character position 4 is set to zero and the authoriser is assumed to be the issuer.
AVS/CV2 Check Response Values
AVS and CV2 checks are supported by most major card issuers including Visa, MasterCard, Maestro and American Express.
| AVS / CV2 Response Message | Description |
|---|---|
| ALL MATCH | AVS and CV2 match. |
| SECURITY CODE MATCH ONLY | CV2 match only. |
| ADDRESS MATCH ONLY | AVS match only. |
| NO DATA MATCHES | No matches for AVS and CV2. |
| DATA NOT CHECKED | Supplied data not checked. |
| SECURITY CHECKS NOT SUPPORTED | Card scheme does not support checks. |
| UNKNOWN RESPONSE | Unrecognised AVS/CV2 response from issuer. |
As part of the AVS/CV2 design, responses are passed back along with the authorisation outcome. This can result in a situation where the transaction has been authorised by the card issuer, but the AVS/CV2 checks have returned negative results. At this point, the merchant may decide not to proceed with the transaction. In these circumstances, under normal UK banking practice, a merchant would need to cancel, reverse or refund the transaction. This is often not practical to achieve in situations where the merchant is not present for the transaction, such as Internet retailers.
TransactDirect removes the necessity for the merchant to explicitly carry out the cancellation, reversal or refund by providing the merchant with AVS/CV2 acceptance parameters governing what action to take dependent upon the AVS/CV2 result.
Card Type Values
The following card type codes are currently supported. This list is subject to change as new card types are added.
| Card Type Code | Card Type |
|---|---|
| AM | American Express |
| DI | Diners Club |
| DS | Discover |
| EL | Electron |
| JC | JCB |
| MA | Maestro (International) |
| MC | MasterCard |
| MD | MasterCard Debit |
| SW | Maestro (UK issued) |
| VC | Visa Credit |
| VD | Visa Debit |
| VP | Visa Purchasing |
3-D Secure Result Fields
| Field Name | Description | Size |
|---|---|---|
| Emv3DS | The EMV 3-D Secure details as returned from the authentication process. Comma separated. | 150 max. |
| ThreeDS | The 3-D Secure details as returned from the verify enrolment and payer authentication stages. Comma separated in Monek 2.1 compliant form. | 60 max. |
| ThreeDSErrorCode | Code issued by 3-D Secure if either enrolment verification or 3-D Secure authentication failed with an error. | V |
| ThreeDSErrorDetail | Error description issued by 3-D Secure if either enrolment verification or 3-D Secure authentication failed with an error. | V |
Structure of the Emv3DS Information field
The Emv3DS information field is comma delimited list with the following fields
| No | Field Name and Contents | Req'd | Size | Type |
|---|---|---|---|---|
| 1 | EMV 3-D Secure Status | M | 1 | A |
| 2 | 3-D Secure Version used. e.g. 2.2.0 | M | 10 max. | A |
| 3 | ECI | M | 2 | A |
| 4 | CAVV | M | 32 max. | A |
| 5 | Directory Server Transaction Identifier | M | 36 | Guid |
| 6 | Monek 3-D Secure Transaction Reference | M | 36 | Guid |
Note: The number of fields in these structures are variable. Please ensure any field validation is tolerant.
Receipt Information
| Field Name | Description | Size |
|---|---|---|
| ReceiptInformation | This returns all the information that a merchant needs to produce a customer receipt. Please contact Monek to enable this facility. Returned if transaction request field EchoReceiptInformation was set to YES. Not returned if TransactDirect ResponseCode = 30 | 387 max. |
Structure of the Receipt Information field
| No | Field Name and Contents | Req'd | Size | Type |
|---|---|---|---|---|
| 1 | Bank Merchant Number | M | 15 max. | A |
| 2 | Unit Separator US – ASCII character code 31 | M | 1 | |
| 3 | Card Type Description | M | 50 max. | A |
| 4 | Unit Separator US | M | 1 | |
| 5 | Merchant Name | M | 50 max. | A |
| 6 | Unit Separator US | M | 1 | |
| 7 | Merchant Location | M | 50 max. | A |
| 8 | Unit Separator US | M | 1 | |
| 9 | Date – "YYMMDD" | M | 6 | N |
| 10 | Unit Separator US | M | 1 | |
| 11 | Time – "HHMM" | M | 4 | N |
| 12 | Unit Separator US | M | 1 | |
| 13 | Transaction Type | M | 20 max. | A |
| 14 | Unit Separator US | M | 1 | |
| 15 | Card Number – First 4 and last 4 digits | M | 20 max. | N |
| 16 | Unit Separator US | M | 1 | |
| 17 | Start Date – "YYMM" | O | 0 or 4 | N |
| 18 | Unit Separator US | M | 1 | |
| 19 | Expiry Date – "YYMM" | M | 4 | N |
| 20 | Unit Separator US | M | 1 | |
| 21 | Issue Number (discontinued) | O | n/a | N |
| 22 | Unit Separator US | M | 1 | |
| 23 | Card Details Entry Method | M | 20 max. | A |
| 24 | Unit Separator US | M | 1 | |
| 25 | Terminal Identifier | M | 8 | N |
| 26 | Unit Separator US | M | 1 | |
| 27 | Message Number | M | 4 | N |
| 28 | Unit Separator US | M | 1 | |
| 29 | Response Message Text | M | 80 max. | A |
| 30 | Unit Separator US | M | 1 | |
| 31 | Transaction Amount – minor currency units | M | 11 max. | N |
| 32 | Unit Separator US | M | 1 | |
| 33 | Cashback Amount - minor currency units | O | 11 max. | N |
| 34 | Unit Separator US | M | 1 | |
| 35 | Gratuity Amount - minor currency units | O | 11 max. | N |
M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric
Legacy fields
These fields are still accepted so existing integrations keep working. Don't use them in new integrations.
Legacy request fields
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| ValidityID | Is used by TransactDirect in conjunction with MerchantID to provide additional security. ValidityID will be issued by Monek and can be used to authenticate repeat transactions and refunds performed by Cross Reference. Note: ValidityID must be kept private and should only be used on direct API calls. Do not use on hosted page redirects. | M/O | 50 max. | A |
| CardToken | This is sent in lieu of the card details (card number, expiry month and year, start month and year) and can be used for reprocessing a stored card. e.g. For continuous authority. Note: Deprecated in favour of CrossReference. | O | 50 max. | A |
| DispatchLaterAmount | The total amount of the transaction. Numeric, minor currency i.e. pence/cents etc. No decimal point e.g. £10.02 = 1002 Note: Deprecated. Dispatch later transaction should authorise for the full amount or utilise Account Verification. | M | 10 Max | N |
| QAAddress | Required for AVS check. Customer's address. | O | 100 max. | A |
| QAPostcode | Required for AVS check. Customer's postcode. | O | 10 max. | A |
ValidityIDis replaced byApiKey. If you were issued aValidityID, you can use the same value as yourApiKey.CardTokenis replaced byCrossReference.QAAddressandQAPostcodeare replaced by the Cardholder fields (BillingLine1,BillingPostcodeand so on).
Legacy response fields
| Field Name | Contents | Size | Type |
|---|---|---|---|
| CardToken | The unique character string returned by TransactDirect to identify this card. Optional: Will be returned where the merchant is configured to support card tokens. | 50 max. | A |
Structure of the ThreeDS Information field
The ThreeDS information field is comma delimited list with the following fields
This field is deprecated with the introduction of EMV 3-D Secure and the Emv3DS response field.
For compatibility, 3-D Secure v1 compliant codes will always be returned for Enrolled and Authenticated fields when 3-D Secure v2 is used.
| No | Field Name and Contents | Req'd | Size | Type |
|---|---|---|---|---|
| 1 | Enrolled | M | 1 | A |
| 2 | Authenticated | M | 1 | A |
| 3 | ECI | M | 2 | N |
| 4 | CAVV | M | 32 max. | A |
| 5 | Transaction Identifier | M | 20 | N |
Note: The number of fields in these structures are variable. Please ensure any field validation is tolerant.
Secure Hosting card link fields
For merchant migrating from Secure Hosting TransactDirect provides the facility to directly reference previous transactions by their Secure Hosting Transaction ID.
Transaction responses will include a new TransactDirect CrossReference which should then be used for all future processing.
| Field Name | Description | Req'd | Size | Type |
|---|---|---|---|---|
| shReference | Your Secure Hosting account reference number e.g. SH212345 | O | 8 | A |
| shCheckCode | Your Secure Hosting Check Code. This can be found in the settings menu in your Secure Hosting account. | O | 6 | N |
| shTransactionId | The numeric Transaction ID of the Secure Hosting transaction you wish to recharge or refund | O | 10 max. | N |
Custom form fields
Support for additional form or query string fields sent to TransactDirect using custom names has been removed. Please use the PaymentDetail or MerchantData fields.