Skip to main content

Checkout Page

Methods of Operation

The TransactDirect Checkout Page allows merchants to secure process eCommerce web transactions directly with Monek. Primary use cases for this are:

  • Website checkout pages from merchant web sites and shopping carts.
  • Payment page integration into call centre systems and desktop software solutions.

For merchants processing additional transactions and refunds, or PCI:DSS accredited merchants requiring more control of the payment journey see our Payments API documentation.

Gateway URLs

Note: Both gateways are LIVE and will process for all Monek Merchant accounts.

The staging API is available for integration and compatibility testing of new features before they are available on the primary platform.

The TransactDirect Checkout Page supports a number of features we recommend for additional security and convenience:

  • Prepared Payments provide a secure way to protect merchant and transaction details with a simple redirect token.
  • Idempotency Tokens provide a reliable way to protect against against duplicate transactions and replay events.
  • The Integrity Digest provides a secure method to verify that responses, redirects, and webhooks are genuine and unmodified.
  • Webhooks provide a simple notification service for transaction results without relying on the cardholder transaction flow.
  • Basket Details provides an updated and flexible method of sending itemised basket details for your transaction that also satisfies required transaction details for American Express.

Sequence of Events

The following is a typical sequence of events whereby transaction request data is securely sent to TransactDirect and the cardholder processes their transaction through the Monek Checkout page.

Step 1: Merchants sends transaction request data to TransactDirect

The merchant sends a transaction initiation request to https://elite.monek.com/Secure/iPayPrepare.ashx to obtain a Prepared Payment Token.

Step 2: Merchant web site redirects cardholder to the Checkout page

The merchant web site or shopping card redirects the cardholder to the Monek Checkout Page https://elite.monek.com/Secure/Checkout.aspx using the Prepared Payment Token from Step 1. The redirect supports both HTTP POST and HTTP GET and is suitable for use within an iFrame.

The cardholder fills out their payment details and the Checkout page submits directly to TransactDirect.

Step 3: EMV 3-D Secure authentication

On receiving payment card details from the cardholder TransactDirect will perform a 3-D Secure authentication check with the cardholders card issuing bank.

  • If the card issuing bank authorises the transaction for a 'Frictionless Flow' the transaction will proceed directly to authorisation, Step 4.

  • If the card issuing bank indicates a 'Challenge Flow' is required the cardholder will be redirected to their bank's 3-D Secure authentication page to perform this step with the result sent back to TransactDirect automatically.

tip

The ThreeDSAction method ACSDIRECT provides for the simplest implementation of 3-D Secure and requires no additional coding as the redirect and response handling is automated by TransactDirect

Step 4: Authorisation and response

TransactDirect will authorise the provided transaction, including 3-D Secure details, and respond dependent upon the value of the ResponseAction request field:

If the ResponseAction field was set to REDIRECT TransactDirect issues a redirect to the web client, redirecting it to the SuccessUrl or FailureUrl depending upon the transaction outcome, with the response fields sent as query string attachments to the redirect URL e.g.

http://www.myURL.com/success.asp?ResponseCode=00&Message=AUTHCODE%3A01223&CrossReference=03050711535801223303

Transaction Request

The passing of data to TransactDirect's iPayPrepare.ashx, iPay.aspx, or Checkout.aspx is accomplished using HTML form fields or query strings. To provide the most secure implementation please use the Prepared Payments feature to ensure all key transaction configuration is kept private.

The following tables detail the HTML form fields that are used to pass transaction data to TransactDirect. Every transaction that is passed to TransactDirect must include those fields listed in the 'Mandatory Generic Transaction Request Fields' table.

Mandatory Generic Transaction Request Fields

Field NameDescriptionReq'dSizeType
AmountThe transaction amount, numeric, in minor currency i.e. pence/cents etc. No decimal point. e.g. £10.02 = 1002M10 max.N
CountryCodeISO standard country code for merchant location. Use 826 for UK based merchants. Other options available on request.M3N
CurrencyCodeISO standard currency code of transaction. Use 826 for Sterling transactions. Other options available on request.M3N
DispatchUsed for Deferred Dispatch. Options are NOW or LATER.M5 max.A
MerchantIDMonek merchant ID. Test accounts are available on request.M7N
MessageTypeIndicates the transaction type for the request.See later table for acceptable message types.MVA
ResponseActionSpecifies the return method for the transaction response data. Options are HTMLQS, XML, REDIRECT, or JSONMVA

M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric

3-D Secure Transaction Request Fields

Field NameDescriptionReq'dSizeType
Ret3DSAddressIf 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.OVA
PurchaseDescriptionSummary description of purchase. Passed to 3-D Secure.O125 max.A
ThreeDSActionUsed 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
MVA
ThreeDSPAContinueOnErrorOptions are YES or NO (default).
If set to YES, TransactDirect will allow a transaction to continue if an error occurred processing payer authentication details.
O2 or 3A
ThreeDSVEContinueOnErrorOptions are YES or NO (default).
If set to YES, TransactDirect will allow a transaction to continue if an error occurred verifying card enrolment details.
O2 or 3A

M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric

Cardholder Detail Request Fields

Cardholder data fields can be collected on the Checkout page, supplied by the merchant, or both. Where details are supplied by the merchant they will be presented for confirmation on the Checkout page if the appropriate fields are included on the page.

Field NameDescriptionReq'dSizeType
CardholderNameCustomer's name. Note: Mandatory for 3DS v2 transactions.O30 max.A
QAAddressRequired for AVS check. Customer's address. Note: Deprecated in favour of Billing fields.O100 max.A
QAPostcodeRequired for AVS check. Customer's postcode. Note: Deprecated in favour of Billing fields.O10 max.A
EmailAddressCustomer's email address. Note: email or phone number is mandatory for Visa 3-D Secure.O50 max.A
PhoneNumberCustomer's telephone number. Note: email or phone number is mandatory for Visa 3-D Secure.O30 max.A
BillingNameCustomer's name for billing purposes.O200 max.A
BillingCompanyCompany name for billing purposes.O200 max.A
BillingLine1Billing address line 1O200 max.A
BillingLine2Billing address line 2O200 max.A
BillingLine3Billing address line 3O200 max.A
BillingCityBilling cityO100 max.A
BillingCountyBilling countyO100 max.A
BillingPostcodeThe billing postcodeO20 max.A
BillingCountryThe billing country nameO100 max.A
BillingCountryCodeThe 3 digit country code for billing countryO3A
DeliveryIsBillingIndicates if the delivery address is also the billing address. YES or NO (default)O3A
DeliveryNameCustomer's name for delivery purposes.O200 max.A
DeliveryCompanyCompany name for delivery purposes.O200 max.A
DeliveryLine1Delivery address line 1O200 max.A
DeliveryLine2Delivery address line 2O200 max.A
DeliveryLine3Delivery address line 3O200 max.A
DeliveryCityDelivery cityO100 max.A
DeliveryCountyDelivery countyO100 max.A
DeliveryPostcodeThe delivery postcodeO20 max.A
DeliveryCountryThe delivery country nameO100 max.A
DeliveryCountryCodeThe 3 digit country code for delivery countryO3A

M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric

Additional Transaction Request Fields

Field NameDescriptionReq'dSizeType
AcceptCOFIndicates if the cardholder has been informed and has accepted that their card details will be stored for future use. Options are YES or NO (default).O2 or 3A
BasketContains basket details for this transactions. Replaces Line Item structures noted in Accepting Amex. See Basket Details for further infomation.O1000 max.A
CATypeSpecifies the type of cardholder agreement in place for the transaction. see Cardholder Agreement Types for details.O15 max.A
DispatchLaterAmountThe 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.
M10 MaxN
EchoReceiptInformationPasses 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.O2 or 3A
FailureUrlIf 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.OVA
IdempotencyTokenSpecifies 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.
O50 max.A
IntegritySecretProvides a secret only known to the merchant. Used to support the Integrity Digest functionalityO50 max.A
IsDebtRepaymentIndicates if the payment forms part of a debt repayment. Options are YES or NO (default).O2 or 3A
OperatorIdThe operator identifier for the user intiating this transaction. Used to allow a merchant to track which user initiated transactions.O100 max.A
OperatorNameThe operator name for the user initiating this transaction. Used to allow a merchant to track which user initiated transactions.O100 max.A
OriginIdGUID used by Monek to provide additional insight and support for key integration partners and solutions. Contact Monek for more informationO40 max.A
SuccessUrlIf 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.OVA

M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric

Additional Form Fields

Additional merchant specific data should be sent in the PaymentDetail or MerchantData field.

Use of this field for merchant data ensures there are no clashes with fieldnames that may be required to support future functionality on the TransactDirect API.

This field can be used to store a simple value, complex encoded data (such as JSON) or raw binary data. In all cases the supplied value should be Base64 encoded.

Field NameDescriptionReq'dSizeType
PaymentReferenceID created by the merchant to identify the transaction. Replaces TransactionIdentifier.O50 max.A
PaymentChannelPayment channel description as required by the merchant.O50 max.A
PaymentDetailAdditional custom payment details for this transaction.O500 max.A
MerchantDataAdditional custom merchant data for this transaction.O1024maxBase 64

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.

Additional Form Fields – Legacy Functionality

warning

Support for additional form or query string fields sent to TransactDirect using custom names has been removed. Please use the PaymentDetail or MerchantData fields.

Page Configuration Fields

Checkout Page supports some third party alternative checkout options.

Any configurable third party checkout options will be listed here with a brief description of how they work and how to integrate them.

Field NameDescriptionReq'dSizeType
ShowGooglePayIndicates if the Google Pay™ button will appear on the checkout page. YES or NO (default) All merchants must adhere to the Google Pay APIs Acceptable Use Policy and accept the terms defined in the Google Pay API Terms of Service. Google Pay is a trademark of Google LLC.O3A
ShowApplePayIndicates if the Apple Pay button will appear on the checkout page. YES (default) or NOO3A
ShowPayPalIndicates if the Pay Pal button will appear on the checkout page. YES or NO (default)O3A
ShowAddressDetailsIndicates whether the address details will be shown on the checkout page. YES (default) or NOO3A
ShowDeliveryAddressIndicates whether the delivery address will be shown on the checkout page. YES or NO (default)O3A
ShowSaveCardIndicates whether an option to save the card for future use will be shown on the checkout page. YES or NO (default)O3A

M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric

TransactDirect Message Types

MessageTypeDescription
ESALE_KEYEDE-Commerce (Internet) sale transaction, card keyed by cardholder.
EVERIFY_KEYEDE-Commerce (Internet) account verification transaction, card keyed by cardholder. Note: Transaction amount must be ZERO (0).
SALE_CNP_MOSale transaction, cardholder not present, mail order. Replaces SALE_CNP. Suitable for use with VT implementations.
SALE_CNP_TOSale transaction, cardholder not present, telephone order. Replaces SALE_CNP. Suitable for use with VT implementations.

Notes:

  • Other transaction message types are available on TransactDirect but are not appropriate for use with the Checkout Page, see Payment API for additional processing capabilities.

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 TypeUsageDescription
A or ReauthorisationAdditional OnlyIndicates a reauthorisation made after the original purchase. Common scenarios include delayed/split shipments and extended stays/rentals.
C or UnscheduledAdditional OnlyIndicates 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 DelayedAdditional OnlyIndicates 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 InstalmentInitiating or AdditionalIndicates that this transaction is part of an instalment agreement. Instalment transactions should be used to charge a predictable amount at regular intervals.
L or IncrementalAdditional OnlyIndicates 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 NAInitiating or AdditionalIndicates that no specific cardholder agreement is in place.
R or RecurringInitiating or AdditionalIndicates 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 ResubmissionAdditional OnlyIndicates 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 NoShowAdditional OnlyIndicates a transaction where the cardholder entered into an agreement to purchase but did not meet the terms of the agreement.

Common Currency Codes

CurrencyISO-4217 Code
Australian Dollar036
Canadian Dollar124
Czech Koruna203
Danish Krone208
Hong Kong Dollars344
Icelandic Krona352
Japanese Yen392
Norwegian Krone578
Singapore Dollars702
Swedish Krona752
Swiss Franc756
Pound Sterling826
US Dollars840
Euro978

Note:

  • Merchants must have obtained prior clearance from their UK acquiring bank (acquirer) before accepting multi-currency transactions.
  • 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.

3-D Secure API Response

tip

The ThreeDSAction method ACSDIRECT provides for the simplest implementation of 3-D Secure and requires no additional coding as the redirect and response handling is automated by TransactDirect.

If the ThreeDSAction field was set to ACSDIRECT then TransactDirect will automatically perform the 3-D Secure check, redirecting the cardholder through the authentication process as required, and completing the transaction as appropriate.

For all other ThreeDSAction modes of operation please refer to the relevent section in Payments API.

Transaction Response

warning

Please note that all request and response fields are considered case insensitive and may vary depending on response type and TransactDirect version.

Please ensure any response handling does not limit field processing to a specific character casing.

The response format will depend on the ResponseAction requested when initiating the transaction. REDIRECT is typically the appropriate choice when processing transactions using the Checkout Page.

Additional security and information flow can be achieved using additional features of TransactDirect:

  • Prepared Payments provide a secure way to protect merchant and transaction details with a simple redirect token.
  • Idempotency Tokens provide a reliable way to protect against against duplicate transactions and replay events.
  • The Integrity Digest provides a secure method to verify that responses, redirects, and webhooks are genuine and unmodified.
  • Webhooks provide a simple notification service for transaction results without relying on the cardholder transaction flow.

If the ResponseAction field was set to REDIRECT TransactDirect issues a re-direct 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 OutcomeRedirection URL
Successful transactionSuccessUrl
Card referredFailureUrl
Card declinedFailureUrl
Problem with card. e.g. invalid card number, expired card, etc.FailureUrl
Processing errorFailureUrl

Standard Response Fields

The result of the transaction is passed back in the following fields.

Field NameContentsSizeType
AmountAmount 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
AuthorisationCodeThe 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-8A
AVSCV2CheckAVS/CV2 check response. See following table.30 max.A
AVSCV2ResponseCodeThe raw AVS/CV2 code returned by the acquiring bank. See following tables.6N
CardTokenThe unique character string supplied by TransactDirect to identify this card. Optional: Will be returned where the merchant is configured to support card tokens.50 max.A
CardTypeThe card type code indicating the card type used for the transaction. See following table.2A
CrossReferenceThe unique character string supplied by TransactDirect to identify this transaction.50 max.A
CurrencyCodeThe currency code used for the transaction.3N
DuplicateIndicatorContains the reason for a duplicate transaction response. DUPLICATE or IDEMPOTENCY20 max.A
ErrorCodeMay 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.4N
MessageThe 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
PaymentMethodThe payment method used to process the transaction: TransactDirect or PayPal50 max.A
ReferralTelephoneNumberThe 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
RequestTimeThe time the transaction request was initiated in ISO 8601 format.33A
ResponseCodeThe TransactDirect response code. See following table.2N
TrackingTokenA unique tracking token for the payment card used. Note: Only returned by prior partner arrangement.32A

M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric

Response Code Values

Response CodeDescription
00Transaction successful / authorised
02Card referred
03Retailer unknown
04Keep card decline
05Card declined
11Invalid card details
12Invalid request
30Exception

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 ValuePosition 1 Description
0No additional information available
1CV2 not checked
2CV2 matched
4CV2 not matched
8Reserved

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 MessageDescription
ALL MATCHAVS and CV2 match.
SECURITY CODE MATCH ONLYCV2 match only.
ADDRESS MATCH ONLYAVS match only.
NO DATA MATCHESNo matches for AVS and CV2.
DATA NOT CHECKEDSupplied data not checked.
SECURITY CHECKS NOT SUPPORTEDCard scheme does not support checks.
UNKNOWN RESPONSEUnrecognised 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 CodeCard Type
AMAmerican Express
DIDiners Club
DSDiscover
ELElectron
JCJCB
MAMaestro (International)
MCMasterCard
MDMasterCard Debit
SWMaestro (UK issued)
VCVisa Credit
VDVisa Debit
VPVisa Purchasing

3-D Secure Result Fields

Field NameDescriptionSize
Emv3DSThe EMV 3-D Secure details as returned from the authentication process. Comma separated.150 max.
ThreeDSThe 3-D Secure details as returned from the verify enrolment and payer authentication stages. Comma separated in Monek 2.1 compliant form.60 max.
ThreeDSErrorCodeCode issued by 3-D Secure if either enrolment verification or 3-D Secure authentication failed with an error.V
ThreeDSErrorDetailError description issued by 3-D Secure if either enrolment verification or 3-D Secure authentication failed with an error.V

Structure of the ThreeDS Information field

The ThreeDS information field is comma delimited list with the following fields

warning

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.

NoField Name and ContentsReq'dSizeType
1EnrolledM1A
2AuthenticatedM1A
3ECIM2N
4CAVVM32 max.A
5Transaction IdentifierM20N

Note: The number of fields in these structures are variable. Please ensure any field validation is tolerant.

Structure of the Emv3DS Information field

The Emv3DS information field is comma delimited list with the following fields

NoField Name and ContentsReq'dSizeType
1EMV 3-D Secure StatusM1A
23-D Secure Version used. e.g. 2.2.0M10 max.A
3ECIM2A
4CAVVM32 max.A
5Directory Server Transaction IdentifierM36Guid
6Monek 3-D Secure Transaction ReferenceM36Guid

Note: The number of fields in these structures are variable. Please ensure any field validation is tolerant.

Receipt Information

Field NameDescriptionSize
ReceiptInformationThis 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 = 30387 max.

Structure of the Receipt Information field

NoField Name and ContentsReq'dSizeType
1Bank Merchant NumberM15 max.A
2Unit Separator US – ASCII character code 31M1
3Card Type DescriptionM50 max.A
4Unit Separator USM1
5Merchant NameM50 max.A
6Unit Separator USM1
7Merchant LocationM50 max.A
8Unit Separator USM1
9Date – "YYMMDD"M6N
10Unit Separator USM1
11Time – "HHMM"M4N
12Unit Separator USM1
13Transaction TypeM20 max.A
14Unit Separator USM1
15Card Number – First 4 and last 4 digitsM20 max.N
16Unit Separator USM1
17Start Date – "YYMM"O0 or 4N
18Unit Separator USM1
19Expiry Date – "YYMM"M4N
20Unit Separator USM1
21Issue Number (discontinued)On/aN
22Unit Separator USM1
23Card Details Entry MethodM20 max.A
24Unit Separator USM1
25Terminal IdentifierM8N
26Unit Separator USM1
27Message NumberM4N
28Unit Separator USM1
29Response Message TextM80 max.A
30Unit Separator USM1
31Transaction Amount – minor currency unitsM11 max.N
32Unit Separator USM1
33Cashback Amount - minor currency unitsO11 max.N
34Unit Separator USM1
35Gratuity Amount - minor currency unitsO11 max.N

M = Mandatory, O = Optional, V = Variable Length, A = Alpha-Numeric, N = Numeric