Merchant e-solutions Payment Gateway. Merchant e-solutions October 2013 Version 4.10

(1)

Merchant e-Solutions

Payment Gateway

Merchant e-Solutions

October 2013

(2)

© This publication is for information purposes only and its content does not represent a contract in any form. Furthermore, this publication shall not be deemed to be a warranty of any kind, either express or implied. Merchant e-Solutions expressly disclaims, and you expressly waive, any and all warranties, including without limitation those of

merchantability and fitness for a particular purpose. Merchant e-Solutions reserves the right to alter product specifications without notice. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording, or any information storage or retrieval system, without Merchant e-Solutions permission.

MeS Payment Systems  Merchant e-Solutions 2013

MasterCard® is a federally registered trademark of MasterCard International, Inc. Visa® is a federally registered trademark of Visa, U.S.A., Inc.

Discover® Card is a federally registered trademark of Discover Financial Services Inc. American Express® is a federally registered trademark of American Express Company. ZIP code® and ZIP + 4® are federally registered trademarks of the United States Postal Service.

(3)

Chapter 1 – Related Documentation

Applicable documents

This document describes the request and response record formats for authorization devices using Merchant e-Solutions (MES) Payment Gateway Application Programming Interface (API). The following documents provide additional definition and background information. Please refer to the related documents listed for applicable information.

1.2 Related documents

Documentation and SDK libraries are located at:

http://resources.merchante-solutions.com.

1.3 Document revisions

Chapter Action Data

7 Add Added the Hotel, Cruise, Auto Rental _{addendum data, section}_7.13 8 Update Added new gateway error codes for Hotel, _{Cruise, Auto Rental transactions table}_8.2 11 Update Added response control fields to table and commented on field for product level 11.2

(7)

Chapter 2 – Overview

2.1 Introduction

The Merchant e-Solutions (MeS) Payment Gateway Application Programming Interface (API) utilizes the Internet to provide a simple and secure method of processing credit card payments. By sending an HTTPS POST with minimal transaction information to the payment gateway, a merchant can avoid the complex transmission protocols and message formats unique to the credit card payment industry networks. MeS not only simplifies the procedure, but manages the ongoing process of change resulting from credit card association requirement updates.

Figure 2.1 The following graphic illustrates the process:

Figure 2.1 Settlement to bank.

https://authorization_req uest……. https://authorization_response…. Merchant’s order entry system, online storefront, etc. MeS Payment

Gateway Credit Card _Association Networks

Merchant Bank Settlement to Bank

(8)

2.2 Settlement to Bank

The MeS Payment Gateway accepts a request and returns a response, allowing a limited set of administrative actions. Each day, at a time chosen by the merchant, all

transactions that have been approved are marked for capture and automatically settled. The settlement process results in funding to the merchant’s bank account.

The client is responsible for all development and security required to post the request and handle the response. This includes maintaining compliance with all PCI regulations. This document is intended to:

 Offer an overview of credit card processing, including transaction types and payment components that address risk management, Interchange qualification, and other information necessary to the payment process.

 Provide the specific technical information needed to submit a successful request and receive and interpret the resulting response.

 Outline the steps required to implement the MeS Payment Gateway API including testing and certification.

(9)

Chapter 3 – Credit Card Processing

3.1 Introduction

A successful payment transaction consists of two elements: authorization and capture. The issuer of the credit card provides the authorization based on a number of factors including availability of credit and status of the account (card not reported stolen, for example). The response provided by the issuer includes an approval acknowledgement or a decline code, along with additional information such as billing address verification and/or cardholder validation value match results. When an approval is issued on a credit card transaction, that dollar amount is removed from the amount of available credit on that account for a given timeframe (determined by the issuing bank).

Capturing a transaction, or marking an authorized transaction for capture, is required for that transaction to be settled, or submitted for final processing that results in a charge to the cardholder and a credit to the merchant.

The distinction between authorization and capture exists to accommodate differing processing requirements. For example, some merchants may only need to do a single sale transaction in which an authorized transaction is automatically marked for capture. Another merchant may need to obtain an approval but, because an item might not be available for shipment that day, or the final billing amount might differ from the authorized amount, may not want the payment to be included with the next settlement. This latter merchant would want to handle the authorization and the capture in two steps.

Best Practice: There should be a 1 to 1 relationship between an authorization and a settlement (capture). To settle an amount larger than the authorization a new

authorization for the full amount should be requested, then void the original authorization to reverse the hold on funds. The only exception are industries that allow for a gratuity and are listed below.

Best Practice: A settlement should occur within 7 calendar days of the authorization. If the delay is more than 7 days, the merchant should obtain a new authorization and void the original.

Whether a transaction is authorized and captured all-at-once, or in sequential steps, is the result of the Transaction Type submitted in the authorization request. The MeS Payment Gateway API accepts the following Transaction Types:

Transaction Type Description Comments

Sale If the transaction receives an approval, it will be automatically marked for settlement at the same time.

Pre-Authorization The transaction will be authorized but not marked for capture. To complete a Pre-Authorization, a Settle Pre-Authorization transaction must be performed to mark the transaction for capture. Once marked for capture, a transaction will be included in the next scheduled settlement batch.

Settling a transaction seven days or more from the approval date will result in a downgrade to the Interchange levels, resulting in higher processing costs. Settling a transaction beyond seven days from the date of approval also increases the risk of a chargeback. No transaction should be settled more than twenty-eight days after the

(10)

Transaction Type Description Comments approval date. Settle

Pre-Authorization A Settle Pre-Authorization marks the matching Pre-Authorization transaction for capture.

Best Practice: There should be at least 15 seconds between a Pre-Authorization and a Settle Pre-Authorization request.

If the settled amount is less than the original request a partial auth-reversal will be issued. Requests to settle amounts greater than the authorization will be ignored unless the merchant MCC allows for tip processing. These are: 5812 - Restaurants 5813 - Bars and Taverns 5814 - Fast Food Restaurants 4121 - Taxicabs & Limousines 7230 - Hair Salons

7298 - Health & Beauty Spas. Multi-Settle This function is used by merchants that

initially process a transaction but settle for less, want to process another sale but no longer have the card credentials. This is most typically used in a scenario where items are on back order.

This function should NOT be used as a way to facilitate recurring billing. The store card function should be used for recurring.

Multi-Settle transactions may not be submitted for transactions older than 30 days.

Multi-Settle requires initial authorization and settlement to be written to the database to function properly. It is not intended for the user to send concurrent settlement requests.

Each new request is considered a new sale, therefore there is no cap on the amount of sale. All transactions are submitted with the transaction type “S” and the original transaction ID. Each new request will receive a new Transaction ID. This function is available for both USD and International, but not available for FX transactions.

Re-Auth (of a declined transaction)

This transaction is typically used when a transaction is declined and the merchant no longer has the card account

information (particularly the full account number) in order to resubmit the transaction.

Declines older than 30 days may not be re-authorized.

This function is not intended and should not be used for repeated authorization attempts. It is recommended that after a decline, the merchant either contact the customer for a recommended day to re-submit, or wait a few days prior to resubmission. This function is available for USD transactions only, full card numbers are not stored in MeS database when declined. Void A Void request should only be processed

for a Pre-Authorization transaction. Voiding a Sale should be done with a Refund transaction. Voiding a

Pre-Authorization will initiate an auth-reversal.

Best Practice: A Void transaction should be restricted to Pre-Authorization

transactions. Once a Settlement has been

A Void will generate an auth-reversal, which, depending on the bank, may release the amount held by the authorization.

(11)

performed on a Pre-Authorization it is best handled with a Refund transaction.

Refund A Refund request looks for the Transaction ID of the originating

transaction. If that transaction has not yet been settled, it will void the transaction from the batch. If that transaction has been settled, it will issue a credit transaction.

Partial Refunds: To issue a partial refund, provide the transaction amount parameter in the request. Partial refund amount must be less than or equal to the original transaction amount.

The word "Void", "Adjustment" or "Credit" will be included in the response message to indicate the result of the action.

Transactions may be refunded only once if submitted for the full amount of the original transaction.

Multiple refunds are permitted for a single sale transaction up to but not over the original sale amount.

Credit A refund to the cardholder.

Best Practice: Whenever possible a refund should be processed rather than a credit. A refund is a safer transaction because it references a prior transaction and cannot exceed the amount of the original sale.

A credit transaction does not attempt to match to a prior settled or unsettled transaction. A credit is a stand-alone transaction. The ability to do a credit must be enabled in the Merchant e-Solutions MeS profile. Store card Store card number. The transaction_id

returned by the store request can be used in subsequent requests via the card_id parameter.

Enables user to safely store cardholder card number on MeS secured servers for processing future transactions. This can be performed

independently or in

conjunction with a pre-auth or sale transaction.

Delete Store card The function will delete a transaction from the Gateway that was previously stored using the store card feature

Offline These transactions will be settled using the authorization code provided by the merchant in the request.

Offline transactions typically result when an authorization attempt results in a “Call” response, or when authorization codes are obtained by phone because of a technical problem.

Transactions submitted using this transaction code will be downgraded to lower Interchange levels.

Offline transactions are not permitted for International transactions.

Verification Only This transaction is non-monetary in nature and is used to verify the card number and billing address of a cardholder. This service is most fully supported by Visa

For American Express and Discover this service will validate address and zip only,

For this transaction to be successful and reach the issuer for true validation both street address and zip code must be submitted. If no address information or zip only is submitted the response will

(12)

it will not provide any status on the account (open, closed, etc). In addition, the card verification value is not validated. MasterCard supports an AVS only

transaction with a zero amount and will verify only address match and not the status of the card.

not be successfully processed. In addition, an amount of $0.00 should be submitted. Verification Only is not permitted for International transactions.

Inquiry This function may be used to inquire about a previously submitted transaction. Typically used if the system times out and does not provide a response back to the originator. If found all original response fields will be returned, if the transaction is not located a message will be returned indicating it was not found. In addition, a retry_count will be included to indicate the number of inquiries on a particular

transaction.

This request is only valid within 48 hours of the original request. In order to use this function, a retry ID must be submitted with every transaction, this is the identifier used to perform this function.

Batch Close Allows a user to initiate a batch close via

the API. Primarily designed for POS applications that typically have a close function built in. Typically these will be POS terminals.

In addition to transaction types, there are transaction elements that may need to be considered when processing transactions.

3.2 Transaction Method

Transactions can be accepted in the following ways:

 Card-Present

 Non-Card-Present Mail/Telephone Order (MOTO)

 E-Commerce Transaction

 Recurring Billing

The credit card associations require that a transaction be identified by the method of acceptance. This is done primarily through the moto_ecommerce_ind field, although there are additional field and security requirements that correspond with each acceptance method.

A card-present transaction is one where the magnetic card stripe is read by an electronic device and sent with the authorization request. The cardholder is presented with a paper receipt to sign which the merchant retains, and is provided with a copy for their records. In the event that the card stripe is damaged and cannot be read, the transaction can be hand-keyed at the point-of-sale.

A higher transaction fee may be incurred when a card-present transaction is hand-keyed. Card track data (data from the magnetic stripe read) can never be stored by a merchant.

(13)

Non card-present MOTO indicators include: a onetime mail/telephone order (MOTO), a recurring transaction, and an installment payment.

A recurring charge has no defined number of payments; an installment charge has a set number of charges, such as 7 payments of $19.99.

An e-commerce transaction is a sale that is conducted on the Internet. A secure

transaction uses Secure Socket Layers (SSL) with encryption strength of at least 128-bit. No e-commerce transaction should ever be processed in a non-secure manner.

Note: The MeS API defaults transactions with an e-commerce indicator of 7. Only transactions that fall into a different category need to include this indicator.

3.3 Risk Management Tools

There are many tools available at the transaction level to help merchants manage risk and reduce fraud when accepting non face-to-face credit card transactions. These include standard tools such as Address Verification Service (AVS) and Cardholder Validation Code. In addition, use of optional fields like Dynamic Descriptors may reduce cardholder disputes that while not fraud related may improve overall processing. MeS also offers a comprehensive risk and fraud management system called FraudDeflector.

3.3.1 Address Verification Service

Address Verification Service (AVS) is a tool to help merchants manage risk and reduce fraud when accepting non face-to-face credit card transactions. By submitting the cardholder’s billing address and zip code at the time of authorization, a comparison is done against the billing information on file at the bank. A response is returned indicating a full (address and zip) match, an address-only partial match, a zip code-only partial match, or a response indicating AVS Results are not available (this could result from a number of factors including an AVS system outage, the issuing bank not participating, etc.).

Best Practice: When initially accepting a card for payment, it is recommended to perform a verification only transaction to verify the billing address and zip. This is a non-monetary transaction that will not impact a customer’s “open to buy” on their card.

Performing AVS is a requirement with card-not-present transactions in order to qualify for the optimal Interchange rate. Authorization requests that do not include the cardholder’s billing address and zip will cost more to process.

While the credit card associations have mandated AVS be performed on non card-present transactions, there is no requirement based on result at this time. Deciding how to handle transactions that receive responses other than a full match is based on a merchant’s own risk tolerance.

The AVS result will not affect the transaction itself; if a transaction has received an approval, it will process accordingly regardless of the AVS result. Merchants who may not want to accept transactions with certain AVS results must take the appropriate action depending on the type of transaction: a Pre-Authorization transaction should not be converted to a Settle Pre-Authorization transaction until a merchant is comfortable with the AVS discrepancy; a Sale transaction may need to be Voided before the next scheduled settlement if the AVS result is deemed a significant risk.

(14)

3.3.2 Cardholder Validation

Card Validation Codes is another tool to help merchants manage risk and reduce fraud when accepting non face-to-face credit card transactions. Under the generic “Card Validation Code”, each card type has a unique name for the feature:

 Visa: Card Verification Value 2 (CVV2)

 MasterCard: Card Verification Code 2 (CVC2)

 American Express: Card Identification Data (CID)

 Discover: Card Identification Data (CID)

The Validation Code is a three-digit number that appears on the signature panel of Visa, MasterCard and Discover cards. It usually appears on the back of the credit card, after the account number printed on the signature panel. With America Express cards, it is a four-digit number that appears above and at the end of the embossed card number on the front of the card.

Submitting the Card Verification Code is not required by the credit card associations at this time. Deciding whether or not to submit the Card Verification Code should be a decision made by the merchant based on their own risk tolerance.

The Card Verification Code result, in most cases, will not affect the transaction itself; if a transaction has received an approval, it will process accordingly regardless of the Card Verification Code result. There are a few card issuing banks that will decline a transaction based on a “No Match” Validation Code response.

Merchants who may not want to accept transactions with certain Card Verification Code results must take the appropriate action depending on the type of transaction: a Pre-Authorization transaction should not be converted to a Settle Pre-Pre-Authorization

transaction until a merchant is comfortable with the Card Verification Code discrepancy; a Sale transaction may need to be Voided before the next scheduled settlement if the Card Verification Code result is deemed a significant risk.

Card Verification Codes can never be saved by a merchant after a transaction has been authorized.

3.3.3 Commercial and Purchase Card Extended Data

Commercial Cards and Level 2 Purchase Cards require additional or extended data as a part of

the transaction. This data is included when the transaction is settled, and is used by the card issuing bank to provide enhanced reporting to their cardholders.

Commercial and Level 2 Purchase Cards that are submitted do not include the additional required fields may result in a processing fee that is higher than the normal cost for that card category.

These fields may vary based on category and card type, but usually consist of one or more of the following: Purchase Order Number (sometimes called Customer Code), Tax Amount, and/or Tax Indicator.

If the appropriate extended data is not provided for these specific cards, the MeS Payment Gateway will add those fields at the time of settlement. MeS will not overwrite any data submitted by the merchant in the authorization request.

(15)

3.3.4 Dynamic Descriptors

In the event that a merchant needs to process some transactions with Doing Business As (DBA) information different than the information on their merchant account, this

information can be included in the request message. Data in these fields will override the profile DBA data.

Users of this feature must comply with association regulations. The first 3, 7, or 12 digits must be static followed by an *. The remaining available characters may be unique. In order to use this feature Payment Gateway Certification for Dynamic DBA must be completed. The merchant profile will need to be enabled for this feature, and the static prefix for the descriptor will be preset in the merchant profile. An example of a full Dynamic Descriptor is provided in section 7.5.

3.3.5 Store Card

A request can be made to store cardholder data. This allows a merchant to process transactions with the cardholder information at a later time by using an assigned

transaction ID, eliminating the need to store sensitive cardholder data. Store card may be requested as an independent transaction or performed during a pre-authorization or sale request.

3.3.6 FraudDeflector

The MeS FraudDeflector is an additional service offered to merchant’s using the MeS Payment Gateway for processing. In addition to basic velocity checks, white and black lists, the MeS FraudDeflector offers many external checks such as IP addresses and country of issue.

Merchants that required detailed fraud analysis are encouraged to sign up for this integrated service.

3.3.7 Settlement

Settlement happens automatically. If a transaction has been approved and marked for capture, it will be included in the next settlement batch. Once a batch has settled, nothing else (such as a void) can be done to that specific transaction. The cut off time should be considered in regard to:

 Completion of necessary actions such as corrections (Credits, Voids) or follow-up actions (submitting an Offline transaction, converting a Pre-Authorization

transaction to a Settle Pre-Authorization transaction) that needs to be included in the current batch.

 Reconciliation of bank deposits.

The default batch close time is set to 09:00 pm PT but is configurable via the Payment Gateway Back Office Administration. Batch close times set between 09:00 pm PT and 12:00 am PT are not guaranteed to process in that same day’s cycle.

3.3.8 Card Security Obligation

Compliance with Payment Card Industry (PCI) Data Security Standards (DSS) is required of all merchants and service providers. This applies to all payment channels, including retail (brick-and-mortar), mail/telephone order, and e-commerce.

(16)

Merchants that are not yet PCI certified will receive follow up from the Merchant e-Solutions PCI support team and will be provided tools and the assistance needed to comply with PCI requirements.

All merchants should visit one or both of the following websites for comprehensive information on the responsibilities and requirements for PCI compliance.

http://www.visa.com/cisp

https://www.pcisecuritystandards.org/

Third Party Resellers

Resellers must be PA-DSS certified prior to issuance of a certification letter by Merchant e-Solutions.

If the reseller operates as both merchant and reseller they must comply with both PCI and PA-DSS requirements. Because a merchant must be compliant with PCI requirements, it is in their best interest to use software applications that follow best practices to facilitate this compliance, the PA-DSS guide will provide the guidance necessary to ensure applications and hardware meet these guidelines.

Resellers may visit the following website for additional information: https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

(17)

Chapter 4 – Back Office

The Payment Gateway Back Office provides the following functionality to supplement the integrated processing:

Home provides a snapshot of transactions pending settlement, total pre-authorizations, and one click access to the last settled batch. The back office home page also provides important updates and industry new bulletins.

Administration allows the client to set the settlement time and designate transaction acceptance based on AVS and Cardholder Verification responses.

Transaction processing is available for processing exception transactions manually when the integrated processing is not an option. The client may process all transaction types using a “virtual terminal”.

Batch Management allows for the management of unsettled transactions (marking as settled or voiding), as well as the ability to view and print settled batches.

(18)

Chapter 5 – Testing and Certification Roadmap

5.1 Testing

In order to obtain an ID for testing, the certification request form must be submitted online

at

http://resources.merchante-solutions.com/display/TPGPUB/Payment+Gateway+Certification+Request+Form.

Upon receipt of a completed form, the test ID will be emailed within 24 hours.  The certification request form is located at:

http://resources.merchante-solutions.com/download/attachments/1411006/MeS+PG+Certification+Request+form+v1.1.doc?versi on=1

Merchant e-Solutions will e-mail a document which contains important configuration information, including Profile ID, merchant key and URL. These ID’s are set up for the test/certification environment only.

Best Practice: It is important to use the test profile for testing to prevent billing for

authorizations obtained during testing. MeS will bill for all authorizations obtained using a production profile even if the transactions are part of the testing cycle.

The MeS Certification Servers are available 24 x 7 for unattended testing. The

certification server is a replication of the Payment Gateway production servers and will support testing for all available functionality. These transactions will all be processed as test so there is no need to worry about live authorizations or potential settlement to a cardholder account.

Test ID configuration will contain the following:

TPG Development PID for (Client Name) PROPRIETARY SOFTWARE MERCHANT CONFIGURATION INFORMATION

Certification DBA MeS PG Development TEST # Profile ID (unique profile id value) Merchant Key (unique key value) API Development URL https://...

5.2 Certification

Once testing has been completed, a script will be provided that will test both record formats and interchange qualification. These scripts will be customized for the client based upon the record types identified on the Certification Request form.

Once the certification scripts have been reviewed and approved by the MeS Certification team, a certification letter will be issued the Development Profile ID will be disabled. The Production Configuration will be provided after the certification letter has been issued and the client’s merchant number has been configured for the MeS Payment Gateway. All transactions under this configuration will be live. It is important to remember when installing the production ID’s that you ensure the URL is updated to route all requests to the MeS Production Servers.

(19)

5.3 Test Card Numbers

The authorization process in the test environment is simulated. Any card may be used without impacting the cardholder’s account as all responses are from a simulated authorization system. MeS also suggests use of the test card numbers provided in the table below:

Card Type Length Card Number Visa 16 4012301230123010 Visa 13 4012301230158 MasterCard 16 5123012301230120 American Express 15 349999999999991 Discover 16 6011011231231235 JCB 16 3528288605211810

The table below will generate as listed the commercial card response indicator for testing Business to Business transaction:

Card Type Card Number Commercial Card Response _Indicator Visa 4000700705251681 B - Business Card MasterCard 5589548939080095 B - Business Card MasterCard 5133598939080091 S - Purchasing Card

Visa 4000693061211474 R - Corporate Card MasterCard 5119718939080093 R - Corporate Card

5.4 Address Verification Testing

The card associations have developed Address Verification as a tool to assist a merchant in processing a transaction based on information submitted that is compared to the credit card billing address. In order to test the variety of possible responses, the table below can be used. Defined input values will result in responses as described:

Street Address Zip Code AVS Result Code

123 55555 Y – street and postal code match

123 999991111 Y – street and postal code match (Visa) _{X – street and postal code match (MasterCard)} 123 EH8 9ST D - exact match, international

123 Other Zip A - address match, zip mismatch

234 Any Zip U - address unavailable

345 Any Zip G - verification unavailable due to international issuer non-participation (Visa and MasterCard only)

456 Any Zip R - issuer system unavailable, retry

235 Any Zip S – AVS not supported

Other Address 55555 Z - address mismatch, 5-digit zip match Other Address EH8 9ST Z - address mismatch, international zip match

(20)

Street Address Zip Code AVS Result Code

Other Address 999991111 Z- address mismatch, zip match (Visa) _{W- address mismatch, zip match (MasterCard)} Other Address Other Zip N - address and zip mismatch

5.5 CVV, CVC, CID Testing

This table will test CVV, CVC, and CID which is the 3 or 4 digit code printed on the back of a card. This security feature assists merchants processing in a Card Not Present environment and receiving a positive response ensures the likely hood that the cardholder making the purchase is in physical possession of the card. Visa, MC, and Discover encode a 3 digit value on the cards and American Express encodes either a 3 or 4 digit value. Defined input values will result in responses as described:

CVV / CVC Value Result Code

123 M-Match

234 P-Not Processed

345 U-Issuer is not certified

else N-No Match

This table will test American Express CID:

CID Value Result Code

1234 M-match (this response is generated when the CID flag is enabled on the MeS Profile ID)

2345 P-not processed (this response is generated when the CID flag is enabled on the MeS Profile ID)

**** (any value other than 1234 or 2345) N-no match (with a response code of 000) (this response is generated when the CID flag is enabled on the MeS Profile ID)

5.6 3D Secure (Verified by Visa, MC Secure Code) Testing

This table provides the values and the respective response used in our Certification environment for testing Verified by Visa, the test system will not edit the XID field so we recommend for testing that you submit the same value in XID that is submitted in the CAVV field (note: when in production Visa will return unique values for each field).

MOTO

Indicator CAVV Result

5 ERERERERERERERERERERERERERE= Error code = 000

5 MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMg== Error code = 000

not 5 any value Error code = 000

This table provides the values and the respective response used in our Certification environment for testing MasterCard Secure Code, the test system will not edit the ucaf_auth_data field so we recommend for testing that you submit:

ERERERERERERERERERERERERERE= MOTO

Indicator UCAF Collection Indicator Result

5 2 Error code = 000

(21)

5.7 Amount Driven Response Testing

In addition to testing for approval codes, this table will allow testing for a wide variety of potential response codes:

Amount Response Code

Auth response

text Reason/Description

0.00 085 “Card OK” For card verification testing, submit a transaction code=A

0.01 001 "Call" refer to issuer

0.02 002 "Call" refer to issuer - special condition 0.04 004 "Hold-call" pick up card (no fraud)

0.05 005 "Decline" do not honor

0.07 007 "Hold-call" pick up card (fraud) 0.14 014 "Card No. Error" invalid card number

0.15 015 “No Such Issuer” Invalid card number

0.19 019 "RE Enter" re-enter transaction 0.41 041 "Hold-call" pick up card (fraud: lost card) 0.43 043 "Hold-call" pick up card (fraud: stolen card)

0.51 051 "Decline" insufficient funds

0.54 054 "Expired Card" issuer indicates card is expired 0.57 057 "Serv Not

Allowed" transaction not permitted to cardholder

0.59 059 “Suspected

Fraud” Do not honor card

0.84 084 “Invalid Auth” Invalid Authorization Life Cycle 0.86 086 “Can’t Verify

PIN” System is unable to validate the Pin # 1.10 0TA "CT NOT

ALLOWED" Merchant does not accept this type of card

5.8 PINNED Debit Testing

Note: Pinned Debit will only work with PIN Pads that have been injected to work with the MeS Keys.

Send PIN=1234 for an approved transaction. Any other PIN will be declined with response code '55' (Wrong PIN).

The simulator also supports the following trigger inputs:

(22)

Encrypted PIN Block KSN Response Code 706E3CADE53F11CA 3941013211204321 00 – Approval

43197165510DDD89 3941013211204322 55 - Wrong PIN CCCCCCCCCCCCCCCC 3941013211204323 81 - Encryption Error

5.9 American Express – AAV (Cardholder Email, Name and Phone Number

Verification)

The following AAV or ITD values will cause the simulator to return a 'Y' response in the appropriate response field.

Field Name Group Value

Billing Street Address AAV 123 (only numeric part matters)

Billing Postal Code AAV 55555 or 999999999

Billing First Name AAV CHRIS

Billing Last Name AAV FROST

Billing Phone Number AAV 7035551212

Customer Email ITD CFFROST@EMAILADDRESS.COM

Any other value will cause the simulator to return a 'N' response in the appropriate response field. If a given data element is not supplied the simulator will return a space.

5.10 Partial Authorization and Balance Inquiry Testing

To obtain a partial authorization, submit any valid amount that will generate an approval and the simulator will return 1/3 of the requested amount.

Balance Inquiry testing is not available for testing on the simulator but if requested and if the issuer provides a balance it will be returned in production. In order to validate the transaction processes include the balance inquiry request, the system will accept the request but a value will not be returned.

(23)

Chapter 6 - Processing Interface

6.1 Communication Protocol

The MeS TPG API supports Hypertext Transfer Protocol using Secure Sockets Layer (HTTPS). This provides a single-threaded process in which the originating server makes an HTTPS request to the TPG and waits for MeS to return an HTTPS response. Although HTTP is single-threaded, a single originating server can make multiple requests at once.

6.2 Batch Processing

Large batches may be processed using the Payment Gateway. Sale transactions processed with a single Profile ID will run at a rate of approximately 7 transactions per second (420 per minute or 25,200 per hour).

6.3 Security

HTTPS requests must be encrypted at 128-bit cipher strength. Upon receiving the HTTPS request, the MeS API identifies and authenticates the request through two required fields: the profile ID, which is a unique identifier assigned to each merchant, and a profile key, which is a password linked to that profile ID. Once authenticated, the MeS Gateway handles the transportation and storage of all cardholder data in accordance with Payment Card Industry (PCI) requirements.

(24)

Chapter 7 - Request Field Definitions

7.1 Request Fields

Field Name Description Required Length Format Comments

profile_id Identifies the source of the incoming request.

Yes 20 N

profile_key Specifies the API password assigned to the specified profile identifier.

Yes 32 A/N

card_number Cardholder account

number Yes 5- 22 N Card number should be submitted with only numbers – no dashes or spaces?

card_exp_date Card expiration date Yes 4 N Submit as MMYY; if the month is single digit precede with a leading zero.

If the card has expired and the expired date is submitted, and the moto_ecommerce_ind is set to a 2 or 3 (recurring), the Payment Gateway will submit 0000 as the expiration date in the authorization request. If processing International transactions in the cardholders native currency, submission of 0000 is not supported. card_swipe Contents of card track

read by card-swipe device and passed to payment gateway. Yes (if processing card-present, card-swiped transaction) .

-- -- The card_number, card_swipe and card_id parameters are mutually exclusive. Providing more than one in a single request will result in an error.

The card_swipe parameter overrides moto_ecommerce_ind values.

Swiped transactions are assumed to be cardholder present transactions. AVS and CVV2 data are not needed on card_swipe

transactions; if provided, they will be ignored during the

authorization request.

The payment gateway supports full mag-stripe reads, track 1 and track 2 reads both with and without sentinels.

If you are using the GET method, be sure to properly URL encode all track data.

card_id Card Identifier Yes (if

processing a transaction with stored cardholder data).

32 32-character ID assigned during a previous store card request. The card_number, card_swipe and card_id parameters are mutually exclusive. Providing more than one in a single request will result in an error.

transaction_amount Transaction amount Yes 12 N If processing via MeS International gateway, this amount should be in the foreign currency desired.

(25)

Field Name Description Required Length Format Comments transaction_id Transaction Identifier Yes, for

some Tran Types. See comments

32 A/N 32-character transaction id returned in the original authorization request.

Required only for tran type=V,S,U Note:the same tran ID is returned when processing a settle from a pre-auth, otherwise the tran ID will be unique

transaction_type Transaction type Yes 1 A D=Sale

C=Credit (Domestic only) P=Pre-Auth

J=Re-Auth (of a declined transaction)

O=Offline (Domestic only) V-Void

S=Settle Pre-Auth U=Refund (no multiples for International)

T= Store card data. X=Delete Store card data A=Verification Only (Domestic only)

I=Inquiry Z=Batch Close moto_ecommerce_ind Indicates the type of

transaction. No, default is 7. 1 N Z=Not a Mail/Telephone Order Transaction. 1=One Time Mail/Telephone Order Transaction. 2=Recurring Mail/Telephone Order Transaction. 3=Installment Payment of a Mail/Telephone Order Transaction.

5=Secure Electronic Commerce Transaction (3D Authenticated) 6= Non-Authenticated Security Transaction at a 3-D Secure-capable merchant, and merchant attempted to authenticate the

cardholder using 3-D secure 7 =e-Commerce Transaction. Third Party 3D Users: Verified By Visa EciFlag maps directly to this field.

MC Secure Code, set value to 5 when the EciFlag is 2, set value to 6 when EciFlag=1

reference_number Reference number is assigned by the Payment Gateway Is assigned by the MeS Payment Gateway

11 N This field is no longer available for a client to populate with data, however remains an option for merchants that implemented this field in prior versions.

client_reference_number Merchant defined

number No 96 A/N Merchant defined reference number that may be used for cross reference and internal tracking.

(the ‘&’ sign and the ‘=’ sign are not valid characters)

auth_code Authorization code obtained by means outside of the MeS API. This field should only be included when transaction type = Yes, only for Offline transactions . 6 A/N

(26)

Field Name Description Required Length Format Comments Offline.

batch_number Used to specify the

batch number to close Yes, only if using batch close feature

3 N Valid values are 1-999. System edits for duplicate batches and will reject a batch submitted with the same batch number within 5 calendar days

retry_id Used to look up an

Inquiry transaction Yes, only if implementin g the Inquiry transaction type

16 A/N This is only required if the Inquiry transaction type is being deployed. Number must be unique per transaction within a 48 hour time period.

store_card Used to store (tokenize) a card during a pre-auth or sale No Boolean Boolean (Y, y, True)

This field is used to store (tokenize) a card concurrent with a pre-authorization or sale transaction. The tokenized card ID will be returned in the response string in the card_id field.

cvv2 CVV2/CID value from

card. When present a CVV2/CID match request is made.

No 3-4 N This does require enablement on the MeS Payment Gateway to work properly.

7.2 FraudDeflector Recommended Required Fields

Gathering additional data on all transaction requests is recommended in order to accumulate a processing history that will enable MeS to assist with fraud detection and management. A full list of all fraud fields and responses is available in Chapter 12.

7.2.1 FraudDeflector Field Definitions (Digital Goods)

cardholder_first_name Cardholders first

name No 15 A

cardholder_last_name Cardholders last

name No 30 A

ip_address Customer’s Internet

IP address No 15 A/N/+

cardholder_email _{Cardholders billing} email

No

60 A/N/+ Ex: customerabc@order.com Special characters require URL encoding

cardholder_phone Cardholders billing

phone number No 10 N Submit as: nnnnnnnnnn device_id Device id generated

by BlueCava or other vendor

No Unlimited A/N See section 12.4 for details on acquiring the device_id

7.2.2 FraudDeflector Field Definitions (Physical Goods)

cardholder_first_name Cardholders first

name No 15 A

cardholder_last_name Cardholders last

(27)

Field Name Description Required Length Format Comments ip_address Customer’s Internet

IP address No 15 A/N/+

cardholder_email _{Cardholders billing} email

No

60 A/N/+ Ex: customerabc@order.com Special characters require URL encoding

cardholder_phone Cardholders billing

phone number No 10 N Submit as: nnnnnnnnnn ship_to_first_name First name where

goods will be shipped No 15 A

ship_to_last_name Last name where

goods will be shipped No 30 A

ship_to_address Address where goods

will be shipped No 50 A/N

ship_to_zip Postal Code where

goods will be shipped No 9 A/N

device_id Device id generated by BlueCava or other vendor

No Unlimited A/N See section 12.4 for details on acquiring the device_id

7.3 Non-Card-Present Data Field Definitions

invoice_number Yes, for

preferred Interchange

17 A/N Defined by Visa as 0-9, a-z, A-Z or spaces.

No special characters permitted. cardholder_street_address Cardholder address

data. When present an AVS request is issued. Example: 123 Main St.

No Unlimited A/N/+ Special characters require URL encoding.

Addresses longer than 19 characters will be truncated during authorization request. cardholder_zip Cardholder zip or

postal code. When present an AVS request is issued. Example: 55555 or 555554444. Yes, for preferred Interchange

5 or 9 AN Note: cardholder_zip is also a field used for card-present transactions when the magnetic strip fails to be read.

Alpha Permitted for International Transactions, AVS currently supported internationally in Canada and UK only

7.4 Commercial and Purchase Card Extended Data Field Definitions

Required to qualify for Commercial and Purchase Card interchange categories.

invoice_number Yes, for

preferred Interchange

17 A/N Defined by Visa as 0-9, a-z, A-Z or spaces.

No special characters permitted. tax_amount Sales/Local Tax

Amount Yes, for preferred Interchange

12 Decimal required. ship_to_zip Ship to zip or postal

code. Yes, for preferred Interchange for level III processing

5 or 9 A/N This field is only used when implementing Level III processing.

(28)

7.5 Dynamic DBA Information Field Definitions

Data in these fields will override the profile DBA data. The client must complete Payment Gateway Certification for this feature and provide a static prefix value of 3, 7, or 12 characters to be set in the merchant profile. If the merchant profile is not flagged to include this prefix the Merchant DBA value will be used.

merchant_name DBA Name to appear on the

cardholder statement. No 25 A/N/+ The only allowed special character is the * symbol. Must comply with Association regulations. First 3, 7, or 12 digits must be static followed by an *, then remaining 25 characters of the field may be unique

(ex: HarleyD* Parts) merchant_phone Customer Service phone

number to be using in direct marketing extension data.

No 10 N No dashes, special

characters, etc. EX: 2069991212 Dm_contact_info URL or contact information

that is not a phone number No 13 AN merchant_category_code Merchant Category Code

(SIC) to be used when settling this transaction.

No 4 N Consult Merchant

e-Solutions for valid MCC code.

7.6 Verified by Visa (when using a third party for verification)

xid Verified By Visa

Transaction ID Yes varies Base 64 This value comes from the XID field in the 3D response. cavv Verified By Visa CAVV Yes varies Base 64 This value comes from the CAVV field

in the 3D response.

7.7 MasterCard Secure Code (when using a third party for verification)

ucaf_collection_ind MasterCard Secure Code Collection Indicator.

Yes varies A/N Valid Values:

1 = Supported by the merchant, but UCAF data was not present.

2 = Both merchant and issuer are UCAF enabled

Cardinal Centinel Users: Use the value returned in the ECI Flag.

ucaf_auth_data MasterCard Secure Code cardholder authentication data.

Yes varies Base 64 Cardinal Centinel Users: Use the value returned in the CAVV.

7.8 International Currency Field Definitions

currency_code 3-digit ISO 4217 currency code. For example, to process a request in Euros, the currency_code would

No, default is 840.

3 N By default the API sets the currency code to 840 (US Dollars).

(29)

be submitted as 978. In this example, a transaction_amount of 36.00 would be €36

Foreign Currency Exchange (FX) or International processing options. Refer to the Currency Code Table on the MeS resources site. Click on MeS FX Currency Code Table in the Reference Materials section.

7.9 Recurring Payments-Installment

recurring_pmt_num The payment number of the current transaction.

Optional 2 N _{Modifies the cardholder statement message (see} recurring_pmt_count) Note:

moto_ecommerce_ind should be set to a 3 when using Installment Payment option

recurring_pmt_count The total number

of payments. Optional 2 N Modified cardholder statement by appending thestring"XX OF YY" to the DBA name. XX is the recurring_pmt_num and YY is the

recurring_pmt_count. Note:

moto_ecommerce_ind should be set to a 3 when using Installment Payment option

7.10 PINNED Debit (online only)

debit_pin_block Contains the DUKPT encrypted pin block from the pin pad device

Yes A/N _{Only transaction type permitted for PINNED} Debit is a Sale (D). To issue funds back to a cardholder a Credit as a credit card transaction may be issued, or issue cash or check debit_ksn Contains the Key

Serial Number (KSN).

Yes A/N _{Only transaction type permitted for PINNED} Debit is a Sale (D). To issue funds back to a cardholder a Credit as a credit card transaction may be issued, or issue cash or check

7.11 American Express Enhanced Address and Cardholder Verification Service

Enhanced cardholder verification should be paired with use of the Response Control Interface (RCT) in chapter 11. Use of the RCT to receive detailed validations for each field will further validate the cardholder is who they say they are. Enhanced authorization is not required and if just address and zip are submitted, the AVS response will be returned in the core response string.

cardholder_first_name Cardholders first name No 15 A cardholder_last_name Cardholders last name No 30 A

cardholder_email Cardholders billing email (on file with American

Express) No 60 A/N/+

Ex:

(30)

cardholder_phone Cardholders billing phone _number No 10 N Submit as: _nnnnnnnnnn

cardholder_street_address

First 20 characters of the cardholders billing address. No leading, trailing zeros permitted

No 19 A/N

cardholder_zip Cardholders billing postal _code Yes 9 A/N

5 or 9 digit zip for US addresses, International may be any format and A/N

7.12 American Express Enhanced Data Fields

American Express enhanced data is OPTIONAL, and will be used by American Express to determine if the transaction will be approved or declined. Fields are optional and you may send all or just some fields. While these fields are designed to ensure the

transaction is valid, it may also increase the number of declines from American Express.

ship_to_first_name First name where goods _{will be shipped} No 15 A ship_to_last_name Last name where goods _{will be shipped} No 30 A

Ship_to_phone Phone number where _{goods will be shipped} No 10 N

Format is nnnnnnnnnn; no special characters or extension numbers. Per Amex requirements, for international phone numbers, the furthest right 10 numeric digits will be sent

ship_to_address Address where goods will _{be shipped} No 50 A/N ship_to_zip Postal Code where goods _{will be shipped} No 9 A/N

5 or 9 digit zip for US addresses, International may be any format and A/N

dest_country_code code where goods will be 3 digit numeric country

shipped No 3 N

Example: 840 (USA) or 124 (Canada), etc. ip_address Customer’s Internet IP _address No 15 A/N/+

Format is nnn.nnn.nnn.nnn Example: 555.223.225.123

Cust_host_name Customer Hostname No 1-60 A/N/+

Name of the server that the customer is connected to. Example: PPD.QWEST.COM http_browser_type HTTP Browser Type No 1-60 A/N/+

Customer’s HTTP browser type. Example: EXPLORER/6.0~WINDO WS~VISTA

note: ~ = character space

Customer Ani Customer ANI No 15 A/N/+

ANI (Automatic Number Identification) specified phone number that customer used to place order with merchant. Example: 4256664587

Customer2Digits Customer II Digits No 2 A/N

Telephone company-provide ANI ii (Information Identifier) coding digits associated with Customer

(31)

Field Name Description Required Length Format Comments ANI phone number that corresponds to call-type; e.g., cellular, government institution, etc. Example: 00

Prod_sku

Unique SKU (Stock Keeping Unit) inventory

reference number of product

No 15 A/N

DIGITAL GIFTCARD or PHYSICALGIFTCARD or SKU of the highest valued item if purchase is not a gift card. If SKU exceeds 15 digits, send last 15 digits.

ship_method Method goods were _shipped No 2 A/N

Two-byte, shipment-type code: 01 = Same Day 02 = Overnight/Next Day 03 = Priority, 2-3 days 04 = Ground, 4 or more days 05 = Electronic Delivery 06-ZZ = Reserved for future use

7.13 Hotel, Cruise, Auto Rental Enhance Data Fields

The following fields are required in addition to the basic transaction data to qualify transactions at preferred Interchange, and to send meaningful data to card issuers. Travel fields are only used if a transaction contains both a statement begin and a statement end date

statement_date_begin Date of hotel check in, cruise departure, start date

for auto rental Yes 10 Date mm/dd/yyyy

statement_date_end Date of hotel check out, cruise end date, return

date for auto rental Yes 10 Date

mm/dd/yyyy

Please note, if statement begin date and statement end date exceed 99 days the default calculated and sent to the card

associations will be 99. This is due to field length limitations with the card assocations.

Requester_name Name of individual _{checking in/picking up} Yes 38 A/N name_of_place Name of Hotel location, name of Cruise Ship, or

name of Rental Agency Yes 25 A/N

rate_daily

Amount of daily rate for room, auto rental, or cruise. For cruise may be total amount of cruise if a daily rate does not apply

Yes 12 N

no_show_ind

A value of Y indicates a customer did not check in and the charge is for a no show

Yes 1 Y/N

industry_code Identifies type of industry Yes 1 A/N Supported values: A (auto rental), D (direct marketing).

(32)

Field Name Description Required Length Format Comments H (hotel/cruise). Default is D.

invoice_number Identifies folio for hotel, rental agreement number for auto, and primary tracking number for cruise

Yes 17 A/N Defined by Visa as 0-9, a-z, A-Z or spaces. No special characters permitted.

7.14 Basic Request Sample

Sale Request URL: POST /mes-api/tridentApi HTTP/1.1 Content-Type: application/x-www-form-urlencoded Cache-Control: no-cache Pragma: no-cache User-Agent: Java/1.7.0_21 Host: cert.merchante-solutions.com

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Content-Length: 578 profile_id=94100009999900000001&profile_key=A7B8C9A7A7B8C9A7A7B8C9A7A7B8 C9A7&transaction_type=D&card_number=4262369999996102&card_exp_date=0409&tr ansaction_amount=.15&cardholder_street_address=920&cardholder_zip=99212&invoice _number=12345&tax_amount=0.01

Note: an extended set of request and response samples are available in Chapter 9 of this document.

(33)

Chapter 8 - Response Field Definitions

8.1 Required Fields

transaction_id Yes—for

some Tran Types. See comments

32 A/N 32-character transaction id returned in the original authorization request.

Required only for tranType=V,S,U Note:the same tran ID is returned when processing a settle from a pre-auth, otherwise the tran ID will be unique

error_code 3-character error code providing additional detail.

YES 3 or 4 A/N See error code table below. 4 digit codes for Payvision International Only.

auth_response_text Text message showing auth response.

YES 64 A/N Special characters require URL encoding.

Auth_code 6 digit approval code or response from issuer

YES 6 A/N

avs_result Result code for the AVS response. Only provided if AVS data was provided in the request.

YES 1 A/N

cvv2_result Result code for the CVV2/CID request. Only provided if the CVV2/CID value was provided in the request.

YES 1 A/N

retry_count Number of times a single transaction has been Inquired upon

YES 2 N Only returned if retry ID is sent with a transaction and is only returned with an Inquiry transaction.

8.2 Payment Gateway Error Codes

Response

Code Error Description Required Action

000 (approved Verification Only will return No errors - Transaction Approved. a code of 085)

0xx _{xx = Authorization Response Code.}Authorization request failed. Action determined by authorization host response code see MeS _{Authorization Responses.} 101 Invalid Profile ID or Profile Key. Correct the profile ID and profile key, then resubmit.

102 Incomplete Request. Provide all required data.

103 Invoice Number Length Error. Reduce the invoice number length. 104 Reference Number Length Error. Reduce the reference number length.

105 AVS Address Length Error. Correct the AVS Address.

106 AVS Zip Length Error. Correct the AVS Zip.

107 Merchant Name Length Error. Reduce the merchant name length. 108 Merchant City Length Error. Reduce the city name length. 109 Merchant State Length Error. Provide a valid state. 110 Merchant Zip Length Error. Provide a valid 5 or 9 digit zip.

(34)

Response

111 Merchant Category Code Length _Error. Provide a valid MCC. 112 Merchant Phone Length Error. Provide a valid phone number. 113 Reference Number Must Be Numeric. Provide a valid number. 114 Missing Card Holder Account Data. Provide valid card data.

115 Invalid Card Number. Provide a valid card number.

116 Credits Not Allowed. Contact Merchant e-Solutions to have credits enabled. 117 Card Type Not Accepted. Contact Merchant e-Solutions to add the card type. 118 Currency Type Not Accepted. Contact Merchant e-Solutions to add the currency type. 119 Retry ID length error. Must be 16 _{characters or less} Retry request with a valid retry ID.

120 An invoice number is required for a _{3D enrollment check} Retry request with a purchase ID. 121 MOTO/e-Commerce indicator length _error. Retry request with a valid indicator.

122 Non-USD offline transactions are not _supported Do not submit any International transactions with the Offline _{transaction code.} 123 Client Reference Number length error Resubmit with appropriate length, maximum is 96. 124 Batch Number Required A batch number is required when submitted a transaction_type _{of Z} 125 Invalid Batch Number Batch number must be between 1-999

168 Invalid Industry Code submitted. Example: D for direct marketing with hotel check in Industry Code submitted conflicts with transaction data and check out data

201 Invalid Transaction ID. Correct the transaction ID, then resubmit. 202 Invalid Transaction Amount. Correct settlement amount to be less than or equal to the _{original authorization amount.} 203 Void Failed. Failed to void transaction, retry void or issue credit. 204 Transaction Already Settled. Void failed because transaction has already settled, submit _credit. 205 Transaction Already Voided. Void failed because transaction is already voided. 206 Transaction Already refunded. A refund has already been performed on the transaction.

207 Refund failed. Internal error. Retry refund.

208 Failed to receive a response from _{auth host.} Retry request.

209 Invalid tax amount. Correct tax amount and retry request. 210 AVS result is declined by user. Correct AVS data and retry request. 211 CVV2 result is declined by user. Correct CVV2 data retry request. 212 Refund amount must be between _{zero and the original amount.} Correct amount and retry request. 213 Only sale transactions can be _refunded. Provide a valid transaction ID. 214 Only one type of card data allowed _{per request.}

Only use one of the following: * card_number

* card_swipe * card_id.

215 Invalid Card ID. Provide a valid card ID.

216 Failed to load card data, retry _request. Retry request. 217 Failed to store card data, retry _request. Retry request.

218 _{included in this type of transaction.}Card ID parameter cannot be Remove the card_id parameter and resubmit. 219 Offline transactions requires an _{authorization code} Provide authorization code

(35)

Response

220 Failed to delete card data, retry _request Retry request

221 Invalid Card ID Provide a valid card ID

222 Card ID required Provide a valid card ID

223 Retry Request ID Lookup Failed Retry request

224 FX rate ID invalid. Provide a valid FX rate table ID

225 FX rate has expired. Update rate tables and retry request 226 FX rate lookup failed, retry request. Retry request with valid rate ID 227 FX rate ID required for foreign _{currency transactions.} Provide a valid rate ID 228 Base and consumer amounts are _{inconsistent with the FX rate.} Correct provided amounts 229 Failed to find currency code for the _{requested country code.} Check country code and retry request 230 Failed to post transaction the FX _service. Internal Only

231 FX amount in base currency is _required. Provide the base amount 232 FX transactions not accepted for this _account. Contact Merchant e-Solutions

233 Request currency code must match _{FX rate currency code} Retry request with a currency code that matches the FX _{currency code.} 234 Pin debit transactions require track 2

swipe data. Verify track 2 data is sent with the request 235 Invalid pin debit transaction type. _{Only a sale (D) is supported} 236 Non-USD pin debit transactions are

not supported. PINNED Debit for USD transactions only 237 Batch Close Failed _{Please verify parameters are correct and re-submit} 238 Quit Duplicate Batch The same batch number was submitted within 5 calendar days

of another closed batch. Verify batch is not a duplicate and re-submit with a new batch number

239 Returned when an Inquiry message is sent and there is no transaction

matching the submitted retry ID within 48 hours of the original

transaction

Validate the retry ID and resubmit if valid and within 48 hours of original request. If valid then code 239 means that transaction

does not exist. 240

Failed to load declined auth data System was unable to successfully locate data needed for a new authorization request (only when submitting re-auth or multi-settle requests)

300 Failed to capture International _transaction. Retry request. 301 Failed to void International _transaction. Retry request. 302 Failed to refund International _transaction. Retry request.

303 Card Verify not supported. Retry request.

304 Failed to reverse International _{authorization.} Retry request.

350 Adyen request refused Adyen is declining the transaction; refer to text response for _{details. Should indicated Refused – “details for decline”} 351 Adyen request failed Adyen threw an exception; refer to the text response for details. Should also contain a three digit Adyen error code listed in

section 8.4. 352 Failed to capture Adyen transaction Retry request 353 Failed to refund Adyen transaction Retry request 354 Transaction type not supported by _Adyen Retry request

355 Adyen credit failed Retry request

Merchant e-solutions Payment Gateway. Merchant e-solutions October 2013 Version 4.10