Verifone Vx805 DsiEMVUS Platform Integration Guide Supplement

A Vantiv Company
dsiEMVUS
TM
Mercury Platform Integration Guide

Supplement
08.27.2015
dsiEMVUS Mercury Platform Integration Guide Supplement
A Vantiv Company
Datacap and Mercury Integration Guide Disclaimer, Terms of Use and Compliance Representations
Disclaimer
This Integration Guide and all specifications and documentation contained herein or provided to you hereunder
(the Specifications) are licensed by Datacap Systems, Inc. (Datacap) and Mercury Payment Systems, LLC
(Mercury) (individually and collectively, Licensors), as applicable to each of the Licensors interest in such
Specifications, on an AS IS basis. For purpose of clarity, Datacaps Specifications are owned and controlled by
Datacap and Mercurys Specifications are owned and controlled by Mercury. No representations or warranties are
expressed or implied, including, but not limited to, warranties of suitability, quality, merchantability, or fitness for
a particular purpose (irrespective of any course of dealing, custom or usage of trade), and all such warranties are
expressly and specifically disclaimed. Licensors shall have no liability or responsibility to you or any other person
or entity with respect to any liability, loss, or damage, including lost profits whether foreseeable or not, or other
obligation for any cause whatsoever, caused or alleged to be caused directly or indirectly by the
Specifications. Use of the Specifications signifies agreement with the disclaimer set forth in this paragraph and the
below license and restricted use terms and conditions.
Ownership and Restricted Terms of Use
Ownership of all Specifications, related documentation and all intellectual property rights therein and thereto shall
remain at all times with Licensors. All rights not expressly granted to you herein are reserved to Licensors.
Licensors grant you the right to use the Specification for the sole purpose of transmitting transactions directly to
Mercury from a merchant transaction originating device. Under no circumstances may you reverse engineer,
translate, re-direct, emulate, disseminate to other entities, decompile, adapt, or disassemble the information
contained in the Specifications nor shall you attempt to create source code/object code to emulate the
MercuryPay platform. You agree that the Specifications and the printed materials and documentation that
accompany these Specifications are the confidential information of Licensors and may not be used except as
otherwise expressly permitted herein.
You represent, warrant and agree:
Compliance Representations
To comply with the card brand operating regulations and all applicable PCI Data Security Standards (PCI
DSS) and Payment Application Data Security Standards (PA-DSS) and all requirements applicable to the
distribution and use of these Specifications, Mercury products, and your payment application.
To comply with all applicable federal, state and local laws, rules and regulations, including those related
or pertaining to privacy and truncating and masking cardholder account information and data.
To follow and abide by this integration guide and any modifications made to same from time to time by
Licensors. The most recent version of this integration guide can be obtained from a Mercury Developer
integrations representative by calling 800-846-4472, Ext 1808.
To distribute and otherwise make available integration upgrades or modifications made by Mercury to
your reseller and merchant base utilizing any Mercury product integrated by you or your payment
application.
Any use of your point of sale system or environment to store, process or transmit cardholder data, places that
point of sale system and environment within full scope of the PA-DSS. You agree to comply with PCI DSS and, if
your point of sale system or environment engages in any of the above activities, to ensure that the point of sale
system and environment meets all PA-DSS requirements.
By your use of these Specifications, you warrant, represent and certify your agreement to the above terms and
conditions and that your payment application is compliant and adheres to the above requirements and that future
versions of your payment application will continue to comply and adhere with these requirements.
2015 - Datacap Systems, Inc. and Mercury Payment Systems, LLC - all rights reserved.
dsiEMVUS Platform Integration Guide Supplement 08272015
2015 Mercury
Page 2 of 60
A Vantiv Company
Document Version History

Version
Date
Description
08.27.2015
August 2015
Initial Release

2015 Mercury
Page 3 of 60
A Vantiv Company
Table of Contents
Overview ............................................................................................................................................................... 6
The Integration Process ............................................................................................................................................. 6
EMV Data Flow and Terminology .............................................................................................................................. 7
A Phased Approach for U.S. EMV Rollout .................................................................................................................. 8
Quick Reference................................................................................................................................................... 10
Install and Configure the Datacap Test Components .............................................................................................. 10
Setup the VX805 for EMV ........................................................................................................................................ 11
dsiEMVUS Client Test Tool ....................................................................................................................................... 11
Mercury Supported EMV Commands, Functionality and Trancodes ...................................................................... 12
EMV Differences .................................................................................................................................................. 13
Changes to the Consumer Experience ..................................................................................................................... 13
Changes to Transaction Processing ......................................................................................................................... 15
Overview of Datacap Systems, Inc. dsiEMVUS .................................................................................................. 17
Mercury/Datacap Systems U.S. EMV Configuration Information............................................................................ 17
EMV Devices and the VeriFone VX805 .................................................................................................................... 17
Install and Configure the Datacap TEST Components ........................................................................................... 19
Download and Install the CERT NETePay ................................................................................................................ 19
Setup the CERT NETePay ......................................................................................................................................... 19
Retrieve your Test Merchant parameters ............................................................................................................... 20
Redirect processing traffic to the CERT NETePay .................................................................................................... 21
Download and Install the dsiEMVX control ............................................................................................................. 22
Setup the VX805 for EMV ........................................................................................................................................ 22
EMVUS Client Test Tool ....................................................................................................................................... 23
Mercury Supported EMV Commands, Functionality and TranCodes .................................................................... 24
Commands ............................................................................................................................................................... 24
Functionality ............................................................................................................................................................ 24
TranCodes ................................................................................................................................................................ 24
Example of a dsiEMVUS XML Request and Response ........................................................................................... 26
Receipt Requirements ......................................................................................................................................... 32
Mercury Supported Functionality ........................................................................................................................ 34
Mercurys End-to-End Encryption (E2E) .................................................................................................................. 34
TM
MToken : Mercurys Brand of Tokenization .......................................................................................................... 34
Additional MercuryPay Processing Features ........................................................................................................... 36
Duplicate Logic.......................................................................................................................................................... 36
Using dsiPDCX as a Complement to dsiEMVUS ....................................................................................................... 37
Certification and Limited Release ........................................................................................................................ 38
Certification Process ................................................................................................................................................ 38
Certification Network Testing Information.............................................................................................................. 38
Limited Release and Review .................................................................................................................................... 38
Appendices .......................................................................................................................................................... 39
Appendix 1: XML Request/Response Examples....................................................................................................... 40
Appendix 2: NETePay and dsiEMVUS Error Messages ............................................................................................ 57
Appendix 3: Additional Resources ........................................................................................................................... 59
Appendix 4: Glossary ............................................................................................................................................... 60

2015 Mercury
Page 4 of 60
A Vantiv Company
Table of Figures
Figure 1. dsiEMVUS Data Flow.......................................................................................................................................8

Figure 2. EMVUS Client Test Tool ................................................................................................................................23
Figure 3.Example of an XML Request ..........................................................................................................................26
Figure 4. Example of an XML Response .......................................................................................................................29
Figure 5. Approved Text Responses.............................................................................................................................30
Figure 6. Declined Text Responses ..............................................................................................................................30
Figure 7. Receipt Examples ..........................................................................................................................................32

2015 Mercury
Page 5 of 60
A Vantiv Company
Overview
Using this Integration Guide
This guide is a supplement to the Mercury Platform Integration Guide and to the Datacap dsiEMVUS EMV
Programming Interface Specification. This guide provides a one-stop resource for integrating Datacaps dsiEMVUS
to the Mercury Platform, pulling together key information from these other two resources.
The Mercury Platform Integration Guide provides details on processing various types of transactions, admin
functions such as BatchClose, and additional processing features such as how to prevent duplicate
transactions. Your Integration Analyst will provide you with a copy of this guide.
The dsiEMVUS EMV Programming Interface Specification provides details specific to dsiEMVUS
implementations. This guide can be requested from Datacap; go to http://datacapsystems.com/emv-transition
General Integration Information
All Mercury EMV integrations must use Mercurys end-to-end encryption.
It is strongly recommended that all integrations also use Mercurys MToken , our proprietary tokenization
technology.
The first Mercury EMV-certified device is the VeriFone VX805. This device, as all Mercury EMV-enabled
devices, includes Mercurys end-to-end encryption. Devices are ordered through The Phoenix Group.
TM
The Integration Process

POS development cycles vary according to available resources, the scope of the project and urgency of the
business. However, the overall process falls into recognizable phases proven to bring about a successful
outcomeaccelerated time to market and return on investment. Mercurys recommended best practice for
successful POS development is to plan do-able phases and know the Mercury certification and industry
requirements ahead of time to avoid surprises; focus development time on achievable results; and then let us help
you grow your business.
(1) Integration
Planning
(2)
Configuration
and Setup
(3) Active
Development
(4) Certification
and Compliance
Review
(5) Submit
Authorized
Reseller
Application
(6) Download
and Install
Production
Version
(7) Limited
Release and
Review
(8) Full
Production
1. Integration Planning. You will participate in a kickoff call with your Developer Integrations Analyst to review the
integration process, discuss the various peripheral devices available, and decide on a solution. Your integration
analyst will provide you with documentation and links for specifications, code examples, and testing credentials.
2. Configuration and Setup. Download and configure the Cert NETePay server, dsiEMVX control, and setup the test
VeriFone VX805 device.
3. Active Development. Combine your programming language with the tools and sample code from our integration
specifications. Program and test using the Mercury certification network.
4. Certification and Compliance Review. Complete and submit your transaction review test scripts to your
Integration Analyst. Your analyst will review the test results and provide a quick turnaround, identifying any issues
that need to be addressed prior to issuing the Transaction Review Certification letter. Upon receipt of this letter, you
will sign and return the dsiEMVUS compliance declaration provided by your Integration Analyst.
5. Submit Authorized Reseller Application. Complete the reseller application on Datacaps website:
http://datacapsystems.com/reseller-application. (If clicking this link does not work, please copy it to your
browser). If your business uses certified VARs, they too will need to be authorized resellers with Datacap.

2015 Mercury
Page 6 of 60
A Vantiv Company
6. Install Production Version. Once the reseller application is approved by Datacap, Mercury will create a
DeploymentID for all of your new merchant installations.
7. Limited Release and Review: Your integrations analyst will review and monitor the transactions from your first
merchant site(s) through one complete billing cycle. This includes analysis of the merchant(s) statements to ensure
payment-type interchange stability and to ensure that the best qualified rates are maintained.
8. Full Production. After your product is released into full production, Mercury provides you with:
Prospect to processing: our internal sales force can help you grow your channel.
Friendly, well-trained, 24-7 customer support teams to assist your merchants with common questions and
processing concerns.
Knowledgeable technical support teams to help troubleshoot and resolve more complex issues.
Continued access to your dedicated Integration Analyst for troubleshooting and enhancements.
EMV Data Flow and Terminology

EMV chip cards contain an embedded integrated circuit chip (ICC), which is a microprocessor inside the card. When
a chip card is inserted into a chip card entry device (CED), the card and device share physical contact points which
enable a two-way exchange of EMV data. In addition to inserting a chip card into a reader, there are contactless
chip cards which have Near Field Communication (NFC) capabilities. Chip cards that combine both contact and
contactless are referred to as dual-interface cards.
Note There are two grades of contactless: EMV grade and MSD (magstripe) grade. Currently, only MSD grade
contactless is available.
The chip on the card is configured with one or more Application Identifiers (AIDs). Each AID contains an ISOregistered ID, identifies the card brand (e.g., MasterCard, Visa, and Amex), indicates the card product type (credit,
debit or ATM) and the preferred card verification methods (CVM) which can be PIN, SIGNATURE or NONE. The AID
also contains cardholder agreement factors such as amount limits, daily usage counters and risk management
features.
Both the EMV device and EMV card maintain a list of AIDs they support:
The Issuer loads the chip with its preferred applications and AIDs
The device contains a list of AIDs it supports, which may be specific to the business environment.
The card may contain multiple AIDs, referred to as candidate lists. The device also contains one or more AIDs. The
device and the card compare their lists and agree on the best AID, based on a hierarchical structure. This
selection happens automatically without cardholder interaction, and is called Application Selection. This selection
process determines if the receipt output requires a Signature line, allows the transaction to be PIN Verified or to
allow No CVM (no card verification method required).
Note With the Datacap dsiEMVUS and Mercury, all of this is handled seamlessly and certified on your behalf,
right down to the required receipt information.
PIN entry CVMs for EMV credit card verification is managed in two different ways, yet from the end-user and POS
perspective, the experience and interaction will appear the same:
Online PIN is when the encrypted PINBlock and key are sent along with the transaction request to the
processor for decryption and authorization. In this case, PIN decryption is a function of the Issuers host
system.
Offline PIN means the chip communicates directly with the device to verify the PIN entry at the device level.
The PIN is securely encrypted on the chip itself. When the card is inserted, the chip communicates with the
device that an offline PIN is available if the device supports it. If it does, the device will proceed to prompt for
PIN entry. As the PIN is entered on the device, it is compared with the PIN stored on the chip card, and only
the result of the comparison is transmitted to the Issuer host system.
The EMV request and response cryptogram: The chip uses a combination of EMV tag data elements, a uniquely
generated application cryptographic master key, and a message authentication code (MAC) to create a unique
cryptogram. This is called the Authorization Request Cryptogram (ARQC) and is sent to the Issuer along with the
key, key index and details on how the ARQC was generated. Only the Issuer can break down and read the ARQC.
2015 Mercury
Page 7 of 60
A Vantiv Company
The issuer will use the key index and other variables to duplicate the original ARQC. If the two match, then the
issuer will return an Authorization Response Cryptogram (ARPC) to the chip card. The card then follows a similar
process to generate its own ARPC using data elements returned form the Issuer, which should match the original
ARPC. This is the cards way of confirming that the Issuers response is valid, just as the Issuer confirmed the chip
cards request was valid.
Additional randomized numbers are used in the transaction request to protect the card information. If the
transaction request is stolen or reproduced, the reproduced card data will be incorrect and will not authenticate,
thus protecting the card from being counterfeited. This, however, is only true for chip reads. If an EMV card is
swiped for authentication, the data contains only static elements just like magnetic stripe cards.
dsiEMVUS Data Flow
1.
2.
3.
4.
5.
POS initiates an EMV transaction to the dsiEMVUS

which then takes control of the EMV enabled device.
The cardholder inserts chip card into device.
The chip card and card reader negotiate application
selection:
Determine transaction type (credit, debit)
Reads application parameter data
Determines the Card Verification Method (PIN,
Signature, none)
Chip generates ARQC and passes to dsiEMVUS to build
a complete Authorization request (plus cryptogram)
Authorization request is sent from the dsiEMVUS to
Mercury (processor)
6.
Authorization request is sent from Mercury to

Issuer
7. Authorization response with ARPC is sent from
Issuer to Mercury
8. Authorization response is sent from Processor to
dsiEMVUS to EMV enabled device; device
confirms response with chip on card and passes
the application response message back to
dsiEMVUS
9. Receipt information is sent from dsiEMVUS to
POS
10. Card is removed from EMV device
Figure 1. dsiEMVUS Data Flow
A Phased Approach for U.S. EMV Rollout

Supporting EMV in the U.S. has been, and continues to be, an immense undertaking involving many different
entities including the coalition of card brands (EMVCo) which is responsible for defining the regulations, device
manufacturers, issuing banks, processors, acquirers, and of course every ISV, reseller and merchant now faced
with adopting this new payment protocol. Because of this complexity, the industry will see EMV adoption occur in
phases, and this is true for Mercury's rollout as well.
Mercurys initial release of EMV uses Datacap Systems dsiEMVUS and the VeriFone VX805 enabled with our E2E
encryption. This solution, including Mercurys processing infrastructure which passes transaction requests directly
to the backend authorization networks, has been card-brand certified. Below is our timeline for EMV functionality:
Available Now
Card-present EMV Credit Sale, Return, VoidSale/Reversal, VoiceAuth, and ZeroAuth with four card verification
methods (CVM); card-not-present for Credit Adjust and VoidSale using Mercury's tokenization, MToken.
Available entry methods include chip insert, MSR swipe, MSD grade contactless/NFC and manual entry. This initial
release also includes additional security features using Mercury's E2E encryption and tokenization.
Note Credit Offline PIN is available for all card brands. Credit Online PIN is only supported by MasterCard.

2015 Mercury
Page 8 of 60
A Vantiv Company
October 2015
U.S. PIN Debit transactions for Mercury EMV merchants will be available October 2015. Mercury is part of the
Vantiv family, and Vantiv is the largest PIN Debit acquirer in the nation. We are in the process of migrating to
Vantivs debit network, which is scheduled to be completed in October 2015. Until then, standard U.S. PIN Debit
will temporarily be unavailable to Mercury EMV merchants. In the interim, and if your merchants are eager to
adopt EMV, debit cards may be ran as credit.
! Important Note Interim training required. The VeriFone VX805 is designed to prompt for Credit or Debit with
any swiped or tapped card. Until we complete our debit migration to Vantiv, it is important to train your
merchants to instruct customers NOT to select Debit on a swiped or contactless transaction.
Early 2016
EMV Debit (Chip enabled PIN Debit) is not yet supported by the U.S. Debit networks. The industry anticipates this
will be ready in the first quarter of 2016. In the meantime, EMV Debit cards will either be processed as EMV credit,
or the request will fail gracefully when the card is inserteddepending on how the applications are configured on
the card and the device.
EMV Contactless/NFC (EMV grade exchange of chip data using Near Field Communication) will be available in the
first quarter of 2016. In the interim, EMV contactless cards will process as magstripe grade. This includes
ApplePay, GoogleWallet and other contactless entry methods.
Note Magstripe contactless will continue to function normally.

2015 Mercury
Page 9 of 60
A Vantiv Company
Quick Reference
This section provides you with the basics for quickly downloading the software and setting up your device for EMV.
It also lists the key transaction types so you can start building your XML right away. The remainder of this
document provides additional detail.
Install and Configure the Datacap Test Components
Setup the VX805 for EMV
dsiEMVUS Client Test Tool
Mercury Supported EMV Commands, Functionality and Trancodes
Before you begin
A working TCP/IP internet connection is required for this process
Firewalls should accept traffic on port 9000 (and port 9100 if using Gift)
A Windows COM port should be available for attaching the payment device
the 128 bit cipher for Windows cryptographic services must be installed on the system running dsiEMVX.
Install and Configure the Datacap Test Components

1.
2.
3.
Download and install the CERT NETePay.

In this step you will first download the production version of NETePay, then replace it with the CERT version:
Go to: http://www.datacapepay.com/netepay5-mercuryoos.htm, then click on Get next to NETePay for

Mercury In-Store version 5.06.10 (more than one version may be listed so be sure to choose the correct
one). the NETePay will install to the default location: C:\Program Files(x86)\Datacap Systems\NETePay
Go to http://www.datacapepay.com/software/dev-netepay/mercury/version5dev/USEMV/ and click

DSIMercuryIP_Dial.exe to download the file, then save it to your desktop.
Delete the PROD NETePay from the default location: C:\Program Files\Datacap Systems\NETePay. If
there is a shortcut for this file on your desktop, delete it.
Copy and paste the CERT NETePay from your desktop into the C:\Program Files\Datacap
Systems\NETePay. Create a shortcut for this file on your desktop (optional).
Setup the CERT NETePay.

The first time you launch the CERT NETePay, it will prompt you to obtain a serial number.
Click the Obtain Serial Number button. You will get a confirmation screen. Click OK and you will see a new
dialog box saying Configuration not Set Use Setup | Merchant Parameters.
Click OK and you will be returned to the NETePay main status window.
Open NETePay (if it is not already open) and select Setup. You will see the Setup Merchant Parameters
screen. Click Load New Parameters and on the next screen click Yes.
On the next screen click I Have My DeploymentID, then enter your DeploymentID and click OK. (This
number is provided to you by your Integration Analyst).
You will see a new screen with Merchant demographic data. If the information is correct, click Yes This is
the Correct Merchant. (If it is not correct, click Cancel and start again).
If all goes well, you will see a dialog box with Parameters Successfully Loaded. Click OK and you will be
brought back to the Setup Merchant Parameters screen.
Redirect processing traffic to the CERT NETePay.

All processing traffic within your POS application should be directed to the local NETePay you just installed.
Change the processing server host list address in your POS application from x1.mercurycert.net to the
IP of the local machine: 127.0.0.1
! Important Note NETePay must always be running to process transactions. We recommend the default
location in the POS system tray.
2015 Mercury
Page 10 of 60
4.
A Vantiv Company
Download and install the dsiEMVX control.

Go to: http://www.datacapepay.com/software/emvus/ and click dsiEMVUS-100-With-EMVUS-test-AppInstall20150807-W8.exe. Both the dsiEMVX control and the EMV US Client Test tool are contained in the
download. The download will automatically launch the install program. The files will be saved to the
default location: C:\Program Files\Datacap Systems\US EMV Client

1.
Connect the VX805 device to your computer.

Note If you are using USB cables, you should have received the USB device driver with your test device. Make
sure to install the driver. If you do not have the device driver, contact your Integration Analyst.
2.
Go to the Windows Control Panel > Devices and Printers (Windows 7) and verify that the VX805 is displayed. If you
are using USB, also check that virtual COM Port has been assigned. Note the COM port number, which will be used
in step 4 below.
3.
Double-click DSIMercuryIP_Dial.exe to run the NETePay software.
4.
Open the EMV US Client Test Tool (there should be a shortcut for this on your desktop). Configure the
following values:
5.
Merchant ID: 755847002.
Confirm the IP/Hostname is 127.0.0.1.
Change the COM port to the one your VX805 is attached to (from step 2 above). If using USB, the
VeriFone USB driver typically defaults to COM 9.
Enable EMV on the VX805:
Click the EMV ParamDownload button. You will see the XML that is sent to the dsiEMVX.ocx.
Click OK. The client will access the parameters that were initially installed with your NETePay and download
them to the device. The device will display please wait and then loading. It takes about one minute for the
configuration to load onto the device. When this is complete, the device will display re-initializing please wait,
then Welcome, then re-initializing please wait, then Welcome. A response XML will signal that that the
ParamDownload was successful and upon clicking OK, control will be returned to the test application. Your
device is now EMV enabled.
dsiEMVUS Client Test Tool

Datacap provides this tool as a way to run transactions without writing the XML. It can also be used to confirm that
you are communicating correctly with the device.
1.
Use the a shortcut on your desktop for EMVUSClient to open the tool.
2.
The tool opens. Complete the following information:

Pad/Processor
Merchant ID
Terminal ID
Operator ID
IP/Hostname
Com Port
Amount
TIP Amount
Cash Back
RefNumber
Transaction Modifiers
PIN Pad Reset
EMVParamDownload
VX805 Mercury (E2E)

755847002
NA
Test
127.0.0.1
enter the device COM port
use amounts under $10.99
optional
optional
invoice number
check Allow PartialAuth and Use Tokens
should be sent after every transaction
Run this when device is first installed

2015 Mercury
Page 11 of 60
3.
A Vantiv Company
Click the transaction you would like to run (EMV Sale, EMV Return, etc.) All transaction requests and responses
are saved to the test tools log files located at: C:\Program Files\Datacap Systems\US EMV Client
Mercury Supported EMV Commands, Functionality and Trancodes

ISV Commands
Server Version
GetDevicesInfo
Used to confirm the NETePay Version

Used to determine which SecureDevices are supported in the version of dsiEMVX along
with the device capabilities and characteristics.
Device Commands
EMVParamDownload
EMVPadReset
Functions
Prompt for Manual
Prompt for Tip
Loads deployment parameters and security information into the chip card reader.
Performed when a new device is first installed, when a device is replaced, or as
requested by the service provider.
Execute this command before every transaction to ensure that a card was not left in
the chip reader. If there is a card in the reader, the PIN pad will display Remove Card
and waits until the card is removed. Another EMVPadReset should then be sent to reset
the device.
Required/
Optional
O
O
Swiped Entry
Contactless Entry
Partial Approval
R
R
R
Admin Functions
BatchSummary
BatchClose
TranCodes
EMVSale
EMVVoidSale
EMVReturn
EMVVoidReturn
EMVVoiceAuth
EMVZeroAuth*
AdjustByRecordNo
VoidReturnbyRecordNo
VoidSaleByRecordNo
Required/
Optional
R
R
R
R
O
O
O
O
O
Notes
Prompt for manual; use as fallback for swipe
Use to prompt the cardholder for a tip (gratuity) which is added to
the total sale amount and sent as a single transaction.
For non-chip cards, or as a fallback from chip
MSD/magstripe contactless
This a card brand mandate to allow card-present purchases to be
partially approved.
These functions are for POS systems that include a local, merchantinitiated settlement function. Use BatchSummary to retrieve current
batch counts and amounts for comparisons, and use BatchClose to
close the current batch.
Notes
Built in support currently for all CVM: Signature, No CVM, Offline
PIN or Online PIN (MasterCard). dsiEMVX controls receipt
generation
EMVVoidSale and EMVVoidReturn may be supported for either
card-present or ByRecordNo
EMVVoidReturn may also be supported optionally by EMVSale
Card verification without authorization
ByRecordNo TranCodes use a token (RecordNo) to adjust a gratuity
on an EMVSale, reverse an EMVSale, or void an EMVReturn.
* Available for MasterCard, Visa and Discover. Amex requires an amount be included (no charge to cardholder account).
See Example of a dsiEMVUS XML Request and Response later in this document for details on how to construct
the XML.
See Mercury Supported EMV Commands, Functionality and TranCodes later in this document for more details
about each.

2015 Mercury
Page 12 of 60
A Vantiv Company
EMV Differences
EMV is more than just another POS entry methodit is a culture shift for the consumer and for merchants, and may
require a new way of thinking about their business. For the ISV, it means new challenges with device
communications, revisiting existing POS code, new transaction requirements and a whirlwind of information. We
understand and are right there with you. We are committed to simplifying these challenges.
Changes to the Consumer Experience

1.
In addition to a conventional magnetic stripe reader, EMV-enabled devices have a separate slot only used for
inserting and reading the chip card. These devices also support contactless and keyed entry.
2.
The action of inserting a chip card should not be taken for grantedthe cardholder must firmly push the
card into the reader with the chip facing up, making sure the card locks in place. The device grabs the card
and holds it in place with a click.
3.
Chip cards must stay in the EMV-enabled reader for the duration of the transactiononce the chip reader
initiates a chip read, the device reminds the cardholder DO NOT REMOVE CARD. If the card is removed
before the transaction completes, the device will cancel the transaction and display an error,
TRANSACTION NOT COMPLETE Card Removed.
4.
A swipe reader cannot read a chip and the chip insert reader cannot read a magnetic stripe. These are
two separate card entry methods.
If a magstripe card is inserted into an EMV-enabled device, the device will prompt the cardholder
APL NOT AVAILABLE USE MAG STRIPE. This message indicates that the chip reader was either
unable to read the card's chip, or the card was not a chip card, and to proceed to swipe the card.
If an EMV chip card is swiped into an EMV-enabled device, a code on the magnetic stripe will trigger
the device to prompt: USE CHIP READER.
If a chip card is inserted into an EMV-enabled device but cannot be read correctly, the device will
prompt the cardholder APL NOT AVAILABLE USE MAG STRIPE followed by REMOVE CARD. This
is called a "technical fallback."
5.
PIN entry is not just for Debit transactions anymore. Now EMV Credit may be verified using PIN entry as well.
There are two different PIN verification methods:
Online PIN is when the encrypted PINBlock and key are sent online along with the transaction
request to the processor for decryption and authorization.
Offline PIN means the chip communicates directly with the reader to verify the PIN entry.
6.
Whether a transaction is APPROVED, DECLINED, ERROR or CANCELLED, card brand receipt requirements
may vary from previously established receipt practices. A good rule of thumb is if <PrintData> is returned
in the transaction XML response, appropriate receipts should be generatedtypically one for the
cardholder and one for the merchant to retain. The card brand regulations vary on receipt requirements.
Please see the Receipt Requirements section of this document for recommended best practices for printing
receipts.
Try it yourself
Below is a set of tests you can try to get hands-on experience with the differences when using an EMV chip card.
You can use these credentials for the test:
Test Server
x1.mercurycert.net
MerchantID
755847002 (E2E/Token)
Note mercurycert.net is our EMV-ready testing and certification environment designed to mirror production
processing and Card Brand response data. Please use this server address for all of your testing. The above
MerchantID is enabled for E2E encryption and tokenization, which will be the standard configuration for Mercury
EMV Merchants.
2015 Mercury
Page 13 of 60
Test
Action
1. Swipe a chip card
a. Swipe B2 test card #1
1.01
b. Insert card to complete

transaction
1.01
c. Leave card in place after

approved, and send
PadReset.
a. Insert a magstripe test
card
b. Swipe magstripe test
card
--
2. Insert a magstripe card
3. Remove card before

transaction completes
5. Offline PIN
Insert B2 chip card #10, then

remove card before the
transaction is complete
Insert B2 chip card #10, then
press Cancel on the device
after the amount is
confirmed
Insert B2 chip card #2
6. Online PIN
Insert B2 chip card #12
4. Cancel Transaction
Amount
A Vantiv Company
PIN pad Results

PIN pad detects service code and
prompts, USE CHIP READER
Confirm amount. PIN pad displays
DO NOT REMOVE CARD, followed by
approved/declined response
Device beeps and prompts, REMOVE
CARD
1.02
PIN pad prompts, APPL NOT

AVAILABLE USE MAG STRIPE
1.02
Confirm amount
Select CREDIT
Follow prompts to complete
transaction.
Important Note The device may
prompt for CREDIT or DEBIT, but
debit functionality is for future use!
PIN pad displays TRANSACTION NOT
COMPLETE Card Removed
1.03
1.03
PIN pad displays TRANSACTION NOT

COMPLETE
1.04
1.05
Confirm amount
Enter PIN on Card
press OK to complete transaction
Confirm amount
Enter PIN on Card
press OK to complete transaction
Frequently Asked Questions

When I insert the chip card into the device, nothing happens. Why is that?
When inserting the chip card, make sure the chip is facing the device and is facing up. Also make sure to insert
the card firmly until it clicks.
What happens if a consumer presents a magstripe card at an EMV device?
The EMV device has a magstripe reader in addition to a chip reader, so the consumer would swipe the
magstripe card. The dsiEMVX control will handle a chip card, contactless card, or a magstripe card.
! Important Note Transactions originating from an EMV-enabled device using the dsiEMVUS will use a
TranCode of EMVSale even if, after the initial call to the device, a non-EMV card is swiped or manually entered.
What happens if I insert an EMV Debit card?
At this time, the device will display APPL NOT AVAIL USE MAG STRIPE. EMV Debit and the adoption of the U.S.
common debit standard application will be supported in 2016.

2015 Mercury
Page 14 of 60
A Vantiv Company
Changes to Transaction Processing

Tip Modifications (adding gratuities)
For restaurants and other environments that accept gratuities, adding an EMV credit tip can be done in two
waysin the flow of the transaction using a customer facing prompt, or by adding a gratuity amount in a follow up
Adjust.
Prompt for Tip
Send an EMVSale and include <Gratuity>Prompt<Gratuity>, which displays a prompt on the device asking the
consumer to add a tip.
A request is sent in the EMVSale including base purchase amount and the gratuity prompt
The device prompts the consumer to confirm the initial purchase amount
The device prompts the consumer to add a tip and then to enter an amount
The device prompts the consumer to confirm the new total amount
The consumer inserts the card and the transaction is sent for approval
The response confirms the approval and includes three amount tags:
<Purchase>5.00<Purchase>
<Gratuity>1.25<Gratuity>
<Authorize>6.25<Authorize>
Adjust for Tip

TM
This option can only be used for chip and signature, and requires the use of Mercurys tokenization, MToken .
The steps are similar to the two-step PreAuth/PreAuthCapture method commonly used in non-EMV transactions to
capture gratuities.
With MToken implemented and a RecordNo requested, send an EMVSale, then:
Use CVM to confirm that the card presented was credit chip and signature.
Store the returned token for later use.
Build out a standard sales receipt including a line for the gratuity and another line for customer
signature.
Present the receipt to the customer for signature and gratuity.
Upon closing out the check, use AdjustByRecordNo to send the gratuity amount
<Gratuity>2.00<Gratuity>.
! Important Note Credit CVMs that require PIN entry (Offline or Online Credit PIN) and U.S. PIN Debit do not
allow gratuity to be added in a subsequent transaction using a token.
Running a tab
Running a tab refers to the POS feature of identifying a customer and continuously adding to the purchase amount
as that customer orders additional items over a period of time until the customer finishes and the tab is closed.
There are multiple ways for POS applications to handle tabs, and how this feature is implemented is determined by
a balance between business requirements, need for fraud protection and card brand regulations. The enhanced
fraud protection of the chip read and preferred processing rates associated with card present transactions make
the adoption of EMV in tab environments appealing. However, there is a minor difference with EMV cardsthe
customer will need to insert their card more than once:
To open the tab, the customer or clerk inserts the card and the POS sends a ZeroAuth. ZeroAuth validates that
the card has not been reported lost or stolenwithout charging the card. For additional fraud protection
ZeroAuth may be sent with the customer's AVS data.
Note This is best used with tokenization. A token is returned and stored for subsequent use. With
tokenization, should a consumer leave before closing the tab, the token may be used to finalize the
transaction. Although this is not optimal, it can help to reduce loss due to so called "Dine and Dash" behavior.
To close the tab, customer or clerk inserts the card a second time and sends an EMVSale for the final amount.

2015 Mercury
Page 15 of 60
A Vantiv Company
Tip modification can be handled either in the above flow by including a device prompt, or by using the token
returned from the EMVSale and sending a AdjustByRecordNo.
As an alternative to the ZeroAuth initiation of a tab, the initial transaction can be used for validating the card. This
method requires a reversal of the original EMVSale be sent prior to sending and adjusting the final total amounts.
Cashback
Unless you or your merchants have made arrangements directly with the card brands, cashback is predominantly a
feature of PIN Debit. If the POS includes a prompt for cashback, the cashback flow requires several steps of
customer input on the device:
1.
Confirm the original purchase amount.
2.
Select Yes or No on Cashback.
3.
If Yes, select a pre-configured amount from $20 to $100.
4.
Reconfirm the total amount.
5.
Then Insert, Swipe or Tap card.
Because of the above flow, this feature requires careful attention because the type of card being used (credit or
debit) is unknown when cashback is selected. If the POS prompts for cashback and the customer selects an
amount, inserts a credit chip card or swipes a non-EMV credit card and selects credit, the transaction will fail with
the error message, Cashback Not Supported.
Note The card brands will support cashback for credit cards if special arrangements are made. This generally
applies to very large merchants.
Entry method fallback and prompting for manual entry
Fallback is a device mechanism that detects a bad chip read. When this occurs, the device will fallback to
magstripe entry.
If the device cannot read the chip, (for example if the chip is damaged), the VX805 will be unable to read it and
will display APPL NOT AVAILABLE USE MAG STRIPE, and when the card is removed, it will display Tap or Swipe
card. The consumer then proceeds to tap or swipe the card and the transaction processes normally.
Note All swiped transactions will trigger a prompt to select credit or debit. U.S. PIN Debit functionality will
be available by October, 2015.
If the device unable to read the card at all (chip or magstripe), the POS may prompt for manual entry. To do
this, after failed attempts or if the device returns Unsuccessful Card Read from PinPad, the POS can resend
the request and initiate a manual entry using <AcctNo>Prompt</AcctNo>.
Note Failed card reads could indicate fraudulent activity. Prompting for manual entry will incur a greater
processing rate and indicates potential fraud. Always accompany a prompt for manual with zip code and
street address AVS data.

2015 Mercury
Page 16 of 60
A Vantiv Company
Overview of Datacap Systems, Inc. dsiEMVUS

The Datacap dsiEMVUS uses a locally installed Windows ActiveX control, dsiEMVX, which serves as the application
interface between the POS, the EMV device, and Datacaps US EMV-certified in-store NETePay. The dsiEMVX:
directly controls an EMV device through a PC port (Serial/RS232 or USB using a Virtual COM port) to manage
all PIN pad interaction.
uses XML formatted requests and responses for transaction processing and makes all non-sensitive request
and response XML data available for POS payment logs.
The POS sends transaction XML commands to the dsiEMVX which then takes control of the remaining processing
flow:
The dsiEMVX manages the communication with the EMV-enabled device,

prompts the end-user,
gathers the required EMV data,
builds the transaction request, then
passes the request to an in-store NETePay which facilitates communication with Mercury for processing.
This first software release supports the VeriFone VX805 with Mercurys E2E encryption. This device supports all
CVMs (PIN, signature and none.)
EMV grade contactless is not supported with this initial software release. Contactless cards will be processed as
magstripe cards. This includes ApplePay, AndroidPay and other contactless entry methods.
Once boarded as an EMV merchant, standard U.S. PIN Debit will be unavailable until October 2015. Mercury is in
the process of migrating to Vantivs debit processing network, and PIN debit functionality will be unavailable
during the migration. Until then, debit cards should be routed through the credit networks. It is important to take
this into consideration as you build your EMV adoption strategy based on your existing business requirements.
Mercury/Datacap Systems U.S. EMV Configuration Information

Application
Datacap Systems Inc., DSIEMVX v1.0.0.1 , NETePay v5.06.10
EMV-Enabled PIN Pad Device
VeriFone Vx805, XPI 8.42b (E2E enabled)
Application PadType
VX805 Mercury (E2E)
Card Verification Methods
No CVM, Signature, Offline PIN, Online PIN (MasterCard only)
EMV Terminal Capabilities
Mercury E2E Encryption, Insert, Swiped, Keyed, MSD Contactless
SecureDeviceID
EMV_VX805_MERCURY
EMV Devices and the VeriFone VX805

Mercurys EMV devices require and support Mercurys end-to-end encryption. The VeriFone VX805 is the first
EMV-certified payment device customized for Mercury. More devices will be available over time.
The VX805 uses a software application built into the device called XPI, which controls the data reads from the
payment card. Mercury collaborated with VeriFone to create our version of the XPI, which supports encrypted
EMV chip reads, magnetic stripe, contactless/NFC and manual entry. There are two versions of this XPI in
circulation today: XPI 8.30G, and XPI 8.42B. Both versions support EMV, although XPI 8.42B is Mercurys preferred
version. All new devices ordered will contain this version.
Test VX805 EMV devices are available directly from your Integration Analyst.
Production VX805 EMV devices must be ordered through Mercurys certified key injection facility (KIF), The
Phoenix Group. Contact your Integration Analyst for details and order forms.

2015 Mercury
Page 17 of 60
A Vantiv Company
ISVs that already have Mercury VX805 devices should know that XPI 8.30G will support EMV chip reads, with one
difference in the consumer experience: the device has a feature enabled that will prompt for language. In XPI
8.42B the language prompt was removed. The language prompt can be removed from XPI 8.30G by following the
steps below. The parameter is LANGMODE, and can be changed in the sys mode menu. Do the following on the
VX805 device:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Press F2 and F4 at the same time

Enter the password: 1-alpha alpha-66831
Select Edit Parameters
Group 1 App not empty Press Enter
Enter the password: 1-alpha alpha-66831, then press Enter
Select #1 for NEW
Parameter = LANGMODE
Value = 1
Select New again
Parameter = #CZE
Value = 1
Cancel to the Main Menu and select RESTART
ISVs should make sure they are testing with the same XPI version that their merchants will be using.
If the VX805 test device is not loaded with either XPI 8.30G or 8.42B, it will need to be replaced. XPI cannot be
updated remotely.
Should the test device indicate an Out of Memory error, this can be corrected by updating the DHEAP
parameter. Do the following on the device:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Press F2 and F4 at the same time

Enter the password: 1-alpha alpha-66831
Select Edit Parameters
Group 1 App not empty Press Enter
Enter the password: 1-alpha alpha-66831, then press Enter
Select #1 for NEW
Parameter = *DHEAP
Value = 0
Select New again
Parameter = #CZE
Value = 1
Cancel to the Main Menu and select RESTART

2015 Mercury
Page 18 of 60
A Vantiv Company
Install and Configure the Datacap TEST Components

Below is a step-by-step guide for installing and configuring the Datacap components you will need to use for your
integration work and certification. In summary, you will:
Download and install the CERT NETePay
Setup the CERT NETePay
Retrieve your Test Merchant parameters
Redirect processing traffic to the CERT NETePay
Download and Install the dsiEMVX control
! Important Notes Before you begin
A working internet connection is required for this process
Firewalls should accept traffic on port 9000 (and port 9100 if using Gift)
Download and Install the CERT NETePay

1.
Download the PROD NETePay for Mercury In-Store.

a.
Go to: http://www.datacapepay.com/netepay5-mercuryoos.htm
You will see one or more tables listing
different versions of NETePay for Mercury
In-Store.
b.
Under NETePay for Mercury In-Store

Version 5.06.10, click Get under the
NETePay 5.0 column.
c.
The program will install to the default location: C:\Program Files(x86)\Datacap Systems\NETePay.
2.
Download the Mercury Certification NETePay for Mercury In-Store. This .exe is the CERT file and will
replace the production NETePay server addresses to point to the Mercury cert.net testing environment.
a. Go to: http://www.datacapepay.com/software/dev-netepay/mercury/version5dev/USEMV/
b. Click on the file DSIMercuryIP_Dial.exe to download it, then save it to your desktop.
3.
Replace the PROD file with the CERT file

Delete the PROD NETePay from the default location: C:\Program Files\Datacap Systems\NETePay
If there is a shortcut for this file on your desktop, delete it.
Copy and paste the CERT file from your Desktop into the C:\Program Files\Datacap Systems\NETePay
Create a shortcut for this file on your desktop (optional).
Setup the CERT NETePay

1.
The first time you launch the CERT NETePay, it will prompt you to obtain a serial number from Datacaps
PSCS (Payment Systems Configuration Server) system:

2015 Mercury
Page 19 of 60
2.
A Vantiv Company
Click Obtain Serial Number. If NETePay is successful in obtaining a serial number but is unable to locate
merchant parameters for the assigned serial number, you will see the following dialog box:
The dialog contains the 10-digit serial number that was
automatically assigned to NETePay.
3.
Click OK and a new dialog box will appear:
This dialog box indicates that NETePay has not yet retrieved
merchant parameters from Datacaps PSCS server. It cannot
operate until these parameters are downloaded.
4.
Click OK and you will be returned to the NETePay main status window.
If a parameter file has been created on Datacaps PSCS server by your Integration Analsyst proceed to the
next section below, Retrieve Merchant Parameters.
If a parameter file was not created, contact your Integration Analyst to create the merchant parameters.
Retrieve your Test Merchant parameters

1.
Open NETePay and select Setup.
2.
You will see the Setup Merchant Parameters screen.

Click Load New Parameters, and on the following
screen click Yes.

2015 Mercury
Page 20 of 60
A Vantiv Company
3.
A new screen displays. Click I have my DeploymentID. (This was provided to you by your integration analyst):
4.
In the dialog box that displays; enter the Deployment ID you received, then click OK.
5.
A new screen will display with merchant demographic data:
6.
If the information is correct, click Yes This is the Correct Merchant.

If the information is not correct, click Cancel and retry entry from the beginning of Step 3.
If NETePay successfully retrieves the parameters associated with the entered DeploymentID from the PSCS
server, you will see the following dialog box:
Click OK. You will be brought back to the Setup Merchant Parameters screen.
Redirect processing traffic to the CERT NETePay

The CERT NETePay has built-in processing configurations that point to our certification platform at
x1.mercurycert.net. Therefore, all processing traffic within your POS application should be directed to the local
NETePay you just installed. To do this, change the processing server "host list" address in your POS application
from x1.mercurycert.net to the IP of the local machine: 127.0.0.1. if your test environment is networked with
more than one computer, and the NETePay was installed on a separate computer, then point your workstation to
the IP Address of the computer where the NETePay was installed.
! Important Note NETePay must always be running to process transactions. We recommend the default
location in the POS system tray.

2015 Mercury
Page 21 of 60
A Vantiv Company
Download and Install the dsiEMVX control

Prerequisites: dsiEMVX requires TCP/IP networking and an available Windows COM port for attaching an input
device. RS-232 devices require a Windows COM port; USB devices require a virtual USB port and the appropriate
software driver. Your Integration Analyst will have all of these details.
In addition, the 128 bit cipher for Windows cryptographic services must be installed on the system running
dsiEMVX.
A link to the dsiEMVX control will soon be available on the Datacap NETePay 5.0 download page. Until then,
please go to: http://www.datacapepay.com/software/emvus/ and click dsiEMVUS-100-With-EMVUS-testApp-Install20150807-W8.exe. Both the dsiEMVX control and the EMV US Client Test tool are contained in the
downloaded package.
The download will automatically launch the install program. The files will be saved to the default location:
C:\Program Files\Datacap Systems\US EMV Client
Note When building your own POS installer program, we strongly recommend not to include the dsiEMVX
control. The EMV landscape is dynamic and many updates will be rolled out over time. It is important to always
download the latest version of dsiEMVX directly from Datacap.

1.
Connect the VX805 device to your computer.

Note If you are using USB cables, you should have received the USB device driver with your test device. Make
sure to install the driver . If you do not have the device driver, contact your Integration Analyst.
2.
Go to the Windows Control Panel > Devices and Printers (Windows 7) and verify that the VX805 is displayed. If you
are using USB, also check that virtual COM Port has been assigned. Note the COM port number, which will be used
in step 4 below.
3.
Double-click DSIMercuryIP_Dial.exe to run the NETePay software.
4.
Open the EMV US Client Test Tool (there should be a shortcut for this on your desktop). Configure the
following values:
5.
Merchant ID: 755847002.
Confirm the IP/Hostname is 127.0.0.1. (This allows communication to the previously installed local
NETePay on port 9000, which in turn communicates with Mercurys CERT environment.)
Change the COM port to the one your VX805 is attached to (from step 2 above). If using USB, the
VeriFone USB driver typically defaults to COM 9.
Enable EMV on the VX805:

a.
Click the EMV ParamDownload button. You will see the XML that is sent to the dsiEMVX.ocx.
b.
Click OK. The client will access the parameters that were initially installed with your NETePay and download
them to the device. The device will display please wait and then loading. It takes about one minute for the
configuration to load onto the device. When this is complete, the device will display re-initializing please wait,
then Welcome, then re-initializing please wait, then Welcome. A response XML will signal that that the
ParamDownload was successful and upon clicking OK, control will be returned to the test application. Your
device is now EMV enabled.

2015 Mercury
Page 22 of 60
A Vantiv Company
EMVUS Client Test Tool
When you first setup your VX805 device to accept EMV transactions, this tool provides a quick way to confirm that
you are communicating correctly with the device. It can also be used to run test transactions without writing the
XML, making it a convenient way to quickly see the request/response formats generated by the different
transaction codesall transaction requests and responses are saved to the test tools log files, located at:
C:\Program Files\Datacap Systems\US EMV Client. These log files are also helpful for troubleshooting.
Note You should also create XML log files for your POS application. In addition to the NETePay logs, these XML
logs are important and will be requested as a part of our EMV certification.
To run a transaction using the test tool
Open the tool and fill in the information on the screen as indicated below
Click the type of transaction you want to run. The XML request will display on the screen.
Follow the prompts on the device. When the transaction is complete the XML response will display.
1.
Pad/Processor: Select VX805 Mercury (E2E).
2.
Merchant/Setup Info:
Merchant ID: 755847002
Operator ID: test
IP/Hostname: 127.0.0.1
Com Port: enter your Com Port
3.
Amount fields:
Amount: use amounts under $10.99
TIP Amount: optional
Cash Back: optional
4.
Refnumber: incremented invoice number
5.
Use the TranCodes listed to discover the various

transaction flows (after completing 6 and 7
below)
6.
Transaction Modifiers:
Allow Partial Auth (Required)
Use Tokens (Required)

Check others as applicable
Check Clear Response Fields on New
Transaction when running a new transaction to
clear the previous information. Uncheck this box
to retain this information for Adjusts and VoidSales.
7.
8.
Figure 2. EMVUS Client Test Tool
Admin: This section contains administrative functions

PIN Pad Reset: should be sent after every transaction.
EMV ParamDownload: This must be run when you are first installing the VX805 device.

2015 Mercury
Page 23 of 60
A Vantiv Company
Mercury Supported EMV Commands, Functionality and TranCodes

Commands
ISV Commands
The following commands are helpful for ISVs:

Server Version. Used to confirm the NETePay Version.
GetDevicesInfo. Used to determine which SecureDevices are supported in the version of dsiEMVX along with the
device capabilities and characteristics.
Device Commands
EMVParamDownload is a device command that loads deployment parameters and security information
into the chip card reader. This command should be performed when a new device is first installed, when a
device is replaced, or as requested by the service provider.
An EMVPadReset is a device command which should be programmatically performed before every transaction to
ensure that a card was not left in the chip reader. If there is a card in the reader, the PIN pad will display Remove
Card and waits until the card is removed. Another EMVPadReset should then be sent to reset the device.
Functionality
Functions
Prompt for Manual
Prompt for Tip
Required/
Optional
O
O
Swiped Entry
Contactless Entry
Partial Approval
R
R
R
Admin Functions
BatchSummary
BatchClose
Notes
Prompt for manual; use as fallback for swipe
Use to prompt the cardholder for a tip (gratuity) which is
added to the total sale amount and sent as a single
transaction.
For non-chip cards, or as a fallback from chip
MSD/magstripe contactless
This a card brand mandate to allow card-present purchases to
be partially approved.
These functions are for POS systems that include a local,
merchant-initiated settlement function. Use BatchSummary to
retrieve current batch counts and amounts for comparisons,
and use BatchClose to close the current batch.
TranCodes
TranCodes
EMVSale
EMVVoidSale
EMVReturn
EMVVoidReturn
EMVVoiceAuth
EMVZeroAuth*
AdjustByRecordNo
VoidReturnbyRecordNo
VoidSaleByRecordNo
Required/
Optional
R
R
R
R
O
O
O
O
O
Notes
Built in support currently for all CVM: Signature, No CVM, Offline
PIN or Online PIN (MasterCard). dsiEMVX controls receipt
generation
EMVVoidSale and EMVVoidReturn may be supported for either
card-present or ByRecordNo
EMVVoidReturn may also be supported optionally by EMVSale
Card verification without authorization
ByRecordNo TranCodes use a token (RecordNo) to adjust a gratuity
on an EMVSale, reverse an EMVSale, or void an EMVReturn.
* Available for MasterCard, Visa and Discover. Amex requires an amount be included (no charge to cardholder account).
2015 Mercury
Page 24 of 60
A Vantiv Company
EMVSale. Transactions originating from an EMV-enabled device using the dsiEMVUS use a TranCode of EMVSale
even if a non-EMV card is swiped or manually entered.
EMVSale may be used to request a OneTime token by including <RecordNo> and <Frequency> in the request.
The token can then be used for adding a tip (gratuity) with AdjustByRecordNo.
Tokens may be requested as either OneTime or Recurring based your business needs.
An EMV SaleByRecordNo (which uses a token to originate a sale) is not supported when processing a
transaction to the dsiEMVUS; however, in conjunction with Datacap's dsiPDCX, all ByRecordNo
transactions are available.
AdjustByRecordNo. Uses tokenization to add a tip (gratuity) amount to an EMVSale.
Not available for offline or online PIN credit transactions or for any U.S. PIN Debit transactions.
Applicable in restaurant environments in place of PreAuthPreAuthCapture.
Does not require card-present interaction.
EMVVoidSale. Always card-present on the EMV-enabled device. This transactions is sent as a reversal.
Although the TranCode is VoidSale, the transaction request must include the Process and AcqRefData
elements. This allows the request to be sent directly to the Issuer. The XML response will indicate
REVERSED.
VoidSaleByRecordNo (using a token) is available for card-not-present VoidSales, also sent as a reversal.
EMVReturn. Use to run a card-present refund on an EMVSale.
EMVVoidReturn. Voids a Return; card-present.
VoidReturnByRecordNo (using a token) is available for card-not-present VoidReturns.
EMVVoiceAuth. Used to capture a transaction that was authorized by one of the card brand automated
telephone services, typically after a call referral message.
A voice authorization is primarily used when Mercury returns a Decline-Call referral message with a
TextResponse such as CALL CENTER, CALL AMEX or CALL DI. The merchant then contacts the automated
voice-authorization system (using the number included in their Mercury Welcome kit) to obtain a six-digit
authorization code (AuthCode).
Receiving the AuthCode assures the merchant that the card is good and has credit available. Completing the
voice authorization captures the funds for the merchant at settlement.
EMVZeroAuth. (Available for MasterCard, Visa and Discover). Enables card verification without charging the
card. Used to determine if a card has been reported lost or stolen; may be used in with AVS and CVV; may
be used to initiate a bar tab.
A quick word about Mercury's Tokenization with dsiEMVX
TM
TranCodes that end with ByRecordNo use Mercurys secure tokenization technology, MToken . Merchant
IDs are configured to enable the return of a token with each supported transaction, which can then be used
for subsequent supported transactions (the supported transactions all end with ByRecordNo.)
Gift/PrePaid, Debit, and EBT are examples of unsupported transaction types for which a ByRecordNo
TranCode is unavailable. The Merchant ID configuration in this case ignores the token request and does
not generate a RecordNo in the response.
Because of the card present nature of EMV, an EMVSaleByRecordNo is also unavailable.
Card-on-File or recurring billing programs can be implemented in conjunction with dsiPDCX.
! Important Note Tokens may only be used with EMV CVMs returned as SIGNATURE or NONE. Card brands
will reject transaction submitted ByRecordNo for CVMs returned as PIN VERIFIED. See Mercurys Brand of
Tokenization for more details.

2015 Mercury
Page 25 of 60
A Vantiv Company
Example of a dsiEMVUS XML Request and Response

The EMV transaction request and response use the same XML format as all of Mercurys solutions.
XML Request
All Mercury EMV transactions use end-to-end encryption. We highly recommend using tokenization as well. The
following example is an EMVSale and includes a token request (RecordNo).
Request
<TStream>
<Transaction>
<HostOrIP>127.0.0.1</HostOrIP> 
<IpPort>9000</IpPort>
<MerchantID>755847002</MerchantID>
<LaneID>02</LaneID> 
<TranCode>EMVSale</TranCode> 
<SecureDevice>EMV_VX805_MERCURY</SecureDevice> 
<ComPort>9</ComPort>
<InvoiceNo>452</InvoiceNo>
<RefNo>452</RefNo>

<Amount>
<Purchase>8.18</Purchase>
</Amount>
<SequenceNo>0010010000</SequenceNo> 
<RecordNo>RecordNumberRequested</RecordNo> 
<Frequency>OneTime</Frequency>
<PartialAuth>Allow</PartialAuth>
11
<Memo>Your POS Memo v1.0 EMVUS</Memo>
<OperatorID>Test</OperatorID> <!configurable. Only use Test for testing-->
<UserTrace>DEMO</UserTrace>
</Transaction>
*<HostOrIP>: 127.0.0.1 is a local machine IP address indicating that the NETePay is installed on the same computer as the POS
application. In networked environments using multiple POS workstations and a single NETePay server, this HostOrIP will always be
the IP address of the computer where the NETePay is installed.
Figure 3.Example of an XML Request
1.
<MerchantID> (MID) Mercury merchant accounts are set up with a primary Merchant ID that is used to identify
the account both internally and externally for POS configuration and for use in transmitting banking information
and deposits.
MID settings are configured by Mercury with a range of attributes that parallel the POS systems functionality. If
not in sync with the POS system, these configuration flags can render the merchant location unable to process.
For example, if the POS is processing using E2E, then the MID must be enabled to allow E2E.
2.
<LaneID> is required for multi-terminal merchants for all card-present transactions sent to Mercury. Each
terminal or input device must have a unique, alphanumeric identification with a maximum of 3 characters. No
special characters, dashes or slashes. If the POS does not send a LaneID the in-store NETePay will generate
one.
3.
<TranCode> indicates the type of transaction being submitted (EMVSale, EMVReturn, etc.) All EMV TranCodes
start with EMV.
4.
<SecureDevice> This is the unique identifier for the device being used. EMV_VX805_Mercury is for the
VeriFone VX805 device, which is the first device supported by Mercury for EMV transactions. Additional
identifiers will be added as more EMV certified devices become available through Mercury.
5.
<ComPort> This is the COM Port the device is connected to. There are two ways to connect a device:
RS-232/Serial devices require a COM port value. Set this to the port number the device is connected to.
USB devices require a USB port and the appropriate software driver which will create a virtual COM port.
The device driver is available from your Integration Analyst.

2015 Mercury
Page 26 of 60
6.
A Vantiv Company
<InvoiceNo> and <RefNo>

a. The InvoiceNo is a locally generated, always incrementing transaction number with a very specific Mercury
function. This InvoiceNo logic may be kept unique from existing POS numbering logic (also referred to as
order, ticket, check, or receipt number) especially in the case of split tenders. Each transaction that is
processed with separate cardholder data, including each individual split tender, requires a unique
InvoiceNo.
For example, if the POS presents a ticket number #1234 for $100 and this ticket is split among four credit
cards, then the POS would need to generate four separate receipts, each with its own unique InvoiceNo
specific to each of the four cardholders.
InvoiceNo format: Length: 16 max, Right 10 unique; Data Type: Numeric only
InvoiceNo logic: although a maximum length of 16 is allowed, only the right-ten digits are submitted for
processing and are critical for identifying duplicate transactions. Therefore, these right 10 numbers must be
unique per transaction. In addition, all-numeric zeroes, alpha characters, dashes or special characters may
not be used.
b.
RefNo is both a filler value on the transaction request and a true value assigned by Mercury which is
returned in the transaction response. It indicates that an approved transaction has been referenced and
logged in the merchants current batch file.
RefNo is the item number logged and incremented within each batch for each transaction. Upon batch
close, the RefNo counter resets for the next batch. The first transaction is typically assigned RefNo 1001 or
5001; the second transaction is RefNo 1002, or 5002 and so on. It is important to note when an actual RefNo
value is returned and to use that RefNo value when required for subsequent transactions.
Use the actual returned RefNo value whenever submitting a subsequent transaction that modifies an
originally referenced transaction. For example, use the actual RefNo value when running an EMVVoidSale
against an EMVSale, or when using AdjustByRecordNo for a tip modification.
Note For initial unreferenced transaction requests such as EMVSale, we recommend including the
RefNo with a filler value(coded as RefNo=InvoiceNo). The transaction response will then return the actual,
batch-specific RefNo value. The actual RefNo value is used in any subsequent transaction as a reference to
the original transaction, such as EMVVoidSale.
7.
<Amount> This contains the requested purchase amount and is always presented in two decimal places (0.00).
It may also contain gratuity. To prompt for gratuity, include <Gratuity>Prompt</Gratuity>.
8.
<SequenceNo> This is required to be included in the XML request, and is currently reserved for future use.
9.
<RecordNo> and <Frequency> These two tags are used in Mercury's proprietary tokenization method. On the
MercuryPay platform, tokens are referred to as RecordNo. A RecordNo will be requested with two tags:
a.
b.
the Frequency of the token requested (OneTime or Recurring), and

either a request for token (RecordNumberRequested) or the actual token returned in the original
response.
See Mercurys Brand of Tokenization below for more details.
10. <PartialAuth> Use of this data element is mandated by the Card Brands (MasterCard and Discover)
specifically in response to the growing use of Prepaid and Card Branded Debit cards. Use of this tag will
allow a partial approval if the balance on the card is less than the purchase amount requested. The
transaction will approve for the available balance on the card and will not decline the transaction.
In the transaction response, two data elements can be used to recognize and calculate the Partial
Authorization:
the POS will be alerted to the partial approval with a TextResponse of PARTIAL AP, and
the <AuthorizedAmount> which will be less than the original purchase amount. It is important to
compare the AuthorizeAmount to the original Purchase Amount to determine the balance due.
The PARTIAL AP response requires ISVs to build in split-tender functionality that recognizes the partial
approval and prompts for a balance due. If the cardholder is unable to complete the balance due transaction,
the ISV is required to send a Reversal/VoidSale of the partially approved amount.
2015 Mercury
Page 27 of 60
A Vantiv Company
Note The PartialAuth=Allow tag should ONLY be used in EMVSale requests.

Use of the PartialAuth tag is required for any ISV who supports Void Sales/reversals. A transaction cannot be
reversed without the use of the PartialAuth in the originating transaction.
11. <Memo> Placed in all XML transaction requests, the Memo tag is used to identify the POS name and version.
For dsiEMVUS integrations, include EMVUS in the memo tag. This will help our technical support teams to
more quickly identify and troubleshoot potential issues.
Recommendation Dynamically build the Memo tag so that it pulls the product name and version from
your application. This way the Memo stays current as the application version changes. Send the POS name
and version number in the following format: Length: 40 maximum; Data Type: Alpha-Numeric; Position:
<Transaction> level. Example: <Memo>POS NAME v1.10A-08 EMVUS</Memo>
XML Response
All transactions routed through Mercury return a similar XML response. This response, the <RStream>, contains only
non-sensitive, truncated or tokenized cardholder data elements, and may be used to validate the transaction, build
receipts, build records for internal POS reporting, and for storing for subsequent use.
The response XML is divided into three sections:
<CmdResponse> indicates the origin of the response (Processor, Server, Client), the status of the authorization
response (Approved, Declined, Success, Error) and important verbiage in the <TextResponse> field.
<TranResponse> provides all of the response details, transaction routing identifiers, and (if requested) a token
for subsequent use.
<PrintData> provides information to be printed on the receipt.
<?xml version="1.0"?>
<RStream>
<CmdResponse>
<ResponseOrigin>Processor</ResponseOrigin>
<DSIXReturnCode>000000</DSIXReturnCode>
<CmdStatus>Approved</CmdStatus>
<TextResponse>APPROVED</TextResponse>
<SequenceNo>0010010000</SequenceNo>
</CmdResponse>
<TranResponse>
<AcctNo>************0010</AcctNo>
<AuthCode>30592A</AuthCode>
<CardType>VISA</CardType>
<TranCode>EMVSale</TranCode>
<CaptureStatus>Captured</CaptureStatus>
<RefNo>1001</RefNo>

<OperatorID>Test</OperatorID>
<Amount>
<Authorize>8.18</Authorize>
</Amount>
<RecordNo>dyowoK8BIOAG3UQ7atfo/8ej6JShzNBtEkxo1EbSmaAiEgUQECIQGRZI</RecordNo> 
<AcqRefData>aAb314282069480098c1234d e000</AcqRefData>
<ProcessData>|00|410100500000</ProcessData>
<EntryMethod>CHIP</EntryMethod>
<Date>07/06/2015</Date>
<Time>10:12:38</Time>
<ApplicationLabel>Visa Credit</ApplicationLabel>
<AID>A0000000031010</AID>
<TVR>8000008000</TVR>
2015 Mercury
Page 28 of 60
A Vantiv Company
<IAD>06010A03602000</IAD>
<TSI>6800</TSI>
<ARC>00</ARC>
<CVM>SIGN</CVM>
</TranResponse>
<PrintData> 
<Line1>.MERCHANT ID: 337234005</Line1>
<Line2>.CLERK ID: Test</Line2>
<Line3>.</Line3>
<Line4>.
SALE
</Line4>
<Line5>.</Line5>
<Line6>.************0010</Line6>
<Line7>.VISA
ENTRY METHOD: CHIP</Line7> 
<Line8>.DATE: 07/09/2015 TIME: 07:40:26</Line8>
<Line9>.</Line9>
<Line10>.INVOICE: 07092015073925283</Line10>
<Line11>.REFERENCE: 1001</Line11>
<Line12>.AUTH CODE: 30592A</Line12>
<Line13>.</Line13>
<Line14>.AMOUNT
USD$ 8.18</Line14>
<Line15>.
==========</Line15>
<Line16>.TOTAL
USD$ 8.18</Line16>
<Line17>.</Line17>
<Line18>.
APPROVED - THANK YOU
</Line18>
<Line19>.</Line19>
<Line20>.I AGREE TO PAY THE ABOVE TOTAL AMOUNT</Line20>
<Line21>.ACCORDING TO CARD ISSUER AGREEMENT</Line21>
<Line22>.(MERCHANT AGREEMENT IF CREDIT VOUCHER)</Line22>
<Line23>.</Line23>
<Line24>.</Line24>
<Line25>.</Line25>
<Line26>.x_______________________________________</Line26> 
<Line27>.
Cardholder Signature
</Line27>
<Line28>.</Line28>
<Line29>.</Line29>
<Line30>.Application Label: CREDIT VISA</Line30>
<Line31>.AID: A0000000031010</Line31>
<Line32>.TVR: 0000008000</Line32>
<Line33>.IAD: 06010A03608000</Line33>
<Line34>.TSI: F800</Line34>
<Line35>.ARC: 00</Line35>
<Line36>.CVM: SIGN</Line36>
</PrintData>
</RStream>
Figure 4. Example of an XML Response
<CmdResponse> tags
1.
<Response Origin> indicates the source of the response:

Client indicates that the response is from the dsiEMVX control
Server indicates it is from Mercury's platform servers or the locally installed NETePay
Processor indicates that the response is from Mercury processing networks
2.
<DSIXReturnCode> contains either a server-specific or dsiEMVUS-specific TCP/IP six-digit code corresponding

to a single or dynamically generated message text. See Appendix 2 for details on these codes.
3.
<CmdStatus> and <TextResponse>

a. <CmdStatus> indicates the outcome of the transaction:
For Credit transactions: the value returned will be Approved or Declined.
For Admin requests: the value returned will be Success or Error. Error text responses are listed in
Appendix 2.
b. <TextResponse> is used to qualify the <CmdStatus>.

2015 Mercury
Page 29 of 60
A Vantiv Company
Approved Text Responses

Value
Description
APPROVED
transaction approved by processor
PARTIAL AP
The response is based on the use of <PartialAuth> ALLOW</PartialAuth> in the

request;
it may require a split tender and a balance-due prompt;
always confirm <Authorize> amount approved.
AP NEW INFO or
AP-NEW INFO
optional message; account information is updatedthis is often the address or

expiration date
AP*
Indicates that duplicate logic is enabled and has detected the same card, the same
amount, and the same invoice number in a second transaction in the same batch; it is
paired with <CmdStatus>Approved</CmdStatus> and assures that the cardholder is
charged only once.
(Reports as AP DUPE)
AP NOT CAPTURED
Credit, Debit, EBT and Check response: Transactions are being sent to the back-end
processing networks but are not being captured or logged with the issuing bank.
Typically this only occurs prior to a back-end network outage. It requires the transaction
to be resent for authorization.
REVERSED
Credit reversal response: The transaction was acknowledged as reversed by the cardissuing bank when sending a reversal (VoidSale + AcqRefData + ProcessData).
Figure 5. Approved Text Responses
Declined Text Responses

Declined TextResponse values vary according to the source of the message and whether the decline was due to an
issuer-level response or if there was an error in the processing of the transaction. Below is a condensed list:
Value
DECLINE
CALL xxx Referrals

PIC UP
DECLINED-CV2 FAIL
INVALID EXP DATE
INVALID PIN
UNAUTH USER
"NO TRAN FOUND"
"INV ITEM NUMBER"
Description
Authorization was declined based on issuing bank response. Card brand regulations
stipulate that declines should not be re-attempted but should be followed-up with a
request for a second form of payment.
Issuer has placed a notice on the card and requests the merchant to call for a Voice
Authorization. xxx = CENTER, AMEX, or Discover.
Authorization declined; authorization network requests picking up the card and
reporting. See card brand regulations for details and appropriate action.
Card brand response for CVV2 mismatch. (AMEX uses INVLD CID)
Expiration date entered is incorrect, invalid or no longer current.
Incorrect PIN entered on Debit or EBT transaction.
Merchant setting does not allow debit (may also be seen with EBT).
Failed Reversal attempt.
Typically triggered by an invalid RefNo used in VoidSales or an Adjust.
Figure 6. Declined Text Responses
Recommendation It is important that the POS interprets and passes appropriate response messages, as well as the
corresponding alerts and prompts to the end-users of their system. Merchants should be able to see the
TextResponse of decline messages such as DECLINED CV2FAIL, Call CENTER, PIC UP, etc., so they can take appropriate
action if needed.

2015 Mercury
Page 30 of 60
A Vantiv Company
<TranResponse> tags
The <TranResponse> portion of the response contains all relevant transaction details:
1.
<MerchantID> is returned without the = sign and "Nick Name".
2.
<AcctNo> and <AuthCode> For PA-DSS validated application, this data may be stored with strong encryption
until batch close in order to support a possible VoidSale or Adjust.
<AcctNo> returns the Account number with all but the last four digits of the number masked (*****)and,
<AuthCode> When used in conjunction with a Reversal or VoidSale is always returned in the <TranInfo>
section, typically with AcqRefData and ProcessData.
3.
<CardType> and <TranCode> indicate the card type entered and the dsiEMVUS transaction code submitted.
4.
<Capture Status> will inform the POS if the transaction was Captured or Not Captured.
5.
<RefNo> and <InvoiceNo> The RefNo returned in the TranResponse is the actual, true transaction reference
number returned for any approved transaction in the current open batch. For any subsequent transactions such
as VoidSale or Adjusts, this true <RefNo> must be used in place of the filler value. The InvoiceNo is passed back
directly from the original request.
6. <Amount> tags always return both the original purchase amount and the actual authorized amount. Compare
these two amounts for Partial approvals. Additional amount tags vary based on the transaction and TranCode
used, such as Gratuity.
7.
<RecordNo> is the returned token reference number. RecordNo may be stored for subsequent use with any
ByRecordNo transactions. Min/Max length varies from 48 to 100 alpha-numeric characters.
8.
<AcqRefData> and <ProcessData> contain multiple subfield strings of card association required identifiers,
market data and transaction routing references Allow Min/Max length values from 1-200 alpha-numeric
characters for AcqRefData and 12-40 alpha-numeric characters for ProcessData. Both fields must be submitted
with all reversal requests. When submitted these fields are always included in the TranInfo data node.
9.
<EntryMethod> through <CVM> are EMV specific tags that capture print data elements for reporting purposes:
Entry Method: Indicates how the card information was obtained:

- Chip
- Contactless (MSD/Non EMV Grade)
- Swiped
- Chip Fallback/Swiped if the chip insert could not be read
- Chip/Manual manually entered chip card
- Manual manually entered non chip card
Date: Transaction date
Time: Transaction Date
Application Label: Indicates card brand and transaction type (credit, debit, etc.)
AID - Application Identifier
TVR - Terminal Verification Results
IAD - Issuer Application Data
TSI - Transaction Status Indicator
ARC - Application Response Code
CVM - Card Holder Verification Method (CVM)
Fallback is a mechanism within the chip card reader that detects a bad chip read. If this occurs, the reader
prompts the consumer to swipe the card instead. For example, the VX805 will display, "APPL NOT
AVAILABLE USE MAG STRIPE" followed by, when the card is pulled out, "Tap or Swipe card". If the tap or
swipe fails, manual entry may optionally be used.
<PrintData>
This section contains the data to be printed on the receipt except for the merchant information in the header and
footer. More details are provided in the Receipt Requirements section below.
2015 Mercury
Page 31 of 60
A Vantiv Company
Receipt Requirements
Whether a transaction is APPROVED, DECLINED, ERROR or CANCELLED, and especially if PrintData is returned in
the response, it is important to be able to produce the required receiptstypically one for the cardholder and one
for the merchant to retain.
The merchant's copy may be stored electronically.

Customer copies must always be available upon customer request.
EMV PrintData is entirely managed by the dsiEMVUS and returned to the POS in the <PrintData> section of the
XML response. The POS application must supply the merchant receipt header information (typically merchant
name, address, phone number and/or email) and the footer information (Cardholder Copy and Merchant Copy).
Below are two examples of EMV receipts, one with a CVM of Signature and one PIN Verified:
MERCHANT NAME
MERCHANT STREET
CITY, STATE ZIP
123-456-7890
MERCHANT NAME
MERCHANT STREET
CITY, STATE ZIP
123-456-7890
MERCHANT ID: 337234005

CLERK ID: test
MERCHANT ID: 337234005

CLERK ID: test
SALE
************0010
VISA
ENTRY METHOD: CHIP
DATE: 06/22/2015
TIME: 14:58:15
INVOICE: 1002
REFERENCE: 1002
SALE
************0010
VISA
ENTRY METHOD: CHIP
DATE: 06/22/2015
TIME: 16:56:36
AUTH CODE: 30290A
INVOICE: 1003
REFERENCE: 1003
AUTH CODE: 28843A
AMOUNT USD$ 2.56

==========
TOTAL USD$ 2.56
AMOUNT USD$ 2.57

==========
TOTAL USD$ 2.57

I AGREE TO PAY THE ABOVE TOTAL AMOUNT
ACCORDING TO CARD ISSUER AGREEMENT
(MERCHANT AGREEMENT IF CREDIT VOUCHER)

BY ENTERING A VERIFIED PIN, CARHOLDER
AGREES TO PAY ISSUER SUCH TOTAL IN
ACCORDANCE WITH ISSUER'S AGREEMENT WITH
CARDHOLDER
x_________________________________
Application Label: Visa Credit
AID: A0000000031010
TVR: 0008008000
IAD: 06010A03649000
TSI: F800
ARC: 00
CVM: PIN VERIFIED
Application Label: Visa Credit

AID: A0000000031010
TVR: 0000008000
IAD: 06010A03608800
TSI: F800
ARC: 00
CVM: SIGN
Chip and Signature
Chip and PIN

Figure 7. Receipt Examples
Note ByRecordNo transactions (that is, transactions using a token) do not generate PrintData, and receipt
generation would follow standard non-EMV criteria.

2015 Mercury
Page 32 of 60
A Vantiv Company
Cancelled and Declined Receipts

The dsiEMVUS generates different XML responses for errors and cancelled transactions. How these messages are
communicated is at the discretion of the ISV.
At this time, only MasterCard requires that receipts be made available on declined transactions. The following EMV
information appears on all declined transaction receipts:
AIDApplication Identifier
TVRTerminal Verification Results
TSITransaction Status Indicator
IADIssuer Application Data
ARCApplication Response Code
How dsiEMVUS handles Signature, PIN Verified and No CVM
Credit Chip and Signature. If the cardholder verification method (CVM) is determined to be chip and signature
(CVM: SIGN), or if the card presented is a non-chip card, then the PrintData will be generated with a "Cardholder
Signature" line.
The merchant should always have the cardholder sign the Merchant Copy of the receipt, then retain this copy for
their records.
Credit Chip and PIN. If the cardholder is prompted to enter a PIN during a transaction and does so successfully, the
PrintData will indicate that the cardholder was PIN VERIFIED. If PIN entry is unsuccessful, the PrintData will include
a signature line for the cardholder to sign.
No CVM. In the event of a NO CVM, which is allowed in quick-serve restaurants, neither a signature line nor PIN
prompt is required.
EMVReturn and EMVVoidSale. The PrintData returns with Merchant Signature.

2015 Mercury
Page 33 of 60
A Vantiv Company
Mercury Supported Functionality

Mercurys End-to-End Encryption (E2E)
All Mercury EMV devices use end-to-end encryption for added card data security.
All Mercury supported encryption devices are injected with Mercurys custom keys and only Mercury's secure
platform is capable of the decryption.
Devices are distributed for either testing or for production. Per PCI requirements, testing devices may only be
used in testing environments, and production devices may only be used in production environments.
No additional work is required by the ISV; the encryption/decryption activities occur between the device and our
platform.
MTokenTM: Mercurys Brand of Tokenization

MToken is Mercurys proprietary technology that replaces sensitive cardholder data with a token record number
for POS system storage and subsequent use. A token is returned to the POS system with the transaction
authorization approval response. It can then be used to perform any subsequent transaction if required, or stored
securely if recurring billing is supported.
Tokens are unique, dynamically-generated reference numbers. They are used to replace sensitive card data with
an encrypted code for security purposes. There is no key loaded or injected into any external device. A token is
uniquely generated at Mercury per transaction and is returned to the POS in a standard Base64 format. Mercury is
the sole holder, generator and custodian of the process that generates and then unlocks a token.
Token/RecordNos vary in length depending on card data and it is important to code for up to Length: 100 alphanumeric and special characters in the response. Data Type: Alpha-Numeric; Position: <Transaction> level.
Tokens are only generated by request. This is done using a standard XML transaction request with two additional
tags: <RecordNo> and <Frequency>. Token frequencies may either be for OneTime use or for Recurring, card-onfile environments.
A OneTime token expires 6 months from the date the token record is generated. With each subsequent use a
new token is generated and returned, adding an additional 6 months. One-time tokens are recommended for
all daily use transactions or for "card-on-file" supported systems and used for non-recurring, card-on-file
transactions.
A Recurring token expires 24 months from the date the token record is generated. With each subsequent use
a new token is generated and returned, adding an additional 24 months. Recurring tokens are used for
environments where weekly, monthly or annual subscription billing is implemented. Recurring tokens are not
recommended for daily transaction activity.
Mercury processes the transaction, and then generates a RecordNo based on the request criteria, which replaces
the account number and expiration date. This RecordNo is then passed back to the local POS with the authorization
response. The POS, per business need, may store the token as-is for future use. The token can only be unlocked
and decrypted by Mercury.
Merchant accounts are set up to reflect POS system tokenization capability. If the merchant is setup for
tokenization and both RecordNo and Frequency tags are in the request, then Mercury will build and return the
token record on all credit responses.
Initial Token Request
Tokens must be requested for every transaction. This is done using two additional tags in the standard XML
request: <RecordNo> is used to request a token record, and <Frequency> is used to define the specific type of
token to be generated.
The initial RecordNo element will always contain RecordNumberRequested.
The Frequency element has two options:

2015 Mercury
Page 34 of 60
A Vantiv Company
OneTime token used in subsequent transactions.

Recurring tokens used for recurring billing.
Frequency values must stay consistent in all subsequent uses of MToken requests. Inconsistent use of
Frequency will cause the subsequent transaction request to fail with the following error:
Error # 004119- Token Service Unavailable. - 200 Response With Status:
Failure Message: Parse token failure.
Subsequent Token Use
Once the token is passed back to the POS, all subsequent requests will use the ByRecordNo TranCodes. The table
below lists the dsiEMVUS TranCodes for Token Requests and the corresponding subsequent usage ByRecordNo
TranCodes:
TranCodes with Token Request
EMVSale
EMVReturn
EMVVoidSale
EMVVoidReturn
TranCodes for Subsequent Use of Token

AdjustByRecordNo
ReturnByRecordNo
VoidSaleByRecordNo
VoidReturnByRecordNo
When building a ByRecordNo XML request, use the appropriate ByRecordNo TranCode from the above table and
replace the entire Account level tags with the actual token using the RecordNo tag. Note, too, that the Frequency
must match the original requested token frequency.
Using Tokenization for Recurring Billing
The initial and subsequent use of tokens requested for recurring billing purposes follows the same set of XML
requests except that the initial frequency is requested as Recurring. Recurring token records expire after 2 years.
When used, Recurring tokens will appear on the cardholders statement as a Recurring Charge and may be
subject to additional issuer fees.
MToken Error Responses
There are four categories of MToken error responses: Connectivity, Merchant Check, Invalid Fields and Corrupted
Data errors.
Error Category
Error
TxtResponse
Connectivity Errors
service is unavailable
Decryption Service Unavailable. Status Code Not 200 503
Token Service is unavailable
Token Service Unavailable.- 200

Response With Status:Error
Message:Error generating token
Merchant Check
For a tokenization request to
be validated, merchants must
be set up in the Mercury
merchant tokenization tables
AND
send both required
tokenization data elements.
RecordNo and Frequency are in the request,

but the merchant is not setup for
tokenization
Merchant Setting Does Not Accept

RecordNo and Frequency.
Invalid or missing fields
RecordNo is missing in the data element

field.
Frequency is missing in the data element
field.
There is corrupted data in the RecordNo
element, there is a mismatch in token
frequency, or the token has expired
Merchant Setting Requires RecordNo
Corrupt Frequency error
Invalid Field-Frequency
Corrupt RecordNo
Merchant is setup for tokenization, but the

request is missing the RecordNo and
Frequency elements

2015 Mercury
Merchant Setting Requires RecordNo

and Frequency.
Invalid Field-Frequency
Token Service Unavailable. 200
Response With Status:Failure
Message:Parse token failure
Page 35 of 60
A Vantiv Company
Storing Tokens
Only store a token record if there is a business need and if this information supports your targeted
business/merchants.
Build retention and expiration timelines for any stored token record. Note that because of truncated card
expiration data returned in the token response, ISVs should, if needed, obtain the expiration date prior to
processing the request.
Always dispose of expired token records.
Tokens are dynamically refreshed per use. A new token record will always be returned with each subsequent
transaction. If storing token data, store only the most recent token record returned.
Additional MercuryPay Processing Features

Mercury provides many additional processing features, summarized below. Refer to the Mercury Platform
Integration Guide for more details.
Checking for Duplicate Transactions
Mercurys duplicate logic screens for unintended duplicates within a current open merchant batch. This logic
incorporates the following variables:
Card number
Amount
Transaction Type (TranCode)
InvoiceNo
Avoiding duplicate transactions requires implementing an always-incrementing invoice logic.
Handling Transaction Time-Outs
On rare occasions due primarily to connectivity-related issues, transaction requests can timeout while waiting for a
response or timeout en-route. Error responses will be returned depending on where in the transaction cycle the
communication failed.
When these connectivity errors are returned it is important to handle them effectively in order to avoid potential
duplicates. In these cases, the merchant is unsure whether the transaction was actually approved by the processor.
Using Card Security Codes and Address Verification in Card-Not-Present Transactions
Issuing banks consider manually entered (keyed) credit card information (vs. swiped using a card-reader) to have a
higher risk of fraud. Merchants have two options to help reduce this risk: using AVS (Address Verification Service)
and/or CVV (Card Verification Data) when accepting card-not-present transactions, or when accepting manuallyentered (keyed) input in card-present merchant locations. The use of these options also enable merchants to
qualify for better processing rates.
Duplicate Logic
EMV duplicate logic has the same capabilities as Mercury's magnetic stripe processing and uses the InvoiceNo to
differentiate between an intended and an unintended duplicate:
Intended duplicates happen in the normal course of business when the same item is purchased using
the same card more than oncesuch as in a coffee shop. The invoice is incremented per purchase and
the card is charged accordingly.
Unintended duplicates happen when the POS re-sends the same transaction, typically due to a
communication failure or timeout. In this case the transaction will have the same card number, same
amount and same invoice number. Mercury compares these three items, and if the first transaction
was indeed received and authorized, responds by charging the card only once and returns an
Approved/AP* in the XML response to the POS application.

2015 Mercury
Page 36 of 60
A Vantiv Company
Using dsiPDCX as a Complement to dsiEMVUS

Mercury recommends ISVs implement dsiPDCX as a complement to dsiEMVUS if they wish to support any of the
following:
CardLookup
Card-on-file
CheckAuth
EBT FoodStamps and/or EBT Cash
FSA
Mercury Gift and StoreCard
Sale by RecordNo
All transactions supported by dsiEMVUS should be sent through dsiEMVUS. In most cases this includes all credit
and debit transactions. Note that dsiEMVUS and dsiPDCX do NOT interact with each other; they are two separate
controls. If you wish to use dsiPDCX together with dsiEMVUS, a common approach is to create two separate
objects in the code, then determine at runtime which object the XML should be routed to.
The same MerchantID (MID) can be used for both dsiEMVUS and dsiPDCX.
All transactions can be sent to 127.0.0.1 which is the local, in-Store NETePay address; NETePay will then direct
the transaction to Mercurys servers.
Gift/Prepaid transactions can be routed to the in-Store NETePay. The in-store NETePay will automatically
route the transaction to the correct Mercury endpoint.
The Secure device is different:

o
o
dsiEMVUS: EMV_VX805_MERCURY
dsiPDCX: VX805XPI_MERCURY_E2E
The EMVParamDownload is the preferred way to initialize the device.

Note SecureDeviceInit for dsiPDCX should not be done on a device after an EMVParamDownload
(dsiEMVUS) has been performed as this can change settings in the device that have an impact on EMV.
Specifically, the SecureDeviceInit disables contactless EMV if it has been enabled as part of the
EMVParamDownload. This is only important when using both dsiPDCX and dsiEMVUS to communicate with
the same device. EMVParamDownload should be visible only on the administrators screen in the POS, as it
will be rare for a merchant to send this command.
For more information about integrating to dsiPDCX, refer to the dsiPDCX Mercury Platform Integration Guide
Supplement.

2015 Mercury
Page 37 of 60
A Vantiv Company
Certification and Limited Release

Certification Process
1.
Transaction Review. Once your POS application is ready your Integration Analyst will provide you with a Test
script. You must complete all of the indicated transactions, and your Integration Analyst will review the results
to identify any errors that must be corrected.
2.
Compliance Letter. Upon successful completion of the transaction review, your Integration Analyst will
provide you with a dsiEMVUS Compliance Declaration letter that must be signed and returned to Mercury.
3.
Registration. Once your application has been certified by Mercury, you will need to complete and submit an
Authorized Reseller Application with Datacap before obtaining and installing the live, production-ready
NETePay. This application may be filled out at the following link: http://datacapsystems.com/resellerapplication (if clicking this link does not work, please paste it in your browser).
Note Any resellers distributing dsiEMVUS will also need to submit this Authorized Reseller Application form
with Datacap.
Certification Network Testing Information

Test Server
MerchantID
x1.mercurycert.net (with dsiEMVUS, use NETePay local server address 127.0.0.1, Port 9000)
755847002 (E2E/Token) (additional MIDs available upon request)
You will be provided with a set of four test EMV chip cards and one test magstripe card:
Test Card
B2 chip card # 01 Visa
B2 chip card # 02 Visa
B2 chip card # 10
MasterCard
B2 chip card # 12
MasterCard
Mercury test card
Card Number
4761 7390 0101 0010
4761 7390 0101 0010
Date
12/2018
12/2018
Serv Code
201
201
CVM*
Signature
Offline PIN
AID
A0000000031010
A0000000031010
5413 3300 8901 0434
12/2018
201
No CVM
A0000000041010
5413 3300 8901 0434
12/2018
201
Online PIN
A0000000041010
any test card #3 - #8
----
----
None
-----
*CVM (Card Verification Methods) are determined by the Issuer and the EMV-enabled device and include one or more of the
following: Online PIN, Offline PIN, Signature and/or No CVM.
Limited Release and Review

Upon successful completion of the transaction/receipt review and submission of the Authorized Reseller
Application, your POS system will be allowed to soft launch merchant(s) in a live production environment, which is
referred to as a limited release. If required, more than one but not more than five, merchants can be boarded at
this time. It is recommended that you work with your Mercury channel or sales liaison to establish suitable
merchants for a final monitoring of the POS system. Merchants will need to process through one billing cycle
before the limited release and review process is complete.
Once this process is complete, your POS is ready for full production.

2015 Mercury
Page 38 of 60
A Vantiv Company
Appendices

2015 Mercury
Page 39 of 60
A Vantiv Company
Appendix 1: XML Request/Response Examples

EMVSale
This example includes requesting a token.

Request
<TStream>
<Transaction>
<HostOrIP>127.0.0.1</HostOrIP>
<OperatorID>test</OperatorID>
<Memo>Demo POS 1.5 USEMV</Memo>
<LaneID>02</LaneID>

<SecureDevice>EMV_VX805_MERCURY</SecureDevice>
<RefNo>2001</RefNo>

<Amount>
</Amount>
<RecordNo>RecordNumberRequested</RecordNo> 
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
<TextResponse>AP</TextResponse>
</CmdResponse>
<TranResponse>
<AcctNo>************0010</AcctNo>
<RefNo>1003</RefNo>

<Amount>
</Amount>
<AcqRefData>aAb314282069480098c1234d e000</AcqRefData> 
<ProcessData>|00|410100501000</ProcessData> 
<RecordNo>SExXFNopTA/Di8VmT75Vgg32WTEtGB/SI5vd1Xlo4nIiEgUQESIQAC+Y</RecordNo> 
2015 Mercury
Page 40 of 60
A Vantiv Company
<Date>07/31/2015</Date>
<Time>10:07:22</Time>
<AID>A0000000031010</AID>
<TVR>0000008000</TVR>
<IAD>06010A03600000</IAD>
<TSI>F800</TSI>
<ARC>00</ARC>
<CVM>SIGN</CVM>
</TranResponse>
<PrintData>
<Line2>.CLERK ID: test</Line2>
<Line3>.</Line3>
<Line4>.
SALE
</Line4>
<Line5>.</Line5>
<Line6>.************0010</Line6>
<Line7>.VISA
ENTRY METHOD: CHIP</Line7>
<Line9>.</Line9>
<Line13>.</Line13>
<Line14>.AMOUNT
USD$ 1.00</Line14>
<Line15>.
==========</Line15>
<Line16>.TOTAL
USD$ 1.00</Line16>
<Line17>.</Line17>
<Line18>.
</Line18>
<Line19>.</Line19>
<Line23>.</Line23>
<Line24>.</Line24>
<Line25>.</Line25>
<Line26>.x_______________________________________</Line26>
<Line27>.
</Line27>
<Line28>.</Line28>
<Line29>.</Line29>
<Line30>.Application Label: Visa Credit</Line30>
<Line31>.AID: A0000000031010</Line31>
<Line32>.TVR: 0000008000</Line32>
<Line33>.IAD: 06010A03600000</Line33>
</PrintData>
</RStream>

2015 Mercury
Page 41 of 60
A Vantiv Company
EMVSale with Gratuity (Tip)

Request
<TStream>
<Transaction>
<HostOrIP>127.0.0.1</HostOrIP>
<RefNo>2005</RefNo>
<Amount>
<Gratuity>Prompt</Gratuity> <!device will prompt cardholder to enter a gratuity-->
</Amount>
<RecordNo>RecordNumberRequested</RecordNo>
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
</CmdResponse>
<TranResponse>
<AcctNo>************0010</AcctNo>
<RefNo>1006</RefNo>
<Amount>
<Gratuity>0.40</Gratuity> 
<Authorize>2.50</Authorize> <!Authorize amount is automatically calculated -->
</Amount>
<RecordNo>dGMuw9MB2vk5KpFzCrKMvtvZ9ZBusLV/vzlqfpwt9ygiEgUQESIQAIBY</RecordNo>
<Date>08/03/2015</Date>
<Time>11:27:01</Time>
<AID>A0000000031010</AID>
2015 Mercury
Page 42 of 60
A Vantiv Company
<TVR>0000008000</TVR>
<IAD>06010A03600000</IAD>
<TSI>F800</TSI>
<ARC>00</ARC>
<CVM>SIGN</CVM>
</TranResponse>
<PrintData>
<Line3>.</Line3>
<Line4>.
SALE
</Line4>
<Line5>.</Line5>
<Line6>.************0010</Line6>
<Line7>.VISA
<Line9>.</Line9>
<Line13>.</Line13>
<Line14>.AMOUNT
USD$ 2.10</Line14>
<Line15>.TIP
USD$ 0.40</Line15>
<Line16>.
==========</Line16>
<Line17>.TOTAL
USD$ 2.50</Line17>
<Line18>.</Line18>
<Line19>.
</Line19>
<Line20>.</Line20>
<Line24>.</Line24>
<Line25>.</Line25>
<Line26>.</Line26>
<Line27>.x_______________________________________</Line27>
<Line28>.
</Line28>
<Line29>.</Line29>
<Line30>.</Line30>
<Line32>.AID: A0000000031010</Line32>
<Line33>.TVR: 0000008000</Line33>
<Line34>.IAD: 06010A03600000</Line34>
</PrintData>
</RStream>

2015 Mercury
Page 43 of 60
A Vantiv Company
AdjustByRecordNo
This transaction uses a token and is card-not-present.

Request
<TStream>
<Transaction>
<TranType>Credit</TranType>
<TranCode>AdjustByRecordNo</TranCode>
<RefNo>1008</RefNo>
<Amount>
</Amount>
<RecordNo>dt76RZM5f2t/eOW6k2+yfgf7hTcv0BH/MVuzN05/qakiEgUQESIQADDa</RecordNo>
<Frequency>OneTime</Frequency> 
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
</CmdResponse>
<TranResponse>
<AcctNo>476173XXXXXX0010</AcctNo>
<ExpDate>XXXX</ExpDate>
<TranCode>Adjust</TranCode>
<RefNo>1008</RefNo>
<Amount>
</Amount>
<RecordNo>GcCB9KyTbLz7hLwxXZ15QtXZtTOxbSx+BzbtDZZkNiMiEgUQESIQADDf</RecordNo> 
</TranResponse>
</RStream>
2015 Mercury
Page 44 of 60
A Vantiv Company
EMVVoidSale (Reversal)
Request
<TStream>
<Transaction>
<TranCode>EMVVoidSale</TranCode>
<RefNo>1003</RefNo>
<Amount>
</Amount>
<ProcessData>|00|410100501000</ProcessData> <! request includes both AcqRefData
and ProcessData-->
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
<TextResponse>REVERSED</TextResponse>
</CmdResponse>
<TranResponse>
<AcctNo>************0010</AcctNo>
<TranCode>EMVVoidSale</TranCode>
<RefNo>2055</RefNo>
<Amount>
</Amount>
<ProcessData>|A4|410100500000</ProcessData>
<RecordNo>WnRuOfs49wVjnoYlTx9E7enGnbRl0BK0Rd0RUn5JUgYiEgUQESIQAC+h</RecordNo>
<Date>07/31/2015</Date>
<Time>10:09:14</Time>
<AID>A0000000031010</AID>
2015 Mercury
Page 45 of 60
A Vantiv Company
<TVR>0000008000</TVR>
<IAD>06010A03800000</IAD>
<TSI>A800</TSI>
<CVM>SIGN</CVM>
</TranResponse>
<PrintData>
<Line3>.</Line3>
<Line4>.
VOID SALE
</Line4>
<Line5>.</Line5>
<Line6>.************0010</Line6>
<Line7>.VISA
<Line9>.</Line9>
<Line13>.</Line13>
<Line14>.AMOUNT
USD$ 1.70</Line14>
<Line15>.
==========</Line15>
<Line16>.TOTAL
USD$ 1.70</Line16>
<Line17>.</Line17>
<Line18>.
</Line18>
<Line19>.</Line19>
<Line23>.</Line23>
<Line24>.</Line24>
<Line25>.</Line25>
<Line26>.x_______________________________________</Line26>
<Line27>.
Merchant Signature
</Line27>
<Line28>.</Line28>
<Line29>.</Line29>
<Line31>.AID: A0000000031010</Line31>
<Line32>.TVR: 0000008000</Line32>
<Line33>.IAD: 06010A03800000</Line33>
<Line34>.TSI: A800</Line34>
</PrintData>
</RStream>

2015 Mercury
Page 46 of 60
A Vantiv Company
VoidSaleByRecordNo

Request
<TStream>
<Transaction>
<TranCode>VoidSaleByRecordNo</TranCode>
<RefNo>1004</RefNo>
<Amount>
</Amount>
<RecordNo>9ap+m72prd5m0DUWjsgXES+B9DFphjs97xB63Eiq/iEiEgUQESIQAC+o</RecordNo>
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
<TextResponse>REVERSED</TextResponse>
</CmdResponse>
<TranResponse>
<TranCode>VoidSale</TranCode>
<RefNo>1004</RefNo>
<Amount>
</Amount>
<AcqRefData>K</AcqRefData>
<RecordNo>UOdEQVRrjCYstot6IYyD60+mOSN+AAJik2jh6xR8VNIiEgUQESIQAC+r</RecordNo>
</TranResponse>
</RStream>

2015 Mercury
Page 47 of 60
A Vantiv Company
EMVReturn
Request
<TStream>
<Transaction>
<TranCode>EMVReturn</TranCode>
<RefNo>2003</RefNo>
<Amount>
</Amount>
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
</CmdResponse>
<TranResponse>
<AcctNo>************0010</AcctNo>
<TranCode>EMVReturn</TranCode>
<AuthCode>726529</AuthCode>
<RefNo>1005</RefNo>
<Amount>
</Amount>
<RecordNo>UbrPuSVf8fBPvgmSP/N6LafZ4BVspaIgrgfrIrH2u0siEgUQESIQAC+y</RecordNo>
<Date>07/31/2015</Date>
<Time>10:12:22</Time>
<AID>A0000000031010</AID>
<TVR>0000008000</TVR>
<IAD>06010A03800000</IAD>
<TSI>A800</TSI>
2015 Mercury
Page 48 of 60
A Vantiv Company
<CVM>SIGN</CVM>
</TranResponse>
<PrintData>
<Line3>.</Line3>
<Line4>.
REFUND
</Line4>
<Line5>.</Line5>
<Line6>.************0010</Line6>
<Line7>.VISA
<Line9>.</Line9>
<Line12>.AUTH CODE: 726529</Line12>
<Line13>.</Line13>
<Line14>.AMOUNT
USD$ 3.04</Line14>
<Line15>.
==========</Line15>
<Line16>.TOTAL
USD$ 3.04</Line16>
<Line17>.</Line17>
<Line18>.
</Line18>
<Line19>.</Line19>
<Line23>.</Line23>
<Line24>.</Line24>
<Line25>.</Line25>
<Line26>.x_______________________________________</Line26>
<Line27>.
Merchant Signature
</Line27>
<Line28>.</Line28>
<Line29>.</Line29>
<Line31>.AID: A0000000031010</Line31>
<Line32>.TVR: 0000008000</Line32>
<Line33>.IAD: 06010A03800000</Line33>
</PrintData>
</RStream>

2015 Mercury
Page 49 of 60
A Vantiv Company
EMVVoidReturn
Request
<TStream>
<Transaction>
<TranCode>EMVVoidReturn</TranCode>
<RefNo>1005</RefNo>
<Amount>
</Amount>
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
</CmdResponse>
<TranResponse>
<AcctNo>************0010</AcctNo>
<TranCode>EMVVoidReturn</TranCode>
<AuthCode>VOIDED</AuthCode>
<RefNo>1005</RefNo>
<Amount>
</Amount>
<RecordNo>+ltYAexT+EnW/0+q2Zr4NJr+CiJ1SGUUFHkPpXPh5EkiEgUQESIQAC/A</RecordNo>
<Date>07/31/2015</Date>
<Time>10:13:34</Time>
<AID>A0000000031010</AID>
<TVR>0000008000</TVR>
<IAD>06010A03800000</IAD>
<TSI>A800</TSI>
2015 Mercury
Page 50 of 60
A Vantiv Company
<CVM>SIGN</CVM>
</TranResponse>
<PrintData>
<Line3>.</Line3>
<Line4>.
VOID REFUND
</Line4>
<Line5>.</Line5>
<Line6>.************0010</Line6>
<Line7>.VISA
<Line9>.</Line9>
<Line12>.AUTH CODE: VOIDED</Line12>
<Line13>.</Line13>
<Line14>.AMOUNT
USD$ 3.05</Line14>
<Line15>.
==========</Line15>
<Line16>.TOTAL
USD$ 3.05</Line16>
<Line17>.</Line17>
<Line18>.
</Line18>
<Line19>.</Line19>
<Line23>.</Line23>
<Line24>.</Line24>
<Line25>.</Line25>
<Line26>.x_______________________________________</Line26>
<Line27>.
Merchant Signature
</Line27>
<Line28>.</Line28>
<Line29>.</Line29>
<Line31>.AID: A0000000031010</Line31>
<Line32>.TVR: 0000008000</Line32>
<Line33>.IAD: 06010A03800000</Line33>
</PrintData>
</RStream>

2015 Mercury
Page 51 of 60
A Vantiv Company
VoidReturnByRecordNo

Request
<TStream>
<Transaction>
<TranCode>VoidReturnByRecordNo</TranCode>
<RefNo>1006</RefNo>
<Amount>
</Amount>
<RecordNo>cgA6E9xDudKDjjqpaf4ukajlgWYVr7i0XJMduJpeGvYiEgUQESIQAC/Y</RecordNo>
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
</CmdResponse>
<TranResponse>
<TranCode>VoidReturn</TranCode>
<AuthCode>VOIDED</AuthCode>
<RefNo>1006</RefNo>
<Amount>
</Amount>
<AcqRefData>K</AcqRefData>
<RecordNo>xRTiAAsGs1FAYPb9sgviFooXHsJoohmFHA8/SK5VdfwiEgUQESIQAC/c</RecordNo>
</TranResponse>
</RStream>
2015 Mercury
Page 52 of 60
A Vantiv Company
EMVVoiceAuth
Request
<TStream>
<Transaction>
<TranCode>EMVVoiceAuth</TranCode>
<RefNo>2005</RefNo>
<AuthCode>123456</AuthCode> <!the authorization code obtained over the phone-->
<Amount>
</Amount>
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
</CmdResponse>
<TranResponse>
<AcctNo>************0010</AcctNo>
<TranCode>EMVVoiceAuth</TranCode>
<RefNo>1007</RefNo>
<Amount>
</Amount>
<RecordNo>qubp/LoBoHZe2A6qwoaM5KOKc0b6K1Ix1xGaDiO2j2siEgUQESIQAC/s</RecordNo>
<Date>07/31/2015</Date>
<Time>10:17:40</Time>
<AID>A0000000031010</AID>
<TVR>000000C000</TVR>
<IAD>06010A03800000</IAD>
2015 Mercury
Page 53 of 60
A Vantiv Company
<TSI>A800</TSI>
<CVM>SIGN</CVM>
</TranResponse>
<PrintData>
<Line3>.</Line3>
<Line4>.
POST AUTH
</Line4>
<Line5>.</Line5>
<Line6>.************0010</Line6>
<Line7>.VISA
<Line9>.</Line9>
<Line12>.AUTH CODE: 123456</Line12>
<Line13>.</Line13>
<Line14>.AMOUNT
USD$ 5.25</Line14>
<Line15>.
==========</Line15>
<Line16>.TOTAL
USD$ 5.25</Line16>
<Line17>.</Line17>
<Line18>.
</Line18>
<Line19>.</Line19>
<Line23>.</Line23>
<Line24>.</Line24>
<Line25>.</Line25>
<Line26>.x_______________________________________</Line26>
<Line27>.
</Line27>
<Line28>.</Line28>
<Line29>.</Line29>
<Line31>.AID: A0000000031010</Line31>
<Line32>.TVR: 000000C000</Line32>
<Line33>.IAD: 06010A03800000</Line33>
</PrintData>
</RStream>

2015 Mercury
Page 54 of 60
A Vantiv Company
EMVZeroAuth
Request
<TStream>
<Transaction>
<TranCode>EMVZeroAuth</TranCode>
<RefNo>2007</RefNo>
<Amount>

</Amount>
</Transaction>
</TStream>
Response
<RStream>
<CmdResponse>
</CmdResponse>
<TranResponse>
<AcctNo>************0010</AcctNo>
<TranCode>EMVZeroAuth</TranCode>
<RefNo>2007</RefNo>
<Amount>
<Authorize>0.00</Authorize> 
</Amount>
<RecordNo>6UrbpaDlbxWiiXwqzc7I/ThNG+VQPzVLvWoKMWLtuYciEgUQESIQADAH</RecordNo>
<Date>07/31/2015</Date>
<Time>10:19:34</Time>
<AID>A0000000031010</AID>
<TVR>000000C000</TVR>
<IAD>06010A03600000</IAD>
2015 Mercury
Page 55 of 60
A Vantiv Company
<TSI>F800</TSI>
<ARC>00</ARC>
<CVM>SIGN</CVM>
</TranResponse>
<PrintData>
<Line3>.</Line3>
<Line4>.
VERIFY CARD
</Line4>
<Line5>.</Line5>
<Line6>.************0010</Line6>
<Line7>.VISA
<Line9>.</Line9>
<Line13>.</Line13>
<Line14>.AMOUNT
USD$ 0.00</Line14>
<Line15>.
==========</Line15>
<Line16>.TOTAL
USD$ 0.00</Line16>
<Line17>.</Line17>
<Line18>.
</Line18>
<Line19>.</Line19>
<Line23>.</Line23>
<Line24>.</Line24>
<Line25>.</Line25>
<Line26>.x_______________________________________</Line26>
<Line27>.
</Line27>
<Line28>.</Line28>
<Line29>.</Line29>
<Line31>.AID: A0000000031010</Line31>
<Line32>.TVR: 000000C000</Line32>
<Line33>.IAD: 06010A03600000</Line33>
</PrintData>
</RStream>

2015 Mercury
Page 56 of 60
A Vantiv Company
Appendix 2: NETePay and dsiEMVUS Error Messages

In-Store NETePay Errors (TCP/IP)
Code Number
002000
002001
002002
002003
002004
002006
002008
002009
002010
002011
100201
100202
100203
100204
100205
100206
100207
100208
100209
Code Text
Password Verified
Queue Full
Password Failed Disconnecting
System Going Offline
Disconnecting Socket
Refused Max Connections
Duplicate Serial Number Detected
Password Failed (Client / Server)
Password failed (Challenge / Response)
Internal Server Error Call Provider
Invalid Transaction Type
Invalid Operator ID
Invalid Memo
Invalid Account Number
Invalid Expiration Date
Invalid Authorization Code
Invalid Reference Number
Invalid Authorization Amount
Invalid Cash Back Amount
dsiEMVUS Specific (TCP/IP)
Code Number
100210
100211
100212
100213
100214
100215
100216
100217
100218
100219
100220
100221
100222
100223
100224
100225
100226
100227
100228
Code Text
Invalid Gratuity Amount
Invalid Purchase Amount
Invalid Magnetic Stripe Data
Invalid PIN Block Data
Invalid Derived Key Data
Invalid State Code
Invalid Date of Birth
Invalid Check Type
Invalid Routing Number
Invalid TranCode
Invalid Merchant ID
Invalid TStream Type
Invalid Batch Number
Invalid Batch Item Count
Invalid MICR Input Type
Invalid Drivers License
Invalid Sequence Number
Invalid Pass Data
Invalid Card Type
Code Text
Failed to start Event Thread.
XML Parse Error
All Connections Failed
Server Login Failed
Initialize Failed
Response Length Error (Too Short)
Unable to Parse Response from
Global (Indistinguishable)
String Error
Weak Encryption Request Not
Supported
Clear Text Request Not Supported
Error Occurred While Decrypting
Request
Unrecognized Request Format
Invalid Check Digit
Merchant ID Missing
Code Number
001001
001003
001004
001006
001007
001011
003002
Code Text
General Failure
Invalid Command Format
Insufficient Fields
API Not Initialized
Timeout on Response
Empty Command String
In Process with server
Code Number
003017
003050
003051
003052
003053
004001
004002
003003
003004
Socket Error sending request.

Socket already open or in use
004003
004004
003005
003006
Socket Creation Failed

Socket Connection Failed
004005
004011
003007
003008
003009
Connection Lost
TCP/IP Failed to Initialize
Control failed to find branded serial
(password lookup failed)
Time Out waiting for server response
Connect Cancelled
004010
004017
004018
128 bit CryptoAPI failed.
009999
003010
003011
003012
003014
Threaded Auth Started Expect Response

Event (it is possible the event could fire
before the function returns.)

2015 Mercury
004019
004020
TStream Type Missing

Could Not Encrypt Response- Call
Provider
Unknown Error
Page 57 of 60
A Vantiv Company
Common Errors
I received Failed to start TCP/IP server(9000)
Please uninstall the in-Store NETePay, ask your Integration Analyst to update your stage file, and then reinstall.
That should correct your problem.
I received Failed to access ComPort
Please uninstall the in-Store NETePay, ask your Integration Analyst update your stage file and select only IP
Processing, and then reinstall. That should correct your problem.

2015 Mercury
Page 58 of 60
A Vantiv Company
Appendix 3: Additional Resources

Mercury Online
Developer Network
http://developer.mercurypay.com
Mercury GitHub
https://github.com/MercuryPay/dsiEMVX.CSharp
Mercury EMV YouTube videos
https://www.youtube.com/playlist?list=PLpj0a-Besn6_1jJzr7ifPKqislVNW7RJr
Datacap Systems
dsiEMVUS EMV Programming
Interface Specification
http://datacapsystems.com/emv-transition
in-store NETePay for Mercury
http://www.datacapepay.com/netepay5-mercuryoos.htm
dsiEMVX control
Go to: http://www.datacapepay.com/software/emvus/ and click dsiEMVUS100-With-EMVUS-test-App-Install20150807-W8.exe. Both the dsiEMVX

control and the EMV US Client Test tool are contained in the download.
Datacap Reseller Application*
http://datacapsystems.com/reseller-application
* If clicking this link does not work, please copy it to your browser
General EMV Information

EMVCo
http://www.emvco.com/
EMVLab
http://www.emvlab.org/emvtags/all/
Official US EMV
Specification
Wikipedia
http://www.emvco.com/specifications.aspx?id=2
23
https://en.wikipedia.org/wiki/EMV#cite_notechipAndPin2-6

2015 Mercury
The official source for information

EMV specifications
List of all EMV tags and their
definitions
This consists of four volumes, which
can be downloaded from here
Always a great source to start with
Page 59 of 60
A Vantiv Company
Appendix 4: Glossary
AID
ARC
ARPC
ARQC
CED
CVM
EMV
Fallback
IAD
ICC
MSD
MSR
TSI
TVR
Application Identifier
Application Response Code
Authorization Response Cryptogram
Authorization Request Cryptogram
Card Entry Device
Cardholder Verification Method
Europay MasterCard Visa
alternative ways for entering card information if a chip read fails (swipe or manual entry)
Issuer Application Data
Integrated Circuit Chip
Magstripe
Magstripe reader
Transaction Status Indicator
Terminal Verification Results

2015 Mercury
Page 60 of 60

Verifone Vx805 DsiEMVUS Platform Integration Guide Supplement

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Verifone Vx805 DsiEMVUS Platform Integration Guide Supplement

Hochgeladen von

Copyright:

Verfügbare Formate

A Vantiv Company

Mercury Platform Integration Guide

dsiEMVUS Mercury Platform Integration Guide Supplement

dsiEMVUS Mercury Platform Integration Guide Supplement

Document Version History

dsiEMVUS Platform Integration Guide Supplement 08272015

dsiEMVUS Mercury Platform Integration Guide Supplement

dsiEMVUS Platform Integration Guide Supplement 08272015

dsiEMVUS Mercury Platform Integration Guide Supplement

Figure 1. dsiEMVUS Data Flow.......................................................................................................................................8

dsiEMVUS Platform Integration Guide Supplement 08272015

dsiEMVUS Mercury Platform Integration Guide Supplement

General Integration Information

All Mercury EMV integrations must use Mercurys end-to-end encryption.

The Integration Process

dsiEMVUS Platform Integration Guide Supplement 08272015

dsiEMVUS Mercury Platform Integration Guide Supplement

EMV Data Flow and Terminology

dsiEMVUS Mercury Platform Integration Guide Supplement

POS initiates an EMV transaction to the dsiEMVUS

Authorization request is sent from Mercury to

Figure 1. dsiEMVUS Data Flow

A Phased Approach for U.S. EMV Rollout

dsiEMVUS Platform Integration Guide Supplement 08272015

dsiEMVUS Mercury Platform Integration Guide Supplement

dsiEMVUS Platform Integration Guide Supplement 08272015

dsiEMVUS Mercury Platform Integration Guide Supplement

Install and Configure the Datacap Test Components

Download and install the CERT NETePay.

Go to: http://www.datacapepay.com/netepay5-mercuryoos.htm, then click on Get next to NETePay for

Go to http://www.datacapepay.com/software/dev-netepay/mercury/version5dev/USEMV/ and click

Setup the CERT NETePay.

Redirect processing traffic to the CERT NETePay.

dsiEMVUS Mercury Platform Integration Guide Supplement

Download and install the dsiEMVX control.

Setup the VX805 for EMV

Connect the VX805 device to your computer.

Double-click DSIMercuryIP_Dial.exe to run the NETePay software.

Merchant ID: 755847002.

Confirm the IP/Hostname is 127.0.0.1.

Enable EMV on the VX805:

dsiEMVUS Client Test Tool

The tool opens. Complete the following information:

VX805 Mercury (E2E)

dsiEMVUS Platform Integration Guide Supplement 08272015

dsiEMVUS Mercury Platform Integration Guide Supplement

Mercury Supported EMV Commands, Functionality and Trancodes

Used to confirm the NETePay Version

dsiEMVUS Platform Integration Guide Supplement 08272015

dsiEMVUS Mercury Platform Integration Guide Supplement

Changes to the Consumer Experience

dsiEMVUS Mercury Platform Integration Guide Supplement

1. Swipe a chip card

a. Swipe B2 test card #1

b. Insert card to complete

c. Leave card in place after

2. Insert a magstripe card

3. Remove card before

Insert B2 chip card #10, then

Insert B2 chip card #12

PIN pad Results

PIN pad prompts, APPL NOT

PIN pad displays TRANSACTION NOT

Frequently Asked Questions