image


Host XML Specification

Release 2.03.01

Last Update: March 19, 2017 Creation Date: March 16, 2015


© 2017 JetPay LLC. All rights reserved.

  1. Communicating with JetPay 7

    1. JetPay URLs 7

    2. Methods of Securely Posting an XML file 8

  2. JetPay Test System 9

    1. Connecting to the JetPay Test System 9

    2. Testing Terminal ID's 9

  3. Element Overview 10

    1. JetPay Transaction Request Elements and Definitions 10

    2. JetPay Transaction Response Elements and Definitions 13

  4. General Examples 15

    1. AUTHONLY Transaction 15

    2. PARTIAL AUTHORIZATION Transaction 16

    3. CAPT Transaction 19

    4. SALE Transaction 20

    5. FORCE Transaction 21

    6. VOID Transaction 22

    7. CREDIT (Refund) Transaction 23

    8. Cash Disbursement Transaction 25

    9. ENQ Transaction 26

    10. PING Transaction 29

    11. Error Response 29

    12. SEEK "PIN Debit" Transaction 30

    13. Additional Examples 31

    14. Address Verification (AVS) 31

    15. Card Validation (CVV2) 33

    16. Cardholder Authentication (CAVV) 34

    17. Recurring & Bill Payment Examples 36

  5. Application-Specific Examples 39

    1. Explicitly Invoking Alternatives Using Routing Code 39

    2. Retail - Restaurant Industry Type 39

    3. Corporate/Business/Purchase Card Processing (Level 2) 40

  6. Credit Card Examples 43

    1. Magnetic Stripe POS Retail Sale Transaction 43

    2. Magnetic Stripe Transaction for Restaurant 44

    3. Manually Entered POS Transaction 45

    4. Contactless Track POS Transaction 47

  7. EMV Chip POS Transaction 49

    1. Datagram Elements for EMV Transactions 49

    2. EMV Chip POS Transaction Example 51

    3. Chip and PIN Transaction Example 51

    4. EMV REJECT Transaction Example 52

  8. Visa Readylink (PrePaid Cards) 54

    1. BALANCE (Inquiry) Transaction 54

    2. LOADPURSE Transaction 55

    3. UNLOADPURSE Transaction – Not Supported at This Time 56

    4. VOID Transaction - Not Supported at This Time 57

  9. Debit Card and EBT Card 59

    1. Debit POS Sale Transaction 59

    2. EBT POS Sale Transaction - Not Supported at This Time 59

    3. Pin Debit 60

    4. PIN Debit Void Transaction 60

  10. eCommerce Industry-Specific 61

    1. MOTO Industry-Specific 62

  11. ACH processing 65

    1. ACH Request Messages 65

    2. Request Transaction Element Definitions 65

    3. ACH Response Message 66

    4. ACH Response Transaction Element Definitions 66

    5. CHECK Transaction (ACH) 67

    6. REVERSAL Transaction (ACH) 67

    7. VOIDACH Transaction (ACH) 68

  12. Dynamic Descriptors 70

  13. Memo Post Transactions 71

  14. Batch Processing 72

    1. Batch Status 72

    2. Batch Release 72

    3. Batch Clear 73

  15. Data Security Features 74

    1. DUKPT Encrypted Credit Card Data 74

    2. IDTech Transaction Example 74

    3. Magtek Transaction Example 75

  16. CryptoPAN Secure Credit Card Number Storage 77

    1. Sending Card Numbers Securely, Using CryptoPAN 77

    2. CryptoPAN Encoding 78

    3. Sample CryptoPAN Program 78

  17. JetPay Account Safe Tokens 80

    1. Tokens for Credit Cards 80

    2. Expiration Dates 81

    3. Tokens for ACH 81

  18. Passwords 83

  19. Verification and Validation Features 84

    1. Address Verification Services 84

    2. Card Validation Using CVV2, CVC2, and CID 84

    3. JetPay CVV2 Result Codes 85

  20. Simulating Approved and Declined Transactions 86

    1. Simulating Approved Transactions 86

    2. Simulating 'DECLINED' Transactions 86

    3. List of Amount and Action codes 87

  21. Other Responses 88

    1. Simulating AVS and CVV Responses 88

    2. Postal Code Values That Affect the AVS Result 89

    3. Simulating CVV2/CVC2/CID Responses 90

    4. CVV2 Values That Affect the CVV2 Result 90

  22. Result Codes 91

    1. AVS Result Codes 91

    2. Visa AVS Result Codes 92

    3. Discover AVS Responses 92

    4. MasterCard AVS Result Codes 93

    5. American Express AVS Responses 93

    6. CVV2 Result Codes 94

    7. CAVV Result Codes 95

  23. Action Codes 96

    1. Visa Action Result Codes 96

    2. MasterCard Action Result Codes 97

    3. American Express Action Codes 97

    4. Discover Action Codes 98

    5. JetPay Specific Action Codes 99

  24. Appendix: The JetPay Authorization XML Schema – Version 2.2 100

Introduction


The JetPay XML interface provides a flexible and easy-to-use interface for processing transactions with the JetPay host. Through one interface a merchant can perform credit card, debit card, EMV and ACH transactions across multiple industry-types.


This document is for merchants or third-party developers who will be generating their own XML for transmission to JetPay. This document does not cover the Windows DLL, Java, or Batch File interfaces. This document does assume that the reader is familiar with XML generation and parsing, using the https protocol, and the rudiments of credit card and/or ACH processing.


The JetPay system is a host capture system. Transactions run as SALE, FORCE, or CAPT(ure) will be automatically delivered for settlement at 12:00 midnight CST. The exception to this is when Batch Processing is used. This is discussed in Section 15.


You will be assigned a terminal id that you will use for the certification process, as well as a Developer ID that you will use for testing and in production. You will also be required to supply an Application name with version number and a Device name with version number for each transaction.


Please verify that each transaction is sent with the all of the necessary data elements required by the card issuer. Once your code is released in production, transactions may not qualify for the best interchange rates or chargeback protection. This will result in higher transactions costs and fees. The test simulator that you will be using during the certification process DOES NOT validate qualifications. Even if you receive an approval response, it does not guarantee that the transactions will qualify at the best rates.


Response codes should be reviewed to verify that your system interprets and handles the response codes correctly. There are specific transactions amounts that can be used to test all action, AVS, and CVV2 response codes.


Note:


All XML examples are purely EXAMPLES ONLY! Please DO NOT copy examples for coding purposes.




Disclaimer: The information in this guide is current as of the date of printing. However, card acceptance and processing procedures are subject to change. JetPay is not responsible for your use of the information contained in this guide, including errors, omissions, inaccuracy or non-timeliness of any kind. JetPay will publish updates as needed.


Any questions or problems with this document should be sent to: devgroupmanager@jetpay.com.

Change Control

Date

Version

Description

05/08/2015

2.01.02

Sec 7 – Dynamic Descriptors: Correction to last sentence.

05/12/2015

2.01.02

Sec 2.2 – Partial Authorization Transaction: Added comment in NOTES for Balance Returned and updated the XML Example 1 with <BalanceAmount> in the response message.

06/01/2015

2.01.02

Sec 9.3 – Batch Clear: Corrected XML Response example.

06/23/2015

2.01.02

Sec 2.9 – Cash Disbursement Transaction: Corrected XML Request example.

2.01.02

Sec 1.1 – JetPay Transaction Request Elements and Definitions -

<TransactionType>: Added SEEK as a transaction.

2.01.02

Sec 2.14 – SEEK "PIN Debit" Transction: Added SEEK transaction descript and XML example.

7/26/2015

2.02.00

Sec 1.1 – JetPay Transaction Request Elements and Definitions -

<TransactionType>: Add CashbackAmount.

7/26/2015

2.02.00

Sec 3.2.2.1 – Pin Debit: Correct request and add CashbackAmount.

08/05/2015

2.02.00

Sec 3.2.1.7 – EMV Chip POS Transaction Example: Corrected the Total Amount in the example.

09/03/2015

2.02.00

Sec 1.2 – JetPay Transaction Response Elements and Definitions: Updated the definition for <ResponseText>.

09/15/2015

2.02.00

Sec 2.6 – VOID Transaction: Changed the format of the record to require

<UniqueID> to be sent in the request message.

09/15/2015

2.02.00

Sec 3.2.2.4 - PIN Debit Void Transaction: Added new functionality to be able to process a VOID using a PIN Debit card.

11/20/2015

2.02.00

Removed the following Industry specific data as it is not fully supported at this time. Will be added in the future: HOTEL, PARKING, AIRLINE, TRANSPORT, QUASICASH, PURCHASE/COMMMERCIAL CARD.

01/06/2016

2.02.00

Global: Changed <JetPay Version='2.0'> to <JetPay Version='2.2'> and

<JetPayResponse Version="2.0> to <JetPayResponse Version="2.2">.

01/06/2016

2.02.00

Sec 1.2 - JetPay Transaction Response Elements and Definitions, and Global: Added <TimeStamp> in all Reference's to: <JetPayResponse Version="2.2"> XML examples.

02/11/2016

2.02.00

Some minor formatting throughout the specifications manual.

03/14/2016

2.02.00

Remove reference to Pinless Debit.

08/18/2016

2.02.00

Added additional response code for MasterCard - 088

08/18/2016

2.02.00

Sec 8 - Added Readylink PrePaid Cards

02/08/2017

2.03.00

Sec 5.3 – Add commercial card/Level 2 section

02/08/2017

2.03.00

Added response: </CardProgram> for Level2/Corporate cards to all responses.

02/08/2017

2.03.00

Remove REVERSEAUTH. VOID replaces the functionality.

03/19/2017

2.03.01

Transaction Request Elements and Definitions: Update Order <TicketNumber>

03/19/2017

2.03.01

Transaction Request Elements and Definitions: Update Order <OrderNumber>

03/19/2017

2.03.01

Sec 5.3 update purchase card examples

1. Communicating with JetPay

The XML is sent to JetPay inside of an HTTPS POST message. Each post can contain only one message. The XML itself must contain only valid UTF-8 characters. Transactions that use the non-ASCII portions of character sets such as ISO-8859-1, ISO-8859-15 or Windows-1252 will be rejected. For best results, it is strongly recommended that merchants restrict themselves to using only the US-ASCII character set.


As part of an industry wide adoption of Secure Hash Algorithm 2 (SHA-2) as a stronger, more secure way to exchange sensitive data using secure connections, JetPay has migrated to SHA-2 certificates. Mozilla, Google, Apple and all global Certificate Authorities have agreed that as of December 31, 2015, no new SHA-1 certificates will be issued. In 2017 a number of entities, including Microsoft, will be treating otherwise valid SHA-1 certificates as untrusted. Microsoft has announced that SHA1-based certificates will be blocked in their web browsers starting February 14, 2017.

JetPay's Secure Sockets Layer (SSL) and Transport Layer Security (TLS) gateways support the SHA-2 certificate standard. Ensuring continued protection for cardholder information. Point of Sale (POS) devices, applications, servers, and firewalls must be SHA-2 compatible by the SHA-1 certificate expiration date to prevent processing impacts.


    1. . JetPay URLs


      TLS Version

      Testing URL/Port

      Production URL Primary/Port

      Production URL Secondary/Port

      TLS 1.2

      TEST1.JETPAY.COM:443

      GATEWAY20.JETPAY.COM:443

      GATEWAY17.JETPAY.COM:443

      The production gateway should not be used for test purposes (unless a test of live transaction data is deliberately planned with intent to settle that transaction data).


      Stress testing is not permitted over the Internet connections without the specific consent of JetPay LLC. Any entity discovered to be stress testing over the Internet without consent of JetPay LLC will be categorized as a Denial of Service attacker and be prohibited from using the JetPay system without notice.


    2. . Methods of Securely Posting an XML file


If you are using Java, you can download the Java Secure Socket Extension package available at http://java.sun.com.


If you are using Microsoft technologies, you can use the XMLHTTPRequest object of msxml.dll. Please note that this solution is built upon wininet.dll, which is not scalable. Another solution is to use the rope.dll that is included with the SOAP toolkit. This is a newly emerging technology that at the time of this writing was not able to successfully post data without code changes (the source is freely available) but may be useful in the future.


For Windows 2000 and Windows XP platforms, the Microsoft WinHTTP Service SDK is useful for posting secure XML documents. This solution is more scalable. A simple snip of Visual Basic code illustrates the use of the Microsoft objects available in WinHTTP:


Dim strRequest As String Dim strURL As String

Dim objXml As DOMDocument

Dim objHttp As WinHttp.WinHttpRequest

strRequest = _ '<JetPay Version='2.2'>' & _

'<TransactionType>PING</TransactionType>' & _ '<TerminalID>ASSIGNEDTID</TerminalID>' & _ '<TransactionID>010327153017T10017</TransactionID>' & _

'<Application Version='4.2'>VirtPOS</Application>' & _ '<Device Version='1.0'>Fake POS</Device>' & _ '<Library Version='1.5'>VirtPOS SDK</Library>' & _ '<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>' & _ '</JetPay>'

strURL = https://test1.jetpay.com/jetpay

Set objHttp = New WinHttp.WinHttpRequest objHttp.SetTimeouts 0, 60000, 60000, 60000 objHttp.Open 'POST', strURL, False objHttp.Send strRequest Set objXml = New DOMDocument objXml.loadXML objHttp.ResponseText

Dim node As IXMLDOMNode

For Each node In objXml.selectSingleNode('JetPayResponse').childNodes Debug.Print txtOut.Text & node.nodeName & ': ' & node.Text & vbNewLine Next


There are also third party products available for this purpose. IP*Works is available at: http://www.dev-soft.com


2. JetPay Test System

The JetPay Test System allows developers to simulate the submission and subsequent approval (or denial) of financial transactions. Merchants can system-test their financial transaction programs, building and submitting their JetPay transactions in a safe environment. The Test System operates in a non-production environment; any transaction submitted to the Test System does not actually enter the world of live financial transactions. Using the Test System, merchants can debug their custom programs without worrying about bogus test transactions being processed as live transactions.

The Test System uses virtually the same JetPay software as the production environment. Use the Test System with the knowledge that it will operate in the same manner as the production system. The minor differences between the Test System and the production system are:

The back end simulators.

Enhancements being introduced for test purposes prior to deployment in production.

The test database, a separate database from the production database.

The Test System is disconnected from the financial institutions. Instead of communicating with financial institutions, the JetPay Test System accesses a suite of back-end simulators that send artificial responses back to JetPay, thereby simulating the connections with Visa, MasterCard, American Express, and numerous other financial organizations. Few organizations provide any system for simulating real-time responses for financial transactions, but the JetPay Test System does.

Due to ongoing development, the newest JetPay features will always appear on the Test System before their deployment into production. Some merchants might require the deployment of brand new JetPay features. The Test System serves as the test bed for the newest features. By deploying new features on the Test System, this also allows JetPay to rigorously test the backward compatibility of those enhancements prior to deployment.


The Test System has features that allow merchants to test both approved transactions and declined transactions. Methods for configuring such tests are explained in this document.


This document lists the various features of the Test System. This document assumes that the reader is capable of posting an XML transaction to JetPay. This document concentrates on relating the testing methodology available to developers through the Test System.

    1. . Connecting to the JetPay Test System

      EMV development, special arrangements must be made with JetPay in order to deliver a test environment capable of enabling terminal certification. Please contact JetPay concerning your EMV-compliant POS terminal development. JetPay will arrange to set up a test URL capable of satisfying your testing needs.

      XML development, testing XML-generating software, or for testing applications linked with the JetCom DLL, the Internet connection to the JetPay Test System refer to Section 1.1


      The JetPay Test System's URLs should be used for all testing. The production gateway should never be used for test purposes (unless a test of live transaction data is deliberately planned with intent to settle that transaction data).


      JetPay prohibits stress testing over it Internet connections without explicit prior consent. Any entity discovered to be stress testing over the Internet without consent of JetPay will be categorized as a Denial of Service operator and barred from using JetPay's URLs without notice.


    2. . Testing Terminal ID's

The JetPay Test System recognizes all the terminal IDs that are already boarded on the production system plus the list of assigned terminal IDs. Merchants should use their assigned terminal IDs on the Test System.


To have a TEST Terminal ID assigned to you please send an email to: devgroupmanager@jetpay.com.


3. Element Overview

The following table provides the request elements, definitions and whether the field is required or optional for a JetPay transaction request message.


    1. . JetPay Transaction Request Elements and Definitions

      <ACH Type>

      <AccountNumber>

      <AccountNumber Tokenize>

      <ABA>

      <CheckNumber>

      Required

      Attribute is CHECKING, SAVINGS or BUSINESSCK. Attribute is Standard Entry Class code, three characters.

      AccountNumber is the cardholder's bank account number. AccountNumber Tokenize is used for ACH transactions.

      ABA is the nine-digit routing identifier for the target bank account. CheckNumber is the check number for the banking transaction.

      <AccountType>

      Optional

      Attribute may have a value of 'Checking', 'Savings', or 'BusinessCk' (defaulting to 'Checking').

      <Application Version>

      Required

      The software name and version number generating this JetPay XML transaction.

      <Approval>

      Required

      Required for FORCE transactions. Supply an authorization code from an earlier AUTHONLY response.

      <BaseAmount>

      Optional

      The amount of the customer's restaurant check, without tip, taxes, or other service charges.

      <BatchID>

      Optional

      Enable Merchant-Initiated Terminal Reconciliation feature. The BatchID allows a merchant to tag a transaction for manual settlement. Any transaction having a BatchID does not settle until the merchant

      manually triggers the settlement of transactions having matching BatchIDs.

      <Billing>

      <Address>

      <City>

      <StateProv>

      <PostalCode>

      <Country>

      <Phone>

      <Email>

      Optional - Recommended


      The billing address information and billing postal code information enable AVS processing.

      <Card Encryption='DUKPT-TDES-DATA-HEX' Key>

      Required


      Used when sending an IDTech manually entered credit card transaction.

      <CardExpMonth>

      Required

      Two-digit card expiration month.

      <CardExpYear>

      Required


      Two-digit card expiration year.

      <CardName>

      Optional for Credit– Required for ACH

      The customer name that is printed on the front of the card. CardName is required for ACH transactions.


      <CardNum CardPresent>

      Required

      The credit card number or PAN (Personal Account Number) submitted for a transaction. The PAN is thirteen to nineteen digits long, depending on the type of the credit card. 'CardPresent=' is required. Value are:

      True

      False

      <CardNum Encryption='RSA-BASE64' Key='PUBLICKEY'>

      Required


      Used when sending a CryptoPAN secured card number.

      <CardNum Tokenize>

      Required

      An alternative way to request a Token for a credit card.

      <CardStartMonth>

      Optional

      Two-digit start-up month.

      <CardStartYear>

      Optional


      Optional – Two-digit start-up year.

      <CashbackAmount>

      Optional


      Used for Pin Debit and EBT Transactions


      <CVV2>

      Optional - Recommended

      The Card Verification Value printed on the back of a credit card. The CVV2 number is a three-or four-digit value. These CVV2 digits provide additional security for a transaction, assuring the physical presence of a credit card. Please note the terminology differences between credit card companies: Visa uses CVV2 meaning Card Verification Value 2

      MasterCard uses CVC2 meaning 'Card Validation Code 2'

      American Express CID meaning 'Card IDentifier code'

      <Debit Type>

      Required

      Root element, with the following attribute and elements.

      Type – A declaration of the type of Debit Transaction. Valid types include:

      DIRECT

      NONE

      <DeveloperID>

      Required

      An ID assigned by JetPay to a software developer or development company responsible for writing either the Library or Application, whichever is directly responsible for generating the XML and undergoing certification with JetPay.

      <Device Version>

      Required

      The device name and version number of the platform generating the request transaction.



      <DispenseMode>

      Required

      DispenseMode is used when submitting a cash disbursement transaction. The cash disbursement transaction is limited to banks and financial institutions that fall under merchant category code (MCC) 6010 only. Possible values are:

      Manual

      Automated

      None

      <EMVKernel>

      Required

      As certified by EMVCo.

      <FeeAmount>

      Optional

      The surcharge applied to a transaction. The surcharge value within this element is assumed to be already included in total amount. Digits only: no decimal point, no dollar sign, no plus/minus sign.

      <Gateway>

      Required

      The originator of the transaction, that is, the gateway accepting the initial transaction.


      <IndustryInfo Type>

      Required

      A declaration of the general marketing category served by the merchant. Different merchants fall into different categories:

      ECOMMERCE – web-based sales through Internet merchants

      FINANCIAL

      MOTO – for merchants selling through mail-order or phone-order

      RESTAURANT

      RETAIL – for merchants with brick-and-mortar storefronts

      <Issue>

      Optional

      Two-digit value (European credit cards).

      <JetPay Version='2.2'>

      Required

      Root element, enclosing the following transaction elements.

      <Library Version>

      Optional

      The name and release number of a library or DLL used to process this transaction.

      <Memo Type>

      <AuthAuthority>

      <Description>

      Optional

      AuthAuthority – The organization tha was responsible for the original authorization of the transaction (no more than 24 bytes).

      Description – An optional description associated with the transaction (no more than 80 bytes). **Prior discussion with JetPay will be required before sending <Memo Type> data.**

      <OrderNumber>

      Optional

      Required for dynamic descriptor


      A string referencing an order or used for dynamic descriptor


      <Origin>

      Required

      The manner in which this transaction was communicated to the merchant. Possible values are:

      INTERNET – eCommerce merchants

      POS – retail merchants with magnetic card readers

      RECURRING – eCommerce and MOTO merchants

      PHONE ORDER – MOTO merchants

      MAIL ORDER – MOTO merchants

      <Password>

      Optional

      The password (coordinated with JetPay LLC) is used to verify a submitted XML transaction originates from a specific merchant.

      <PhoneII>

      Optional

      Only used for PHONE ORDER transactions.

      <PhoneANI>

      Optional

      Only used for PHONE ORDER transactions.

      <ReadersFailed>

      Required when processing fallback

      EMV: This required if doing fallback processing due to a reader failure.


      <ReaderUsed>

      Required

      Description of the specific medium used for collecting the terminal-based data. Types of data-collection media include:

      KEYPAD

      CHIP

      MAGNETIC STRIPE

      CONTACTLESS MS

      CONTACTLESS CHIP

      MOBILE READER

      A dual default applies when the JetPay server detects manually entered data is detected; the default is KEYPAD. When track data is detected; the default is MAGNETIC STRIPE. For a contactless magnetic stripe reader or a chip reader to be designated, the reader must be declared explicitly.

      <RoutingCode>

      Optional

      A mechanism for declaring alternate transaction routes. The value of the RoutingCode must be pre- arranged.

      <ServerID>

      Optional

      Restaurant Only: The ID of the wait staff employee filling the customer's order.

      <Shipping>

      <CustomerPO>

      <ShippingMethod>

      <Name>

      <Address>

      <City>

      <StateProv>

      <PostalCode>

      <Country>

      <Phone>

      <Email>

      Optional


      When a product or service is shipped to a customer, this category enables collection of the shipping data. This is best applied to cardholder-not-present transactions. eCommerce merchants and MOTO merchants always submit cardholder-not-present transactions; they may submit shipping information to improve their transaction qualification if permitted. Optional

      The manner of delivering a purchase to the recipient. One of five shipping methods may be specified:

      SAME DAY – courier delivery

      OVERNIGHT – next day delivery

      PRIORITY – two to three days shipping time

      GROUND – four or more days shipping time

      ELECTRONIC – delivery of purchase by electronic means

      <TableNumber>

      For Restaurant transactions, the ID of a customer's dining station.


      image


      Optional


      <TaxAmount>

      Optional

      Tax applied to a transaction. The tax value within this element is assumed to be already included in total amount. Digits only: no decimal point, no dollar sign, no plus/minus sign.

      <TaxAmount Exemptind>

      Required on Level 2

      Optional on non Level 2


      Used to identify if the Level 2 transactions is tax exempt "true" or "false" and the tax amount.

      <TerminalID>

      Required

      This ID is issued by JetPay LLC when an account is set up with the merchant bank.


      <TicketNumber>

      Optional, but Required for Corp Cards only

      TicketNumber is an optional flag that can be used in several different cases.

      For Restaurant transctions - it represents the ticket ID or invoice number of the customer's check For Travel transactions – it represents the Ticket Number

      For Corporate Cards - it represents the Customer Code

      For MOTO transactions – it represents the Invoice Number

      <TipAmount>

      Optional

      For Restaurant transctions, the wait staff's service fee applied to the customer's order.

      <Token>

      Required

      Used in place of sending the CardNumber, CardExpMonth and CardExpYear fields.

      <Token Tokenize>

      Required

      Used when updating the credit card data in the JetPay system for an existing Token.

      <TotalAmount>

      Required

      Purchase price to be transacted, including taxes and fees. The currency type assumed for the amount is dependent on the merchant. Digits only: no decimal point, no dollar sign, no plus/minus sign. Value must be non-zero.

      <Track 1> or

      <Track 2>

      Required

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETICE STRIPE, CONTACTLESS MS or MOBILE READER. Track 2 data is required when <Debit Type>.

      <Track1 Encryption='DUKPT-TDES-DATA-HEX' Key> or

      <Track2 Encryption='DUKPT-TDES-DATA-HEX' Key>

      Required


      DUKPT Key followed by the encrypted card data.

      <Track1 Tokenize>

      Required

      Used when requesting a Token by submitting by mag stripe.

      <TransactionID>

      Required

      The TransactionID is an 18- alpha-numeric value.


      <TransactionType>

      Required

      AUTHONLY

      The credit card limit is checked to verify a certain amount is available (and to reserve that amount), but the card is not charged. A FORCE or CAPT is used to complete the transaction.

      BATCH CLEAR

      When BatchID is used on transactions; Batch Clear is used to delete the transactions in the open batch.

      BATCH RELEASE

      When BatchID is used on transactions; Batch Release is used to close the batch. This responds with the count and totals for each card issuer.

      BATCH STATUS

      When BatchID is used on transactions; Batch Status is used to return the current count and totals for each card issuer.

      CAPT

      A credit card charge using an amount equal to or less than the amount of a previous AUTHONLY transaction. The AUTHONLY transaction is required to be present in the JetPay system for the capture to complete.

      CHECK

      ACH only. Authorize and capture an ACH transaction. CREDIT

      The CREDIT transaction submits a credit card transaction reversal for settlement. The CREDIT reverses a transaction regardless of the settlement status of the transaction it reverses.

      ENQ

      Query for a credit card charge in the JetPay system. Response text is AUTHORIZED when a transaction was an AUTHONLY, or ACCEPTED when the transaction was a FORCE, or APPROVED for a SALE or AUTHONLY/FORCE or AUTHONLY/CAPT, or TRANS NOT FOUND.

      FORCE

      The JetPay system will capture the transaction using the given amount and authorization code. This does not require a corresponding AUTHONLY transaction be present in the JetPay system.

      MEMO

      Memo transactions (also called 'Memo Post') are transactions that do not have a direct authorization or clearing impact, but that do have a financial impact on the merchant. The primary use of the memo transaction is going to be to capture the information on debit transactions made by JetPay's merchant but not using JetPay's debit system.

      PING

      Verify active communication with the acquirer software. Response text reads PING to acknowledge this transaction.

      REJECT

      REJECT transaction is to be used when the merchant, terminal, or ICC chooses to reject an approval received from JetPay. The REJECT must happen immediately at the time of the approval, and timeliness checks for that may apply, additionally a REJECT can only be submitted using the UniqueID returned with the approval.

      REVERSAL

      ACH only. Ship out an ACH transaction.

      SALE

      Authorizes/Captures a credit card charge in a single transaction.


      image



      SEEK

      Use when a POS device needs to determine if the card is PIN Debit capable.

      TOKENIZE

      Allows a merchant to request a token which takes the place of the card number and the expiration date when performing credit card transactions. For ACH transactions, the token will take the place of the ABA (routing code) and DDA (account number).

      VOID

      Removes a credit card transaction from the host before the transaction settles. If a transaction has already settled, it cannot be voided (when a transaction is not voided before settlement, a CREDIT transaction is required to reverse the charge).

      The VOID also attempts to free a cardholder's open-to-buy for a prior AUTHONLY transaction.

      VOIDACH

      ACH only. Remove an ACH transaction before settlement.

      <UDField1>

      Optional

      User-defined field, available for reporting purposes.

      <UDField2>

      Optional

      User-defined field, available for reporting purposes.

      <UDField3>

      Optional

      User-defined field, available for reporting purposes.

      <UniqueID>

      Required


      UniqueID provides an index that directly references the specific transaction at JetPay associated with a response message. This is used when sending a VOID transaction for credit cards and PIN Debit.

      <UserAgent>

      Optional

      For eCommerce transactions, the customer's HTTP browser type.

      <UserHost>

      Optional

      For eCommerce transactions, the Customer's host name.

      <UserIPAddr>

      Optional


      For eCommerce transactions, the Customer's IP address.

      <Verification>

      <CAVV>

      <ECI>

      <XID>

      <ICC>

      <AID>

      <AIP>

      <AppUsageControl>

      <ARQC>

      <ATC>

      <AuthorizedAmount>

      <CardSeqNum>

      <CryptInfoData>

      <CurrencyCode>

      <CustomerExclusiveData>

      <CVMResult>

      <DFName>

      <FormFactor>

      <IFDSerialNum>

      <IssuerAppData>

      <IssuerAuthData>

      <IssuerScript1>

      <IssuerScript2>

      <IssuerScriptResults>

      <OtherAmount>

      <TermAppVer>

      <TermCapCode>

      <TermCountryCode>

      <TermType>

      <TransCategoryCode> <TransDate>

      <TransSeqNum>

      <TransType>

      <TVR>

      <UnpredictableNumber>

      <PINBlock>

      <KSN>

      Optional


      The Verification block provides transactional support for cardholder security. It is used in POS terminals for PIN and EMV chip support. It is used by eCommerce merchants subscribing to Verified by Visa and SecureCode.

      Note: For the <ICC> sub-tags, please refer to Section 4.2.2.1 – Datagram Elements for EMV Transactions for the specific tags required by each card brand.

    2. . JetPay Transaction Response Elements and Definitions



<ActionCode>

ActionCode is three (3) characters. The ActionCode contains a '000' value to indicate a transaction has been approved by the issuer bank. The ActionCode will be some other value when either the issuer bank declines the transaction or if the JetPay server host detects an error.



<AddressMatch>

Code indicating the address match results for a credit card transaction. Returns: Y – The address matches

N – The address does not match

X – No result available (AVS requested but not performed)


<AdditionalInfo>


Conditionally present.


<Approval>

The issuer bank returns an authorization code, six (6) alphanumeric characters long. The Approval is only present if the ActionCode is '000'. A 'PING' transaction does not return an Approval value.


<AuthorizedAmount>

AuthorizedAmount is available to indicate a partial authorization of a purchase card transaction. The AuthorizedAmount returned in the response is always less than the TotalAmount sent in the merchant's request. This AuthorizedAmount gets deducted from the TotalAmount to establish a 'remaining balance' necessary to complete a transaction. This feature is only available for devices/websites capable of supporting partial authorizations.


<AVS>

Address Verification System: By verifying billing address information, merchants insure that their customers are representing their financial responsibilities in good faith. AVS mitigates lower transaction fees for many participating

merchants.


<BalanceAmount>

BalanceAmount contains the amount available on a prepaid card or a debit card. This amount is returned by a balance inquire.


<BatchID>

Enable Merchant-Initiated Terminal Reconciliation feature. The BatchID allows a merchant to tag a transaction for manual settlement. Any transaction having a BatchID does not settle until the merchant manually triggers the settlement of transactions having matching BatchIDs.

<CardProgram>


The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for settlement.

0 = Not a Level 2, B = Business Card,

R = Corporate Card, or S = Purchasing Card

<CVV2>

The response code to a Visa CVV2, a MasterCard CVC2 or an American Express CID submission. Refer to JetPay CVV2 Result Codes for an explanation of the valid result codes.


<ErrMsg>

Error message, if any. This error message usually describes an XML syntax error in the submitted JetPay transaction. This element will usually contain a message that points out the specific XML syntax errors within the submitted XML document. You should only expect to see this element during development. If you see this element in your production software system, analyze your software immediately and make corrections accordingly.

<ICC>

<ATC>


ICC block will contain significant chip-oriented response data. In a POS device, this response information may need to be delivered to the chip by the POS device before a transaction can be completed.


<JetPayResponse Version='2.2'>


Root element, enclosing the following transaction elements:


<RawResponseCode>

Raw response Code from the association or gateway that JetPay submitted the transaction to. The ActionCode tag must be used to determine if the transaction succeeded or failed, as there are a number of cases where we may decline a transaction that the association approved. Additionally, in the case of a Partial Approval this will be a 10

while the ActionCode is 000.


<ResponseText>

Message from the JetPay server describing the ActionCode returned.

There are multiple ResponseText values; please refer to the Action Code Tables: 17.1 – Visa, 17.2 – MasterCard, 17.3 – American Express, 17.4 – Discover and 17.5 – JetPay for specific descriptions. Please note: Do NOT code

to the ResponseText as the values can change. Instead, you should code to the actual ActionCode value returned.

<RRN>

Retrieval Reference Number as it was sent to the association; this is sometimes needed when working with the associations and is required information when doing terminal certifications with the associations.

<Summary>

<SummaryDetailCardType>

<TransactionSubtotalAmount>

<TransactionCount>

<SummaryDetail>


Batch Processing: This provides the breakdown of each Card Type (i.e., Transaction Subtotal Amount and Transaction Count) within the batch.


<TimeStamp>

For most XML transactions using XML version 2.1 or later a TimeStamp tag will be provided, the date/time in this tag is that of the start of the transaction by JetPay, not the time of the response. This time matches how the transaction will be recorded in our database. This is in the standard XML time/date format, in UTC. Of note, this TimeStamp can not be used to fulfill PCI requirement 10.4 requiring time synchronization from industry accepted time sources.


<Token>

Token provides an alias for a customer's credit card number. A Token can be safely stored by a merchant and used in lieu of a card number in subsequent transactions. A Token is not a card number, but it references a customer's credit card number already stored at JetPay.


<TransactionID>

This 18-character value matches the TransactionID submitted in the corresponding JetPay request transaction message. This value can be used to correlate the transaction's acknowledgment information with its submitted

request data.


<UniqueID>

UniqueID provides an index that directly references the specific transaction at JetPay associated with a response message.

<VerificationResult>

The response code to a Visa CAVV or a MasterCard UCAF submission. Refer to CAVV Result Codes for an explanation of the valid result codes.


<ZipMatch>

Code indicating the pos X, where:

Y – Postal code match results for a credit card transaction. Returns: Y, N, or code matches

N – Postal code doesn't match

X – No result available (AVS requested but not performed).

4. General Examples

The following examples illustrate JetPay transaction messages, showing a sample request message with a corresponding sample response message.


    1. . AUTHONLY Transaction

      In an AUTHONLY transaction, JetPay accepts the XML transaction block containing the credit card transaction information, retrieves an authorization response from the card issuer, and responds back to the original sender with that resulting authorization information. By sending a zero dollar amount, this can validate that the card is valid (card verify).

      REQUEST


      <TransactionType>

      AUTHONLY

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen characters long and preferably a unique value.

      <CardNum CardPresent>

      Manual Entry

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      Track 1 or Track 2

      Swiped Entry

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETICE STRIPE.

      <TotalAmount>

      Transaction amount, (Ex. 1000 = $10.00).

      <Origin>

      POS, INTERNET, RECURRING, PHONE ORDER or MAIL ORDER

      <IndustryInfo Type>

      RETAIL, RESTAURANT, MOTO, FINANCIAL and ECOMMERCE

      <ReaderUsed>

      MAGNETIC STRIPE or KEYPAD

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly 6 characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

      settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>010327153017T10018</TransactionID>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>010327153017T10018</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST51</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPhQcUoTlPkQj</UniqueID>

      <RRN>509318000005</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Example: AUTHONLY – Swiped Entry

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>010327153018R10130</TransactionID>

      <Track2>;476173******0119=21122011758954089?</Track2>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>MAGNETIC STRIPE</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>010327153018R10130</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST51</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPhQcUoTlPkQj</UniqueID>

      <RRN>509318000005</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>


    2. . PARTIAL AUTHORIZATION Transaction


      *** BEFORE PARTIAL AUTHORIZATIONS BECOME AVAILABLE, ***

      *** THE MERCHANT MUST ARRANGE TO ENABLE THE MERCHANT FLAG ***

      *** ALLOWING PARTIAL APPROVAL RESPONSES ***


      Partial Approvals – Merchants can systemically conduct split-tender purchases by allowing card issuers (including prepaid) to systemically approve a portion of the original transaction amount in the authorization request when the transaction amount exceeds the funds available on the card. The merchant can then systemically initiate split- tender processing and obtain the remainder of the purchase amount in another form of payment.


      Balance Response – Prepaid issuers can transmit account balance information in an authorization response, cardholders will attempt fewer purchases that exceed their available balances, leading to fewer declines at the POS.


      In order to test partial authorizations the terminal ID assigned to the tester has to be properly flagged as capable of handling partial authorizations. On the test system, card numbers beginning with BIN '501010' or '550909' are presumed to be prepaid cards. Any card number that has this prefix and passes a Luhn check is automatically loaded with a balance of $50.


      It is unnecessary to load or activate a card because it is implicitly initialized in the simulator for immediate use. The prepaid card balance is retained for thirty minutes. After thirty minutes of non-use, the simulator resets the card back to its $50 prepaid amount.


      All testing against that prepaid card must be completed within the span of the thirty minutes. Testing with the same card number should not be restarted until thirty minutes has elapsed. The following are example card numbers. These can also be used for testing. However there could be other developers using these card numbers, so it would be a good idea to generate unique card numbers within the card range.


      Example of some card numbers (the card number used must pass the luhn 10 check digit routine):

      550909 XXXXXX 3026

      550909 XXXXXX 3034

      550909 XXXXXX 3042

      550909 XXXXXX 3059

      NOTE: The handling of split tender using multiple prepaid cards is a function of the client POS device. The XML response will contain significant results, and it is up to the POS terminal and its operator to supply the logic necessary to handle split tender properly.


      The remaining balance on a prepaid card may or may not be returned from JetPay in the response message.


      If the issuing bank returns a balance, JetPay will also return the balance in the response.


      REQUEST

      <TransactionType>

      SALE or AUTHONLY

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen characters long and unique value is recommended.

      <CardNum CardPresent>

      Manual Entry

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      Track 1 or Track 2

      Swiped Entry

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETIC STRIPE.

      <Origin>

      POS

      <ReaderUsed>

      MAGNETIC STRIPE or KEYPAD.

      <TotalAmount>

      Transaction amount, (digits only).

      <IndustryInfo Type>

      RETAIL

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      PARTIALLY APPROVED or APPROVED

      <BalanceAmount>

      Balance remaining - Some issuers do not return this value.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <BatchID>

      Batch number used for merchant-initiated settlement purposes.

      <AuthorizedAmount>

      Amount partially approved.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example 1: On a fully-loaded prepaid card with a $50 balance, a sale amount of $5.00 results in an action code response: 000, Response Text: APPROVED, and Balance Amount: 45.00.

      Request AUTHONLY for $5.00

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>1501131004579MHTCM</TransactionID>

      <CardNum CardPresent='true'>501010******2092</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <Origin>POS</Origin>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <TotalAmount>500</TotalAmount>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>1501131004579MHTCM</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST05</Approval>

      <ResponseText>APPROVED</ResponseText>

      <BalanceAmount>4500</BalanceAmount>

      <UniqueID>QnRkXnTkQnPoPhQbRlPoPkQn</UniqueID>

      <RRN>549319000007</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Example 2: On a fully-loaded prepaid card with a $50 balance, a sale amount of $60 results in an action code response: 000, Response Text: PARTIALLY APPROVED, and an Authorized Amount: 50.00.

      Request AUTHONLY for $60.00

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150113100648UT538P</TransactionID>

      <CardNum CardPresent='true'>501010******2092</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <Origin>POS</Origin>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <TotalAmount>6000</TotalAmount>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150113100648UT538P</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST29</Approval>

      <ResponseText>PARTIALLY APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPhQbRlUkPkQm</UniqueID>

      <RRN>549319000008</RRN>

      <RawResponseCode>10</RawResponseCode>

      <BatchID>50001</BatchID>

      <AuthorizedAmount>4500</AuthorizedAmount>

      <TimeStamp>2016-01-06T21:24:26Z</TimeStamp>

      </JetPayResponse>

      Example 3: On a completely-spent prepaid card having a zero balance, any sale amount will result in an action code response: 051, Response Text: DECLINED.


      Request AUTHONLY for $5.00

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150113100750SBBK98</TransactionID>

      <CardNum CardPresent='true'>501010******2092</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>216</CardExpYear>

      <Origin>POS</Origin>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <TotalAmount>500</TotalAmount>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150113100750SBBK98</TransactionID>

      <ActionCode>051</ActionCode>

      <Approval>TEST33</Approval>

      <ResponseText>DECLINED</ResponseText>

      <BalanceAmount>0</BalanceAmount>

      <UniqueID>QnRkXnTkQnPoPhQbTkUmPkQb</UniqueID>

      <RRN>549319000011</RRN>

      <RawResponseCode>51</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

    3. . CAPT Transaction


      A CAPT (or capture) transaction enables a previously authorized transaction to be settled into a complete sale. In a CAPT transaction, JetPay accepts the XML transaction block containing the credit card transaction information, looks up the matching authorized transaction and responds back to the original sender with the resulting sales information.


      The matching AUTHONLY transaction for this capture operation must have been authorized through JetPay in order for the CAPT transaction to be successful. If a transaction was not authorized through JetPay, the response to the CAPT will indicate that the authorization was not found.


      REQUEST

      <TransactionType>

      CAPT

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string exactly eighteen characters long, either matching the target 'AUTHONLY' transaction or otherwise containing a unique value.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message from the original

      AUTHONLY request.

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

      settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example: CAPT transaction:

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>CAPT</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>010327153017T10518</TransactionID>

      (Either the Original TransactionID or the Orignal UniqueID can be used)

      <UniqueID>QnRkXnTkQnPoPmQnUkPhPkSh</UniqueID>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>010327153017T10518</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST34</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPmQnUkPhPkSh</UniqueID>

      <RRN>509615000009</RRN>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      A CAPT transaction will fail whenever a matching authorization cannot be found in JetPay's system and the transaction will be rejected. When JetPay declines a CAPT transaction, the response would look like this:


      Response

      JetPayResponse Version="2.2">

      <TransactionID>010327153017T10018</TransactionID>

      <ActionCode>025</ActionCode>

      <Approval>REJECT</Approval>

      <ResponseText>ED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPmQoPnTnPkRh</UniqueID>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

    4. . SALE Transaction

      A SALE transaction is a 'two-in-one' operation, completing both an AUTHONLY transaction and a CAPT transaction using only a single submission.


      The required data for a SALE transaction request are the same as for an AUTHONLY transaction request (except that the TransactionType is SALE instead of AUTHONLY). The minimum data returned from a successful SALE transaction response are the same as for an AUTHONLY transaction response.


      REQUEST

      <TransactionType>

      SALE

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string exactly eighteen characters long, either matching the target 'AUTHONLY' transaction or otherwise containing a unique value.

      <CardNum CardPresent>

      Manual Entry

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      Track 1 or Track 2

      Swiped Entry

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETIC STRIPE.

      <TotalAmount>

      Transaction amount (digits only).

      <ReaderUsed>

      MAGNETIC STRIPE or KEYPAD

      <Origin>

      POS

      <IndustryInfo Type>

      Required when Origin is POS. Type must be RETAIL or RESTAURANT

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example: Sale – Manual Entry


      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>010327153017T10017</TransactionID>

      <CardNum CardPresent='true'>590909******3063</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>010327153017T10017</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST06</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPmQoToSiPkRm</UniqueID>

      <RRN>549614000014</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Example: Sale – Swiped Entry


      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>010327153017T10017</TransactionID>

      <Track1>%B400030******1000^MAVERICK INTERNATIONAL^21121010000000000000000?</Track1>

      <TotalAmount>1000</TotalAmount>

      <ReaderUsed>MAGNETIC STRIPE</ReaderUsed>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      JetPayResponse Version="2.2">

      <TransactionID>010327153017T10017</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST06</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPmQoToSiPkRm</UniqueID>

      <RRN>549614000014</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>


    5. . FORCE Transaction


      A FORCE transaction completes an authorized transaction, regardless of whether the transaction was authorized through JetPay or not. The JetPay server will assume that the submitted transaction has been properly authorized and will use the submitted authorization code to settle the transaction. The JetPay server always responds that the transaction is accepted for settlement processing (as long as complete transaction information is submitted in the FORCE transaction).


      REQUEST

      <TransactionType>

      FORCE

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string exactly eighteen characters long, preferably a unique value.

      <CardNum CardPresent>

      Manual Entry

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      Track 1 or Track 2

      Swiped Entry

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETIC STRIPE.

      <TotalAmount>

      Transaction amount (digits only).

      <ReaderUsed>

      MAGNETIC STRIPE or KEYPAD

      <Approval>

      Six characters long, matching the authorization code from the original transaction.

      <Origin>

      POS

      <IndustryInfo Type>

      Required when Origin is POS. Type must be RETAIL or RESTAURANT.

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.



      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

      settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      A FORCE transaction presumes that an authorization has already been previously approved by a proper method (for example, by voice authorization over the phone).


      Example: FORCE – Manual Entry

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>FORCE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>15040714291434EU58</TransactionID>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <Approval>502F6B</Approval>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>15040714291434EU58</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>502F6B</Approval>

      <ResponseText>ACCEPTED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPlQbRbRoPkTn</UniqueID>

      <RRN>549614000014</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Example: FORCE – Swipe Entry

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>FORCE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>15040714291434EU58</TransactionID>

      <Track1>%B400030******1000^MAVERICK INTERNATIONAL^21121010000000000000000?</Track1>

      <TotalAmount>1000</TotalAmount>

      <Approval>502F6B</Approval>

      <ReaderUsed>MAGNETIC STRIPE</ReaderUsed>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>15040714291434EU58</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>502F6B</Approval>

      <ResponseText>ACCEPTED</ResponseText>

      <RRN>549614000014</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      A FORCE transaction differs from a CAPT transaction inasmuch as the authorization does not have to originate with JetPay when it is forced. A FORCE transaction will complete the sale for any transaction whether that transaction originated through JetPay or not. JetPay attempts to settle the transaction using the submitted authorization code. When forcing a transaction, the successful completion of that transaction gets reported to the merchant through settlement (and not directly by the JetPay server).


    6. . VOID Transaction

      A VOID transaction removes an approved transaction before settlement. The JetPay server can only remove unsettled transactions specified by the VOID transaction, so settled transactions are ineligible for VOIDing. The JetPay server responds with either VOID PROCESSED or RECORD NOT FOUND, depending on the outcome of the transaction.

      REQUEST

      <TransactionType>

      VOID

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string exactly eighteen characters long.

      <UniqueID>

      Character string exactly eighteen characters long, matching the target CAPT or SALE or FORCE transaction.

      <Origin>

      POS, INTERNET, RECURRING, PHONE ORDER or MAIL ORDER

      <IndustryInfo Type>

      RETAIL, RESTAURANT, ECOMMERCE, MOTO or FINANCIAL

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.


      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message. Please note: this field is left blank but at JetPay's discretion it may be populated at any given time.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

      settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Presuming that the target sale transaction was successfully approved and has not yet settled, the following VOID transaction removes that target sale:

      Example: VOID


      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>VOID</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>15091511223121WTK6</TransactionID>

      (Either the Original TransactionID or the Orignal UniqueID can be used)

      <UniqueID>QkVhViRcQnPbQnQmRiTjRcTl</UniqueID>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>15091511223121WTK6</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST38</Approval>

      <ResponseText>VOID PROCESSED</ResponseText>

      <UniqueID></UniqueID>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>


    7. . CREDIT (Refund) Transaction


      The CREDIT transaction complements the SALE transaction. The CREDIT transaction is used to reverse a SALE, crediting the cardholder's account.

      Required data elements for a CREDIT transaction request are the same as for a SALE transaction request (except that the TransactionType is CREDIT instead of SALE). The data returned from a successful CREDIT transaction response are almost the same as for a SALE transaction response, except that AVS and CVV2 (and CVC2 and CID) are unavailable.

      REQUEST

      <TransactionType>

      CREDIT

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string exactly eighteen characters long, preferably a unique value.


      <CardNum CardPresent>

      Manual Entry

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      Track 1 or Track 2

      Swiped Entry

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETIC STRIPE.

      <TotalAmount>

      Transaction amount (digits only).

      <Origin>

      POS

      <ReaderUsed>

      MAGNETIC STRIPE or KEYPAD

      <IndustryInfo Type>

      Required when Origin is POS. Type must be RETAIL or RESTAURANT.

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      >DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

      settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example: CREDIT – Manual Entry

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>CREDIT</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150408090857MZZL4Y</TransactionID>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150408090857MZZL4Y</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>090908</Approval>

      <ResponseText>RETURN ACCEPTED</ResponseText>

      <RRN>549614000014</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Example: CREDIT – Swipe Entry


      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>CREDIT</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150408090857MZZL4Y</TransactionID>

      <Track1>%B400030******1000^MAVERICK INTERNATIONAL^21121010000000000000000?</Track1>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>MAGNETIC STRIPE</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150408090857MZZL4Y</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>090908</Approval>

      <ResponseText>RETURN ACCEPTED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPcQoPbPcPkTb</UniqueID>

      <RRN>549614000014</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

    8. . Cash Disbursement Transaction


      A Cash Disbursement is a cash loan from a credit card account. The card holder borrows against their credit card limit. Most credit card issuers have two limits, a limit for purchases and a limit for Cash Disbursements. Cash Disbursements have higher interest rates than purchases. The cardholder must be present to perform a Cash Disbursement. The Cash Disbursement transaction is limited to banks and financial institutions that fall under merchant category code (MCC) 6010 only.


      REQUEST

      <TransactionType>

      SALE

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string exactly eighteen characters long, matching the target transaction.

      <Origin>

      POS

      <Track1>

      <Track2>

      The character information contained in either the track 1 or track 2 magnetic stripes, including the beginning and ending sentinel characters.

      <IndustryInfo Type>

      FINANCIAL

      <DispenseMode>

      MANUAL

      <TotalAmount>

      Transaction amount (digits only).

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example: Cash Dispursement – Swipe Entry – SALE for $30.00:

      Request for $30.00

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>1506231046592EEPG2</TransactionID>

      <Origin>POS</Origin>

      <Track2>;476173******0119=21122011758954089?</Track2>

      <TotalAmount>3000</TotalAmount>

      <IndustryInfo Type='FINANCIAL'>

      <DispenseMode>MANUAL</DispenseMode>

      </IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>1506231046592EEPG2</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST78</Approval>

      <CVV2>P</CVV2>

      <ResponseText>APPROVED</ResponseText>

      <RRN>549614000014</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

    9. . ENQ Transaction


      An ENQ (or enquire) transaction enables verification and review of a previous transaction, including a previous AUTHONLY, SALE, CAPT, or FORCE transaction. In an ENQ transaction, JetPay accepts the XML transaction block containing the credit card transaction information, looks up the matching authorized transaction, and responds back to the original sender with the resulting search information.


      The matching transaction for the enquire operation must have been authorized or settled through JetPay in order for the ENQ transaction to be successful. If a target transaction was not processed through JetPay, the response to the ENQ will indicate that the transaction was not found.


      REQUEST

      <TransactionType>

      ENQ

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen characters long, matching the target transaction.

      <CardNum CardPresent>

      Manual Entry

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      Track 1 or Track 2

      Swiped Entry

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETIC STRIPE.

      <TotalAmount>

      Transaction amount (digits only).

      <Origin>

      POS

      <IndustryInfo Type>

      Required when Origin is POS. Type must be RETAIL or RESTAURANT.

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      You may ENQ (enquire) on a JetPay transaction, checking the status of that JetPay transaction gets accomplished in two ways by sending the TransactionID or by sending the card data.

      Original Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>1601270947156OWSOV</TransactionID>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150408105046IUS1BZ</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST66</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QkVhTkSkQmPjRlQnTlSlSbXn</UniqueID>

      <RRN>602715007468</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Example 1: Submitting the ENQ using just the TransactionID:

      ENQ Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>ENQ</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>1601270947156OWSOV</TransactionID>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>1601270947156OWSOV</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST66</Approval>

      <ResponseText>AUTHORIZED</ResponseText>

      <UniqueID>QkVhTkSkQmPjRlQnUkPmSbYk</UniqueID>

      <RRN>602715007468</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Example 2: Submitting the ENQ using the original credit card information along with a matching total amount and authorization code – Swipe Entry:

      Original Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150102085132W2BFOO</TransactionID>

      <Track1>%B400030******1000^MAVERICK INTERNATIONAL^21121010000000000000000?</Track1>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>MAGNETIC STRIPE</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      JetPayResponse Version="2.2">

      <TransactionID>150102085132W2BFOO</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST90</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPcQnUkUkPkUm</UniqueID>

      <RRN>509815000016</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>


      ENQ Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>ENQ</TransactionType>

      <TerminalID> ASSIGNEDTID </TerminalID>

      <TransactionID>150102085132W2BFOO</TransactionID>

      <Track1>%B400030******1000^MAVERICK INTERNATIONAL^21121010000000000000000?</Track1>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150102085132W2BFOO /TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST90</Approval>

      <ResponseText>AUTHORIZED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPcQmPlRhPkUb</UniqueID>

      <RRN>509815000016</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      image

      Example 3: Submitting the ENQ using the original credit card information along with a matching total amount and authorization code – Manual Entry:


      Original Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>160127095314BU37Z2</TransactionID>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150102085132W2BFOO</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST90</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>160127095314BU37Z2</UniqueID>

      <RRN>509815000016</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      ENQ Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>ENQ</TransactionType>

      <TerminalID> ASSIGNEDTID </TerminalID>

      <TransactionID>160127095314BU37Z2</TransactionID>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <Application Version='4.2'>VirtPOS</Application>

      <JetPayResponse Version="2.2">

      <TransactionID>160127095314BU37Z2/TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST90</Approval>

      <ResponseText>AUTHORIZED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPcQmPlRhPkUb</UniqueID>

      <RRN>509815000016</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>



      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>


      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      image

    10. . PING Transaction


      To check your Internet connection with the JetPay server, you can send a null transaction and receive back an innocuous response. This transaction only verifies the integrity of the Internet connection between the sender and JetPay's interface.


      The PING transaction allows you to judge the status of your communications link with the JetPay server.


      *** Sending PING transactions aggressively is not acceptable. At a maximum, please do not send any more than one per hour. ***


      REQUEST

      <TransactionType>

      PING

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen characters long, matching the target transaction.

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <GatewayID>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      Example: PING

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>PING</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>010327153017T10052</TransactionID>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>010327153017T10052</TransactionID>

      <ActionCode>000</ActionCode>

      <ResponseText>PING</ResponseText>

      <UniqueID></UniqueID>

      </JetPayResponse>


    11. . Error Response

      During testing, errors in building a syntactically correct JetPay request message can occur. The JetPay server parses a request message and determines where the XML syntax error occurs within the message. The ErrMsg element is filled in and sent back, informing developers of problems in building a syntactically correct JetPay message.


      The following example shows how a response looks when a JetPay syntax error is detected. To generate an error response, submit a request with a misspelled element; for this example, change the <TotalAmount> tag to

      <Amount>. Of course, since the element is misspelled, you will get the following response:


      Response

      <JetPayResponse Version="2.2">

      <TransactionID>15040811301038AHSN</TransactionID>

      <ActionCode>900</ActionCode>

      <ResponseText>INVALID MESSAGE TYPE</ResponseText>

      <ErrMsg>INPUT XML STREAM FAILS PARSING. Faulty JetPay message. Error on line 8, column 9. Message: Unknown element 'Amount'Fatal Error in "JetPayDataFatal error on line 8, column 16 Message: Expected end of tag 'Amount'</ErrMsg>

      </JetPayResponse>

      Note: The TransactionID field may come back empty in the response message. Because the XML was faulty, the XML parser becomes uncertain of the contents of the message, including the integrity of other XML data

      within the same message. The only time you should ever receive a JetPay response with no TransactionID is when a faulty JetPay request gets sent.


    12. . SEEK "PIN Debit" Transaction


      A SEEK transaction is useful when the POS device needs to determine if the card is PIN Debit capable. In a SEEK transaction, JetPay accepts the XML transaction block containing the credit card information and checks the card bin against the bin tables loaded on the JetPay host. The response will either be true or false. If true, the card can be used as a PIN Debit transaction.

      REQUEST

      <TransactionType>

      SEEK

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen characters long and preferably a unique value.

      <LookUp>

      Look up request.

      <Sources>

      Identifying where the data is located.

      <BinTable>

      True

      <Return>

      Identifying request type.

      <DebitCapable>

      True

      <ByCardNum>

      Valid Credit Card Number.

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <GatewayID>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      <LookUpRsp>

      Returns a 1.

      <Transaction>

      Returns either True or False.

      Example: SEEK


      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SEEK</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150623115611QOI3I7</TransactionID>

      <LookUp>

      <Sources><BinTable>true</BinTable></Sources>

      <Return><DebitCapable>true</DebitCapable></Return>

      <ByCardNum>483312******0001</ByCardNum>

      </LookUp>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150623115611QOI3I7</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval> 1</Approval>

      <ResponseText>1 TRANS FOUND</ResponseText>

      <UniqueID>QkViQnWcQnPmRhQmUmQbRnPk</UniqueID>

      <TimeStamp>2016-01-27T16:09:21Z</TimeStamp>

      <LookUpRsp>

      <Count>1</Count>

      <Transaction>

      <DebitCapable>true</DebitCapable>

      </Transaction>

      </LookUpRsp>

      </JetPayResponse>

    13. . Additional Examples


      JetPay supports common credit card industry features, including address verification, card validation, and cardholder authentication, and recurring transactions. A merchant who submits transactions that subscribe to any of these features can lower their transactions fees or reduce fraud (or both).


      Visa and MasterCard call address verification 'AVS'; American Express calls it AAV. By submitting the billing address and postal code of a customer, the merchant receives a result code that indicates whether the merchant's information matches the address information on file with the cardholder's bank. The risk of a credit card transaction is lower when matching billing address information is submitted in a JetPay transaction.


      Card validation is achieved through CVV2, CVC2, and CID, collectively called CVV2 by JetPay. Every credit card has a three- or four-digit CVV2 number on the back (or front) of every physical credit card. A merchant can submit a CVV2 value along with a transaction to validate a physical credit card. When a validated card is submitted, the merchant receives charge back protection because the existence of the physical credit card is validated as the origin of the credit card number.


      Cardholder authentication is featured by Verified by Visa and SecureCode. To authenticate that a customer is the legal cardholder for a credit card, a website allows their customer to log in to Verified by Visa and SecureCode. Then, a credit card transaction proceeds after the cardholder's identity is authenticated. This offers charge back protection to the subscribing merchant whenever Verified by Visa and SecureCode is invoked.


      Recurring transactions are used to declare a payment agreement between a merchant and their customer. The three types of recurring transactions are recurring and standing order and bill payment transactions. The recurring and standing order transactions are used for subscription-based payment (i.e., monthly payments that remain the same every month). The 'bill payment' transaction is used for service-based payment where the actual amount of a payment might differ between payments (i.e., your electric bill varies from month-to-month). There will be more explanation on this later.


    14. . Address Verification (AVS)

      By verifying billing address information, merchants insure that their customers are representing their financial responsibilities in good faith. For example, an online dating service that advertises a trustworthy reputation may wish to verify their subscribers' billing addresses, or a travel agency might wish to verify that they are delivering some expensive plane tickets to a proven billing address. However, regardless of whether AVS is actually necessary for a business to operate. AVS mitigates lower transaction fees for many participating merchants. This is reason alone for any merchant to participate in AVS.


      American Express also performs a name-matching operation. By submitting the cardholder's name on an Amex transaction, additional AVS responses are available.


      REQUEST

      <TransactionType>

      SALE

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen characters long, matching the target transaction.

      <CardNum CardPresent>

      Manual Entry

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      Track 1 or Track 2

      Swiped Entry

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETIC STRIPE.

      <TotalAmount>

      Transaction amount (digits only).

      <CardName>

      The customer name, that is, the name of the cardholder.

      <Billing>

      The billing address information and billing postal code information will enable AVS processing: Address, City, StateProv, PostalCode, Country, Phone.

      <Origin>

      POS

      <IndustryInfo Type>

      Required when Origin is POS. Type must be RETAIL or RESTAURANT

      <ReaderUsed>

      MAGNETIC STRIPE or KEYPAD


      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <AddressMatch>

      Y, N or X: Y = Yes match, N = No match and X = No result available.

      <ZipMatch>

      Y, N or X: Y = Yes match, N = No match and X = No result available.

      <AVS>

      The result code sent by an issuer advising the merchant of a customer's billing integrity. Please refer to the Result Codes section for specific codes.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example: SALE with AVS – Manual Entry

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150408131030GRT3RC</TransactionID>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <CardName>Bob Tucker</CardName>

      <Billing>

      <Address>8800 Central Dr.</Address>

      <City>Dallas</City>

      <StateProv>TX</StateProv>

      <PostalCode>75251</PostalCode>

      <Country>USA</Country>

      <Phone>214-890-1800</Phone>

      </Billing>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150408131030GRT3RC</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST47</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPcQcQkScPkVk</UniqueID>

      <RRN>509818000017</RRN>

      <RawResponseCode>00</RawResponseCode>

      <AddressMatch>Y</AddressMatch>

      <ZipMatch>Y</ZipMatch>

      <AVS>Y</AVS>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>


      Example: SALE with AVS – Swipe Entry


      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150408131030GRT3RC</TransactionID>

      <Track1>%B400030******1000^MAVERICK INTERNATIONAL^21121010000000000000000?</Track1>

      <TotalAmount>1000</TotalAmount>

      <CardName>Bob Tucker</CardName>

      <Billing>

      <Address>8800 Central Dr.</Address>

      <City>Dallas</City>

      <StateProv>TX</StateProv>

      <PostalCode>75251</PostalCode>

      <Country>USA</Country>

      <Phone>214-890-1800</Phone>

      </Billing>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>MAGNETIC STRIPE</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150408131030GRT3RC</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST47</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPcQcQkScPkVk</UniqueID>

      <RRN>509818000017</RRN>

      <RawResponseCode>00</RawResponseCode>

      <AddressMatch>Y</AddressMatch>

      <ZipMatch>Y</ZipMatch>

      <AVS>Y</AVS>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      The above example is applicable to AUTHONLY transactions in addition to the SALE transactions. JetPay's AVS is automatically invoked whenever an incoming transaction contains billing address data.


      Merchants may invoke AVS for AUTHONLY and SALE transactions only. AVS is not available for CAPT, FORCE, CREDIT, or other transactions.


    15. . Card Validation (CVV2)

      For card validation, Visa offers CVV2, MasterCard offers CVC2, and American Express offers CID for detecting the presence of a valid physical credit card. JetPay enables these features under the collective name of CVV2.

      All physical credit cards have a three- or four-digit CVV2 value imprinted on them. The CVV2 is calculated as a function of the card number, the expiration date, and a secret key value set by the card's issuer. The formula for calculating CVV2 is a trade secret known only to the credit card associations and the card issuers. After receiving a transaction having a CVV2 along with the credit card number and expiration date, the credit card companies discern the presence of an authentic physical credit card at authorization time. Fraud and risk factors can be weighed.

      NOTE: Please keep in mind the CVV2 is a three- or four-digit value and not a number. Having a leading zero (0) is valid, example - '054' and should be sent as such.

      REQUEST

      <TransactionType>

      SALE

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen characters long, matching the target transaction.

      <CardNum CardPresent>

      Manual Entry

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      <TotalAmount>

      Transaction amount (digits only).

      <CVV2>

      The three-digit value found printed on the back of the card; or for AmEx the four-digit value embossed on the front of the card.

      <Origin>

      POS

      <IndustryInfo Type>

      Required when Origin is POS. Type must be RETAIL or RESTAURANT

      <ReaderUsed>

      MAGNETIC STRIPE or KEYPAD

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.


      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <CVV2>

      The result code sent by an issuer advising the merchant of a customer's card validation. Please refer to the Result Codes section for specific codes.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

      settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example: SALE with CVV2 – Manual Entry

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150408143103QO5VJ9</TransactionID>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <CVV2>465</CVV2>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150408143103QO5VJ9</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST19</Approval>

      <CVV2>S</CVV2>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPcQbSjPmPkVj</UniqueID>

      <RRN>509819000018</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      The above example is applicable to AUTHONLY transactions in addition to the SALE transactions.


      JetPay's CVV2 is automatically invoked whenever an incoming transaction contains a CVV2 value. Merchants may invoke CVV2 for AUTHONLY and SALE transactions only. CVV2 is definitely not available for CAPT, FORCE, CREDIT, or other transactions.


      Never write down or otherwise store a CVV2 value; it isn't allowed. Merchants are advised never to save CVV2 values on any processing system. All card associations cite rules restricting merchants from saving CVV2 values. JetPay LLC is also subject to these rules, so CVV2 values are also not stored in JetPay's system. The CVV2 is only permitted to exist in a processing system for the duration of the transaction. If a merchant is found to be storing CVV2 values, they are subject to being fined by the card associations.


    16. . Cardholder Authentication (CAVV)

      Visa and MasterCard offer a system for verifying the person submitting a credit card in a transaction as the true owner of that credit card. Visa offers Verified by Visa (a.k.a. CAVV) and MasterCard offers SecureCode (a.k.a. UCAF) to accomplish cardholder authentication. This feature is currently only available for transactions sent by ecommerce merchants.


      To accomplish cardholder authentication, immediately prior to sending an authorization to JetPay, the ecommerce merchant presents their customer to Cardinal Commerce. Cardinal Commerce splashes up a dialog box that will query for a user account and password from the customer. Upon completion of this authentication process, Cardinal Commerce generates a CAVV token. The CAVV token becomes included in the authorization transaction's data.

      JetPay accepts the CAVV token within both the AUTHONLY and SALE transactions. The token serves as proof that a merchant has attempted cardholder authentication. The ecommerce merchant receives charge back protection in return for their authentication attempt.

      RESPONSE

      <TransactionType>

      SALE or AUTHONLY

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen characters long, matching the target transaction.

      <CardNum CardPresent>

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      <TotalAmount>

      Transaction amount (digits only).

      <Verification>

      The Verification block provides transactional support for cardholder security.

      <Origin>

      INTERNET

      <IndustryInfo Type>

      ECOMMERCE

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.

      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000

      <Approval>

      Character string exactly six characters long.

      <ResponseText>

      The transaction's outcome status.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

      settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example: Verified by Visa SALE

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150408145819WKTPOU </TransactionID>

      <CardNum CardPresent='false'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <Verification>

      <CAVV Usage = '2' Encoding = 'BASE64'>BwAQASdSdwUFERdUZFJ3EENDaa4=</CAVV>

      <ECI>06</ECI>

      <XID Encoding = 'BASE64'>uhzrZEtTk/wsRsa6hV3/dbfJEPk=</XID>

      </Verification>

      <Origin>INTERNET</Origin>

      <IndustryInfo Type='ECOMMERCE'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150408145819WKTPOU</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST18</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPcQbUcRiPkVi</UniqueID>

      <RRN>509819000019</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      The Encoding= attribute simply specifies whether the data is BINARY, HEX or BASE64. The default format for the CAVV and XID token is in Base 64, which is compatible with the standard encoding method used by Cardinal Commerce. You can set the attribute explicitly, Encoding='BASE64' such that the merchant will not have to convert the CAVV they receive in to a different scheme. Set the Usage attribute to '2'. It's generally unnecessary to declare the Usage and Encoding formatof these tokens because they're rarely manipulated to be any other format.


      The XID element follows the same reasoning as CAVV.

      The ECI value is a one-digit code determined from the PAR (Payer Authentication Request) satus, that is, the result of Verified by Visa processing with Cardinal Commerce. Good values are '5', '6', or '7'. If the PAR transaction status is:

      a. 'Y' (success), then the ECI is '5', which is good b. 'U' (unable), then the ECI is '7'

      c. 'A' (attempt), then the ECI is '6'

      d. 'N' (attempt with proof of attempt), then the ECI is '6' e. 'N' (failed) then the transaction shall not be submitted


      The response to a Verified by Visa transaction looks like the following: Example: AUTHONLY transaction with SecureCode

      Request

      Response

      JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150408152900MID533</TransactionID>

      <CardNum CardPresent='false'>500040******2001</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <Verification>

      <CAVV>jJDMZodNcgMiARAC1PFZd/YPT4k=</CAVV>

      <XID>IpM03Vsyp9TQzzrGDQBK/9TQT1A=</XID>

      <ECI>02</ECI>

      </Verification>

      <Origin>INTERNET</Origin>

      <IndustryInfo Type='ECOMMERCE'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      JetPayResponse Version="2.2">

      <TransactionID>150408152900MID533</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST85</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPcRkRbPiPkVl</UniqueID>

      <RRN>549820000017</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Notice that the implicit defaults for Base 64 encoding for the CAVV and XID were assumed. The SecureCode result is included in the transaction response, and it looks like this.


    17. . Recurring & Bill Payment Examples


Recurring transactions are low-risk transactions submitted on a periodic basis. A customer authorizes periodic payments to a merchant, enabling the merchant to submit authorizations to the credit card companies with prior approval, but without the customer's involvement in performing the periodic transactions. The merchant fulfills a periodic subscription or a standing order according to a merchant-customer agreement, and the merchant fills the customer's order automatically without customer interaction.

An example of a merchant who can use recurring payments is an online dating service having a monthly subscription fee. Their customer subscribes to their service, agreeing to a monthly fee automatically applied to their credit card. The merchant sends monthly transactions to fulfill their customer's subscription to their services.

Bill payment transactions are also low-risk transactions that are submitted on a periodic basis. However, for bill payment, a customer's relationship with their merchant is usage-oriented (instead of subscription-oriented). A customer may need to approve a variable monthly bill for fees accrued during that period, and bill payment fits the description of the transactions made by that customer.

image

Merchants who use bill payment may include utility companies and other companies who send periodic billing to regular customers. The merchant may maintain a website that enables bill payment by their customer.REQUEST


<TransactionType>

SALE

<TerminalID>

Terminal ID, assigned by JetPay LLC.

<TransactionID>

Character string, exactly eighteen characters long, matching the target transaction.

<CardNum CardPresent>

Valid credit card number with CardPresent value of True or False.

<CardExpMonth>

Credit card expiration month (two digits).

<CardExpYear>

Credit card expiration year (two digits).

<TotalAmount>

Transaction amount (digits only).

<Origin>

RECURRING or BILL PAYMENT



<IndustryInfo Type>

RETAIL

<Application Version>

Identifying the system originating the transaction.

<Device Version>

Identifying the system originating the transaction.

<Library Version>

Identifying the system originating the transaction.

<Gateway>

Identifying the system originating the transaction.

<DeveloperID>

Identifying the system originating the transaction.

RESPONSE

<TransactionID>

Matching the value in the request, above.

<ActionCode>

000

<Approval>

Character string exactly six characters long.

<ResponseText>

The transaction's outcome status.

<UniqueID>

An index that directly references the specific transaction at JetPay associated with a response message.

<RRN>

Retrieval Reference Number as it was sent to the association.

<RawResponseCode>

00 or for a Partial Approval you will receive a 10.

<CardProgram>

The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

<TimeStamp>

The date/time of the start of the transaction by JetPay, not the time of the response.

Example: RECURRING transaction

Request

Response

<JetPay Version='2.2'>

<TransactionType>SALE</TransactionType>

<TerminalID>ASSIGNEDTID</TerminalID>

<TransactionID>150408154550CP7C0O </TransactionID>

<CardNum CardPresent='false'>400030******1000</CardNum>

<CardExpMonth>12</CardExpMonth>

<CardExpYear>21</CardExpYear>

<TotalAmount>1000</TotalAmount>

<Origin>RECURRING</Origin>

<IndustryInfo Type='RETAIL'></IndustryInfo>

<Application Version='4.2'>VirtPOS</Application>

<Device Version='1.0'>Fake POS</Device>

<Library Version='1.5'>VirtPOS SDK</Library>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID>150408154550CP7C0O</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST60</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QnRkXnTkQnPoPcRkTnUhPkVc</UniqueID>

<RRN>509820000020</RRN>

<RawResponseCode>00</RawResponseCode>

<CardProgram>0</CardProgram>

<TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

</JetPayResponse>

Example: BILL PAYMENT transaction

Request

Response

<JetPay Version='2.2'>

<TransactionType>SALE</TransactionType>

<TerminalID> ASSIGNEDTID</TerminalID>

<TransactionID>B00000129708368001</TransactionID>

<CardNum CardPresent='false'>400030******1000</CardNum>

<CardExpMonth>12</CardExpMonth>

<CardExpYear>21</CardExpYear>

<TotalAmount>1000</TotalAmount>

<Origin>BILL PAYMENT</Origin>

<IndustryInfo Type='RETAIL'></IndustryInfo>

<Application Version='4.2'>VirtPOS</Application>

<Device Version='1.0'>Fake POS</Device>

<Library Version='1.5'>VirtPOS SDK</Library>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID> B00000129708368001</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST66</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QnRkXnTkQnPoPcRkTcSiPkVb</UniqueID>

<RRN>509820000021</RRN>

<RawResponseCode>00</RawResponseCode>

<CardProgram>0</CardProgram>

<TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

</JetPayResponse>

When considering the use of recurring transactions, some merchants start with the wrong idea about recurring transactions. The following explanations are significant:


JetPay supports recurring transactions. Recurring transactions are simply transactions that are automatically authorized by an agreement between a merchant and their customer. The merchant is authorized to submit recurring transactions without the customer's direct involvement subsequent to the initial authorization.

JetPay's recurring transactions are not an automated customer billing service. Some merchants mistakenly think that they only have to set up a repeat billing scheme with JetPay and that JetPay will take care of the rest. This is not so.

The purpose of declaring a recurring transaction is to declare a transaction's risk. Recurring transactions are considered low-risk by the credit card industry, and fee schedules for transactions are lower for recurring transactions. The reason for submitting a recurring transaction is to be awarded lower transaction rates, not to set up automated billing.


There are legal reasons why JetPay does not offer automated customer billing. If you are looking for a billing system that automatically charges customer and simply sends you a check every month, then there are numerous legal documents to sign that would define the merchant's responsibilities to their customers and absolve the billing service of liability for unpaid transactions. Although JetPay's services fit into the business model for such customer billing services, JetPay does not supply that automated customer billing service itself.


JetPay is in the business of lowering your transaction fees. When you submit recurring transactions, you're declaring to the credit card companies that you have a legal agreement between you and your customer for payment. Credit card companies award you a lower transaction fee when you submit a recurring transaction.


5. Application-Specific Examples

The following examples illustrate JetPay transaction messages, showing a sample request message with a corresponding sample response message.


    1. . Explicitly Invoking Alternatives Using Routing Code

      Some merchants subscribe to alternative back-end processing, which are different than the default back-end connections configured for default JetPay processing. For example, a merchant might have contractual obligations to use a specific third-party processor for their transactions, or a merchant might wish to send transactions in foreign currencies to a processor specializing in banking with those currencies. By explicitly declaring the RoutingCode, a merchant can route their JetPay transaction to a non-default connection.


      A merchant having diverse banking partners might need to use the RoutingCode to declare the desired destination of a transaction to JetPay.


      To declare explicit routing to a specific connection, a merchant simply adds the RoutingCode element to their transaction with a predetermined eight-character code value. JetPay will then direct that explicitly labeled transaction to the destination processor specified by the RoutingCode.


      Note: Please be advised, in order to process using a specific Routing Code, you will need to contact JetPay for special arrangements.


      The following is an example of explicit routing using the RoutingCode:

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>210227153217T1X018</TransactionID>

      <RoutingCode>ForeignB</RoutingCode>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <TotalAmount>1000</TotalAmount>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version='2.1'>

      <TransactionID>210227153217T1X018</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>512G6B</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPbRkUmUoPkXo</UniqueID>

      <RRN>509920000028</RRN>

      <RawResponseCode>59</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      If a merchant declares an invalid RoutingCode value, JetPay will time out on the transaction with a response (ActionCode = '992') that describes the failure to reach that non-existent destination.


    2. . Retail - Restaurant Industry Type

      The retail industry consists of brick-and-mortar merchants that submit card-present transactions to JetPay. Transactions are commonly submitted using a POS (point-of-sale) terminal device having a magnetic stripe reader. Some merchants have developed and deployed POS terminal emulators, (similar to JetPay's Virtual Terminal software), to run on standard desktop computers and submit standard retail transactions. All of these POS transactions are classified as a RETAIL industry type.


      JetPay can process POS terminal transactions via the Internet from brick-and-mortar store locations. In these cases, a brick-and-mortar store is presumed to be any shop or restaurant that consummates credit card sales for purchases made with physical credit cards. This document covers the XML features that support POS terminal transactions via JetPay. The JetPay server, constructed by JetPay LLC, supports the POS features described in this document.


      For credit card sales, the credit card is physically presented to the merchant to pay for the sale. The merchant may scan data off of the credit card's magnetic stripe using a magnetic card reader, initiating a credit card transaction. The merchant may also manually key in data off of the face of the card to initiate a credit card transaction.

      PIN-based debit card sales are also available through JetPay.


      This document is targeted at developers of POS terminal software. A developer may be writing software for a POS terminal device capable of network communications. A developer may be enhancing a merchant's custom POS server, used throughout all their retail stores. A developer may be developing a POS terminal emulation program (also known as a 'virtual terminal') destined to run as either a website-based application or perhaps as a standalone application. This document covers the XML specifications necessary for communicating a POS transaction to JetPay.


      For debit card processing, the reader of this document is presumed to already understand PIN-based debit card processing using a PIN pad. The reader must already understand encryption techniques associated with PIN pads. This document explains the JetPay interface used in setting up PIN-based debit card processing. This document does not explain how to initialize a PIN pad, inject a key, etc.


      The reader of this document is also presumed to be familiar with XML. XML is a markup language for building so- called 'XML documents.' JetPay LLC defines the JetPay transactions through XML documents. As you browse through the examples at the end of this document, please keep in mind that each JetPay transaction is an XML document, that XML is case-sensitive, and that JetPay LLC strives to follow XML document conventions for defining its JetPay transactions. JetPay LLC recommends that the reader review XML's authoring rules for building XML documents, educating themselves with an implicit understanding of the underlying XML syntax rules that underpin all JetPay transactions.


    3. . Corporate/Business/Purchase Card Processing (Level 2)

The card brands offer special credit cards for companies designed to help them manage their spending and streamline the purchasing process. These cards are used for B2B merchants with special interchange rates.

Commercial credit cards offer companies advanced functionality, such as the ability to set employee-spending limits and restrict card usage to specific types of purchases. For example, a cardholder might be authorized to use the card only for purchasing office supplies.

Here is what commercial credit cards are used for:

Travel and entertainment expenses

Procurement Expenses

Integrated multi-purpose card

The collection of sales tax data at the point of sale helps to ensure that companies, who are enrolled in commercial credit card programs, pay the correct sales tax for purchased goods.

Some companies use this information to simplify their sales tax preparation. For each card type, sales tax is required to be prompted for and captured at the POS. To augment sales tax processing, an additional prompt at the POS prompts: sales tax not provided, sales tax included or tax exempt may be activated.

The sales tax data submitted is sent to the card issuer in the authorization record. In addition to the standard data presented to the cardholder’s company when it receives its bill, the Card Brands also report the sales tax information associated with the transaction. The information is never shared with tax agencies.

Purchasing cards, in addition to the tax information, require a customer code prompt at the time of sale. The

<TicketNumber> tag can be used to transmit the Customer Code information in a request. This code is used to identify the transaction. This could be an internal code, general ledger account number, or a job number. This code is captured and sent along with the sales tax and sales tax indicator in the settlement record.

In order to identify what type of card it is so that the correct prompts are displayed at the POS, a card type indicator is returned in the authorization:

Card Type

Response Tag

Required in Capture

B = Business Card R = Corporate Card S = Purchasing Card

<CardProgram>B</CardProgram>

<CardProgram>R</CardProgram>

<CardProgram>S</CardProgram>

<TaxAmount ExemptInd="false" or "true">

<TaxAmount ExemptInd="false" or "true">

<TaxAmount ExemptInd="false" or "true"> and <OrderNumber>


When testing, the following dollar amounts will generate the card program indicators:

B = Business Card

R = Corporate Card

S = Purchasing Card

$25.00

$50.00

$75.00

Sales Tax Test

Required in Capture

Transaction is NOT tax exempt with tax

<TaxAmount ExemptInd="false">00091</TaxAmount>

Transaction is NOT tax exempt with no tax

<TaxAmount ExemptInd="false">0</TaxAmount>

Transaction IS tax exempt with no tax

<TaxAmount ExemptInd="true">0</TaxAmount>

The card type is unknown at the time of purchase, so an authorization only transaction is performed to identify the card as Business, Corporate, or Purchasing. The following is an example of responses for each card program:


Example 1: Business Card

Authorization Request Business Card

Authorization Response Business Card

<JetPay Version='2.2'>

<TransactionType>AUTHONLY</TransactionType>

<TerminalID>TESTMCC3000X</TerminalID>

<TransactionID>170217095808LBWXNF</TransactionID>

<CardNum CardPresent='true'>40771XXXXXXX0263</CardNum>

<CardExpMonth>12</CardExpMonth>

<CardExpYear>21</CardExpYear>

<TotalAmount>2500</TotalAmount>

<Origin>POS</Origin>

<IndustryInfo Type='RETAIL'></IndustryInfo>

<ReaderUsed>KEYPAD</ReaderUsed>

<Application Version='4.2'>VirtPOS</Application>

<Device Version='1.0'>Fake POS</Device>

<Library Version='1.5'>VirtPOS SDK</Library>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID>170217095808LBWXNF</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST30</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QkVnYoUbQlPiQlQnUmSkSjRn</UniqueID>

<RRN>704815001604</RRN>

<RawResponseCode>00</RawResponseCode>

<TimeStamp>2017-02-17T15:56:30Z</TimeStamp>

<CardProgram>B</CardProgram>

</JetPayResponse>

Capture Request

Capture Response

<JetPay Version='2.2'>

<TransactionType>CAPT</TransactionType>

<TerminalID>TESTMCC3000X</TerminalID>

<TransactionID>170217095808LBWXNF</TransactionID>

(Either the Original TransactionID or the Orignal UniqueID can be used)

<UniqueID> QkVnYoUbQlPiQlQnUmSkSjRn</UniqueID>

<TotalAmount>2500</TotalAmount>

<TaxAmount ExemptInd="false">100</TaxAmount>

(Tax amount is included in

The total transaction)

<Application Version='4.2'>VirtPOS</Application>

<Device Version='1.0'>Fake POS</Device>

<Library Version='1.5'>VirtPOS SDK</Library>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID>170217095808LBWXNF</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST30</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QkVnYoUbQlPiQlQnUcPiSjRm</UniqueID>

<RRN>704815001604</RRN>

<TimeStamp>2017-02-17T15:58:02Z</TimeStamp>

<CardProgram>B</CardProgram>

</JetPayResponse>

Example 2: Corporate Card

Authorization Request Corporate Card

Authorization Response Corporate Card

<JetPay Version='2.2'>

<TransactionType>AUTHONLY</TransactionType>

<TerminalID>TESTMCC3000X</TerminalID>

<TransactionID>170217095808LBWXNF</TransactionID>

<CardNum CardPresent='true'>40771XXXXXXX0263</CardNum>

<CardExpMonth>12</CardExpMonth>

<CardExpYear>21</CardExpYear>

<TotalAmount>5000</TotalAmount>

<Origin>POS</Origin>

<IndustryInfo Type='RETAIL'></IndustryInfo>

<ReaderUsed>KEYPAD</ReaderUsed>

<Application Version='4.2'>VirtPOS</Application>

<Device Version='1.0'>Fake POS</Device>

<Library Version='1.5'>VirtPOS SDK</Library>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID>170217095808LBWXNF</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST30</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QkVnYoUbQlPiQlQnUmSkSjRn</UniqueID>

<RRN>704815001604</RRN>

<RawResponseCode>00</RawResponseCode>

<TimeStamp>2017-02-17T15:56:30Z</TimeStamp>

<CardProgram>R</CardProgram>

</JetPayResponse>


Capture Request

Capture Response

<JetPay Version='2.2'>

<TransactionType>CAPT</TransactionType>

<TerminalID>TESTMCC3000X</TerminalID>

<TransactionID>170217095808LBWXNF</TransactionID>

(Either the Original TransactionID or the Orignal UniqueID can be used)

<UniqueID> QkVnYoUbQlPiQlQnUmSkSjRn</UniqueID>

<TotalAmount>2500</TotalAmount>

<TaxAmount ExemptInd="false">100</TaxAmount>

(Tax amount is included in

The total transaction)

<Application Version='4.2'>VirtPOS</Application>

<Device Version='1.0'>Fake POS</Device>

<Library Version='1.5'>VirtPOS SDK</Library>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID>170217095808LBWXNF</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST30</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QkVnYoUbQlPiQlQnUcPiSjRm</UniqueID>

<RRN>704815001604</RRN>

<TimeStamp>2017-02-17T15:58:02Z</TimeStamp>

<CardProgram>R</CardProgram>

</JetPayResponse>

Example 3: Purchasing Card

Authorization Request Purchasing Card

Authorization Response Purchasing Card

<JetPay Version='2.2'>

<TransactionType>AUTHONLY</TransactionType>

<TerminalID>TESTMCC3000X</TerminalID>

<TransactionID>170217095808LBWXNF</TransactionID>

<CardNum CardPresent='true'>40771XXXXXXX0263</CardNum>

<CardExpMonth>12</CardExpMonth>

<CardExpYear>21</CardExpYear>

<TotalAmount>7500</TotalAmount>

<Origin>POS</Origin>

<IndustryInfo Type='RETAIL'></IndustryInfo>

<ReaderUsed>KEYPAD</ReaderUsed>

<Application Version='4.2'>VirtPOS</Application>

<Device Version='1.0'>Fake POS</Device>

<Library Version='1.5'>VirtPOS SDK</Library>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID>170217095808LBWXNF</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST30</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QkVnYoUbQlPiQlQnUmSkSjRn</UniqueID>

<RRN>704815001604</RRN>

<RawResponseCode>00</RawResponseCode>

<TimeStamp>2017-02-17T15:56:30Z</TimeStamp>

<CardProgram>S</CardProgram>

</JetPayResponse>

Capture Request

Capture Response

<JetPay Version='2.2'>

<TransactionType>CAPT</TransactionType>

<TerminalID>TESTMCC3000X</TerminalID>

<TransactionID>170217095808LBWXNF</TransactionID>

(Either the Original TransactionID or the Orignal UniqueID can be used)

<UniqueID> QkVnYoUbQlPiQlQnUmSkSjRn</UniqueID>

<TotalAmount>2500</TotalAmount>

<TaxAmount ExemptInd="false">100</TaxAmount>

(Tax amount is included in

The total transaction)

<TicketNumber>123456</TicketNumber>

(TicketNumber is required on purchase card transactions)

<Application Version='4.2'>VirtPOS</Application>

<Device Version='1.0'>Fake POS</Device>

<Library Version='1.5'>VirtPOS SDK</Library>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID>170217095808LBWXNF</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST30</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QkVnYoUbQlPiQlQnUcPiSjRm</UniqueID>

<RRN>704815001604</RRN>

<TimeStamp>2017-02-17T15:58:02Z</TimeStamp>

<CardProgram>S</CardProgram>

</JetPayResponse>

6. Credit Card Examples

The following examples help to illustrate typical JetPay POS messages, showing sample POS request messages with a corresponding sample response messages.


    1. . Magnetic Stripe POS Retail Sale Transaction

      A magnetic stripe reader can collect basic credit card information. By passing the magnetic stripe data in a SALE or AUTHONLY transaction, the issuer examines the magnetic stripe data to determine its authenticity and approves or declines a transaction accordingly. The integrity of magnetic stripe data is generally high, so these magnetic stripe POS transactions are preferred over other methodologies; there is a lower transactional cost for submitting the magnetic stripe data within a transaction.


      Either track 1 or track 2 information must be submitted with a magnetic stripe transaction. At least one of the two tracks is required. The credit card must always be assumed to be present whenever track 1 or track 2 information is submitted, so there is no CardPresent attribute in a magnetic stripe transaction. The Origin defaults to POS, the IndustryInfo Type defaults to RETAIL, and the ReaderUsed defaults to MAGNETIC STRIPE, but it's a good programming practice to explicitly declare these values instead of relying on the defaults.


      If you need to submit a RESTAURANT sale transaction which includes support for tips and additional charges, advance to the next sub-section for an example.


      REQUEST

      <TransactionType>

      SALE, AUTHONLY, CREDIT, or VOID.

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen alphanumeric characters long, preferably a unique value.

      Track 1 or Track 2

      Swiped Entry

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETIC STRIPE.

      <Origin>

      POS

      <ReaderUsed>

      MAGNETIC STRIPE

      <TotalAmount>

      Total amount of the transaction, including any taxes, fees, and surcharges (digits only).

      <IndustryInfo Type>

      A declaration of the Type attribute for this market segment is needed. Appropriate values for the Type are RETAIL or RESTAURANT.

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeveloperID>

      Identifying the system originating the transaction.


      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000 or other three-digit value.

      <Approval>

      Six alphanumeric characters or less (or absent).

      <CVV2>

      The three-digit value found printed on the back of the card; or for AmEx the four-digit value embossed on the front of the card.

      <ResponseText>

      APPROVEDo r DECLINED.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

      settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example: Retail - Magnetic Stripe

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150409103014CCF9CH </TransactionID>

      <Track2>;400030******1000=21121011139300000378?</Track2>

      <Origin>POS</Origin>

      <ReaderUsed>MAGNETIC STRIPE</ReaderUsed>

      <TotalAmount>1000</TotalAmount>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150409103014CCF9CH</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST19</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPbQnSkQlPkWi</UniqueID>

      <RRN>509915000022</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Do not rely on default values for Origin, ReaderUsed, and IndustryInfo Type. When track data is sent, the Origin value defaults to POS, the ReaderUsed value defaults to MAGNETIC STRIPE, and the IndustryInfo's Type defaults to RETAIL. When the track data is absent, the defaults change to internet-based values. When building a POS terminal program, do not rely on default values for relating terminal information; better results are obtained when values are explicitly declared.


      Note: The above example shows no CardPresent attribute. When sending magnetic stripe data, a physical credit card is automatically presumed to be present. Therefore, it is unnecessary to explicitly operate any CardPresent attribute because its value cannot ever be 'false'. Saving track data is a card association violation, so it is patently invalid to declare the CardPresent attribute as 'false' (and therefore redundant to declare it to be 'true'). When sending track data, ignore any CardPresent attribute because its value is constant.


      If the above transaction had been declined, the sample response might be:

      Response

      <JetPayResponse Version="2.2">

      <TransactionID>150409104101DUVW3Q</TransactionID>

      <ActionCode>005</ActionCode>

      <ResponseText>DECLINED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPbQnTjPhPkWo</UniqueID>

      <RRN>509915000023</RRN>

      <RawResponseCode>05</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>


    2. . Magnetic Stripe Transaction for Restaurant


      As mentioned in the previous example, the issuer examines the magnetic stripe data to determine its authenticity and approves or declines a transaction accordingly. The AUTHONLY transaction enables the allocation of open-to- buy funds without actually finalizing the sale. A subsequent CAPT transaction is used to finalize the transaction by submitting the adjusted total amount.


      Many restaurants need this two-step authorize-and-capture procedure, providing a means for adjusting the final authorized total after adding a tip for the wait staff. By sending an AUTHONLY transaction with the magnetic stripe information, the restaurant obtains an initial authorization for the subtotal. The subsequent CAPT transaction contains the tip amount and the total amount signed for by the cardholder.


      Refer to the previous example for a description of tags and values to be used in a magnetic stripe transaction.


      A restaurant transaction is initiated on a $35.00 subtotal, such that a tax of 8.25% is added onto the bill. This sample retail restaurant magnetic stripe transaction is the resulting AUTHONLY authorization request for $37.89:



      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150409110443GOFY89</TransactionID>

      <Track1>%B400030******1000^MAVERICK INTERNATIONAL^21121010000000000000000?</Track1>

      <Origin>POS</Origin>

      <ReaderUsed>MAGNETIC STRIPE</ReaderUsed>

      <TotalAmount>3789</TotalAmount>

      <TaxAmount>289</TaxAmount>

      <IndustryInfo Type='RESTAURANT'>

      <TicketNumber>3333</TicketNumber>

      <BaseAmount>3500</BaseAmount>

      <TipAmount>0</TipAmount>

      <ServerID>CHRIS5</ServerID>

      <TableNumber>25</TableNumber>

      </IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150409110443GOFY89</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST29</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPbQmPoTmPkWn</UniqueID>

      <RRN>509916000024</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      At this point, a restaurant presents the authorized transaction to the cardholder, intending to add the tip amount and receive back a signature from the cardholder. The tip amount gets reported along with the adjusted total amount in the CAPT transaction.


      The cardholder adds a $6.00 tip to the authorization. This CAPT request finalizes the preceding authorization example to an adjusted total amount of $43.89:

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>CAPT</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150409110443GOFY89</TransactionID>

      <TotalAmount>4389</TotalAmount>

      <TaxAmount>289</TaxAmount>

      <IndustryInfo Type='RESTAURANT'>

      <TicketNumber>3333</TicketNumber>

      <BaseAmount>3500</BaseAmount>

      <TipAmount>600</TipAmount>

      <ServerID>CHRIS5</ServerID>

      <TableNumber>25</TableNumber>

      </IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150409110443GOFY89</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST29</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPbQmQlQiPkWc</UniqueID>

      <RRN>509916000024</RRN>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      Note: That the TransactionID of the CAPT transaction is the same as that of the preceding AUTHONLY transaction. In cases where the CAPT amount is different from the AUTHONLY amount, the TransactionIDs of these paired transactions must match.


      Throughout these AUTHONLY and CAPT examples, the TotalAmount always reflects the grand total of the total purchase, including the base amount plus tax and plus tip. Although you may omit the BaseAmount, TaxAmount, and TipAmount, the TotalAmount still must always be submitted as the grand total for a complete transaction.


      The CAPT amount will be the settled amount of a transaction. The AUTHONLY amount represents the authorized amount. Except for restaurants, JetPay LLC advises that the CAPT amount should be the same as the AUTHONLY amount (because of increased transactional fees when the amounts are not the same); restaurants avoid these increased fees because tip-adjusted amounts are a common business model for restaurant sales.


    3. . Manually Entered POS Transaction

      Sometimes the magnetic stripe data cannot be read on a credit card. When that happens, manual data entry on a keypad becomes the alternative. It's practical to build a POS terminal capable of manual data entry.


      A manually entered POS transaction looks similar to the internet-based examples within this document. The difference between a POS transaction and an eCommerce transaction is the declaration of non-default values for the transaction. The JetPay server will interpret a manually entered transaction as a POS transaction only when

      the Origin, ReaderUsed, and IndustryInfo Type are explicitly declared. For a manually entered POS transaction, you are required to explicitly add the Origin, ReaderUsed, and IndustryInfo Type.


      REQUEST

      <TransactionType>

      SALE, AUTHONLY, CREDIT, or VOID

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string exactly eighteen alphanumeric characters long, preferably a unique value.

      <CardNum CardPresent>

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      The expiration month, '01' through '12'.

      <CardExpYear>

      The last two digits of the expiration year.

      <Origin>

      POS

      <ReaderUsed>

      KEYPAD

      <TotalAmount>

      Total amount of the transaction, including any taxes, fees, and surcharges (digits only).

      <IndustryInfo Type>

      A declaration of the Type attribute for this market segment is needed. Appropriate values for the Type are RETAIL or RESTAURANT.

      <Application Version>

      Identifying the system originating the transaction.

      <Device Version>

      Identifying the system originating the transaction.

      <Library Version>

      Identifying the system originating the transaction.

      <Gateway>

      Identifying the system originating the transaction.

      <DeverloperID>

      Identifying the system originating the transaction.


      RESPONSE

      <TransactionID>

      Matching the value in the request, above.

      <ActionCode>

      000 or other three-digit value

      <Approval>

      Six alphanumeric characters or less (or absent).

      <ResponseText>

      APPROVEDo r DECLINED.

      <UniqueID>

      An index that directly references the specific transaction at JetPay associated with a response message.

      <RRN>

      Retrieval Reference Number as it was sent to the association.

      <RawResponseCode>

      00 or for a Partial Approval you will receive a 10.

      <CardProgram>

      The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

      settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

      <TimeStamp>

      The date/time of the start of the transaction by JetPay, not the time of the response.

      Example: Retail transaction – Manual Entry

      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>150409114216ZOJ0MB</TransactionID>

      <CardNum CardPresent='true'>400030******1000</CardNum>

      <CardExpMonth>12</CardExpMonth>

      <CardExpYear>21</CardExpYear>

      <Origin>POS</Origin>

      <ReaderUsed>KEYPAD</ReaderUsed>

      <TotalAmount>1000</TotalAmount>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>150409114216ZOJ0MB</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST14</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QnRkXnTkQnPoPbQmTiRkPkWb</UniqueID>

      <RRN>509916000025</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      </JetPayResponse>

      In the above example, please note that the CardPresent attribute is set to true. This means that the credit card is in the presence of the merchant. Because the default value of the CardPresent attribute is false, it becomes important to declare CardPresent explicitly in every transaction. For all retail POS transactions, the CardPresent attribute should always be explicitly set to either true or false.


      Note: The value of the CardPresent attribute indicates tangible availability of a physical credit card to a merchant during a transaction. The CardPresent attribute can be set to true whenever a merchant can easily handle

      and view a credit card during a transaction. The CardPresent attribute must be set to false whenever only the PAN (that is, the credit card number) is available to a merchant.


      For manually entered transactions, the default value for Origin is INTERNET and the default value for the IndustryInfo Type is ECOMMERCE. You must always explicitly declare the Origin (as POS) and IndustryInfo Type (as RETAIL or RESTAURANT) in every manually entered POS transaction.


      The default value of ReaderUsed for manually entered card numbers is KEYPAD, but JetPay LLC advises to explicitly declare the value of ReaderUsed anyway for the sake of consistency, regardless of the default.


    4. . Contactless Track POS Transaction

The contactless track readers can collect credit card information when an operator touches the reader with a credit card. The issuer examines the contactless track data in a similar manner to the tracks on a magnetic stripe; the issuer determines a card's authenticity and approves or declines a transaction accordingly.


REQUEST

<TransactionType>

SALE, AUTHONLY, CREDIT, or VOID

<TerminalID>

Terminal ID, assigned by JetPay LLC.

<TransactionID>

Character string, exactly eighteen alphanumeric characters long, preferably a unique value.

<Track2>

The character information contained in track 2 magnetic stripe, including the beginning and ending sentinel characters.

<Origin>

POS

<ReaderUsed>

CONTACTLESS MS

<TotalAmount>

Total amount of the transaction, including any taxes, fees, and surcharges (digits only).

<IndustryInfo Type>

A declaration of the Type attribute for this market segment is needed. Appropriate values for the Type are RETAIL or RESTAURANT.

<Application Version>

Identifying the system originating the transaction.

<Device Version>

Identifying the system originating the transaction.

<Library Version>

Identifying the system originating the transaction.

<Gateway>

Identifying the system originating the transaction.

<DeveloperID>

Identifying the system originating the transaction.


RESPONSE

<TransactionID>

Matching the value in the request, above.

<ActionCode>

000 or other three-digit value.

<Approval>

Six alphanumeric characters or less (or absent).

<CVV2>

The three-digit value found printed on the back of the card; or for AmEx the four-digit value embossed on the front of the card.

<ResponseText>

APPROVED or DECLINED

<UniqueID>

An index that directly references the specific transaction at JetPay associated with a response message.

<RRN>

Retrieval Reference Number as it was sent to the association.

<RawResponseCode>

00 or for a Partial Approval you will receive a 10.

<CardProgram>

The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for

settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

<TimeStamp>

The date/time of the start of the transaction by JetPay, not the time of the response.

Example: Retail Contactless Track Transaction

Request

Response

<JetPay Version='2.2'>

<TransactionType>SALE</TransactionType>

<TerminalID>ASSIGNEDTID</TerminalID>

<TransactionID>1504091151428DJN9I</TransactionID>

<Track2>;400030******1000=21121011139300000378?</Track2>

<Origin>POS</Origin>

<ReaderUsed>CONTACTLESS MS</ReaderUsed>

<TotalAmount>1000</TotalAmount>

<IndustryInfo Type='RETAIL'></IndustryInfo>

<Application Version='4.2'>VirtPOS</Application>

<Device Version='1.0'>Fake POS</Device>

<Library Version='1.5'>VirtPOS SDK</Library>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID>1504091151428DJN9I</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST15</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QnRkXnTkQnPoPbQmUjTnPkXk</UniqueID>

<RRN>509916000026</RRN>

<RawResponseCode>00</RawResponseCode>

<CardProgram>0</CardProgram>

<TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

</JetPayResponse>

In the above example, only track 2 data was sent within the transaction request. Only track 2 is enabled, so it's important that JetPay server receives the track data from track 2.


For contactless track transactions, the Origin, ReaderUsed, and IndustryInfo Type must always be explicitly submitted. The Origin value is POS, the ReaderUsed value is CONTACTLESS MS, and the IndustryInfo's Type should be RETAIL or RESTAURANT.


7. EMV Chip POS Transaction

The EMV chip readers begin processing credit card information after an operator inserts a chip-bearing credit card into the chip reader of a POS terminal. According to EMV protocols, the EMV chip on the credit card communicates with the EMV reader to determine the optimal method for verifying the authenticity of the card and cardholder. The EMV reader generates datagram information, encapsulating the ensuing cardholder verification process. The datagram gets conveyed to JetPay within an XML transaction.

For developers looking for test environment cards, orders can be placed directly with B2 (www.b2ps.com), a company offering the EMV testing tools. Please visit the following website: http://files.ctctcdn.com/82925169401/6cb1d5f3-244c-450e-8206-81190d994923.pdf

REQUEST

<TransactionType>

SALE, AUTHONLY, CREDIT, or VOID

<TerminalID>

Your terminal ID, assigned by JetPay LLC.

<TransactionID>

Character string, exactly eighteen alphanumeric characters long, no spaces, preferably a unique value.

<Track2>

The track 2 information, including the credit card number (or PAN) and the card expiration date.

<Origin>

POS

<ReaderUsed>

CHIP or CONTACTLESS CHIP

<ReadersFailed>

<Reader>CHIP</Reader> and/or <Reader>CONTACTLESS CHIP</Reader> and/or <Reader>MAGNETIC STRIPE</Reader> and/or etc.

<TotalAmount>

Total amount of the transaction, including any taxes, fees, and surcharges (digits only).

<Verification>

This is the root element holding a cardholder verification block. The EMV cardholder verification method proceeds via specifications within the EMV chip.

<ICC>

This element contains the encrypted datagram built by the EMV chip reader. The EMV chip reader delivers the binary datagram which must be marshalled into multiple subfields representing the EMV chip's verification environment.

<IndustryInfo Type>

A declaration of the Type attribute for this market segment is needed. Appropriate values for the Type are RETAIL or RESTAURANT.

<Application Version>

Identifying the system originating the transaction.

<Device Version>

Identifying the system originating the transaction.

<Library Version>

Identifying the system originating the transaction.

<EMVKernel>

As certified by EMVCo.

<Gateway>

Identifying the system originating the transaction.

<DeveloperID>

Identifying the system originating the transaction.

RESPONSE

<TransactionID>

Matching the value in the request, above.

<ActionCode>

000 or other three-digit value.

<Approval>

Six alphanumeric characters or less (or absent).

<ResponseText>

APPROVED or DECLINED

<UniqueID>

An index that directly references the specific transaction at JetPay associated with a response message.

<RRN>

Retrieval Reference Number as it was sent to the association.

<RawResponseCode>

00 or for a Partial Approval you will receive a 10.

<CardProgram>

The card program is used for Level 2 processing. So that the POS device/software can prompt for the necessary data for settlement. 0 = Not a Level 2, B = Business Card, R = Corporate Card, or S = Purchasing Card

<TimeStamp>

The date/time of the start of the transaction by JetPay, not the time of the response.

<ICC>

This element contains the datagram elements returned by the issuer.

    1. . Datagram Elements for EMV Transactions


      The ICC tag consists of numerous predefined subfields, subdivided into multiple tag-value constituents. Because JetPay's XML demands a simple ASCII format for the fields, the ICC data is delivered in hexadecimal format. The table below, lists all the ICC tags (and their associated datagram tags) supported by JetPay:



      MasterCard

      Visa

      Discover

      AmEx

      tag 9F06

      <AID>

      Application identifier.

      X

      tag 82

      <AIP>

      Application interchange profile.

      X

      X

      X

      X

      tag 9F07

      <AppUsageControl>

      Application usage control.

      X

      tag 9F26

      <ARQC>

      Application cryptogram.

      X

      X

      X

      X

      tag 9F36

      <ATC>

      Application transaction counter.

      X

      X

      X

      X

      tag 9F02

      <AuthorizedAmount>

      Amount authorized.

      X

      X

      X

      X

      tag 5F34

      <CardSeqNum>

      Application PAN sequence number.

      X

      tag 9F27

      <CryptInfoData>

      Cryptogram information data.

      X

      X

      X

      tag 5F2A

      <CurrencyCode>

      Transaction currency code.

      X

      X

      X

      X

      tag 9F7C

      <CustomerExclusiveData>

      Customer exclusive data.

      X

      tag 9F34

      <CVMResult>

      Cardholder verification method (CVM) results.

      X

      X

      tag 84

      <DFName>

      Dedicated file name.

      X

      X

      tag 9F6E

      <FormFactor>

      Device type.

      X

      tag 9F1E

      <IFDSerialNum>

      Interface device (IFD) serial number.

      X

      X

      tag 9F10

      <IssuerAppData>

      Issuer application data.

      X

      X

      X

      X

      tag 91

      <IssuerAuthData>

      Issuer authentication data.

      X

      X

      X

      X

      tag 71

      <IssuerScript1>

      Issuer script template #1.

      X

      X (x10)

      X

      X

      tag 72

      <IssuerScript2>

      Issuer script template #2.

      X

      X (x10)

      X

      X

      tag 9F5B

      <IssuerScriptResults>

      Issuer script results

      X

      X

      tag 9F03

      <OtherAmount>

      Cryptogram Cashback Amount. Required when including the cashback amount..

      X

      X

      X

      X

      tag 9F09

      <TermAppVer>

      Application version number.

      X

      X

      tag 9F33

      <TermCapCode>

      Terminal capabilities.

      X

      X

      X

      tag 9F1A

      <TermCountryCode>

      Terminal country code.

      X

      X

      X

      X

      tag 9F35

      <TermType>

      Terminal type.

      X

      X

      tag 9F53

      <TransCategoryCode>

      Transaction category code.

      X

      tag 9A

      <TransDate>

      Transaction data, maps to terminal transaction date.

      X

      X

      X

      X

      tag 9F41

      <TransSeqNum>

      X

      X

      tag 9C

      <TransType>

      Transaction type, maps to cryptogram transaction type.

      X

      X

      X

      X

      tag 95

      <TVR>

      Terminal verification result (TVR).

      X

      X

      X

      X

      tag 9F37

      <UnpredictableNumber>

      Unpredictable number.

      X

      X

      X

      X

      The examples in the next section illustrate the ICC elements from this table within a JetPay XML transaction.

    2. . EMV Chip POS Transaction Example


      This sample retail EMV chip transaction is a sale for $5.00:


      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>AUTHONLY</TransactionType>

      <TerminalID>ASSIGNEDTID</TerminalID>

      <TransactionID>201702211222450003</TransactionID>

      <BatchID>414</BatchID>

      <Track2>;441105######7675=1905201#############?</Track2>

      <TaxAmount>0</TaxAmount>

      <FeeAmount>0</FeeAmount>

      <TotalAmount>500</TotalAmount>

      <Verification>

      <ICC>

      <AIP>1800</AIP>

      <ARQC>5A0BEDBBBF9AD7E5</ARQC>

      <ATC>004D</ATC>

      <AuthorizedAmount>000000000500</AuthorizedAmount>

      <CardSeqNum>00</CardSeqNum>

      <CurrencyCode>0840</CurrencyCode>

      <IssuerAppData>06010A03A02018</IssuerAppData>

      <OtherAmount>000000000000</OtherAmount>

      <TermCapCode>E0F8C8</TermCapCode>

      <TermCountryCode>0840</TermCountryCode>

      <TransDate>170221</TransDate>

      <TransTime>122242</TransTime>

      <TransType>00</TransType>

      <TVR>8080008000</TVR>

      <UnpredictableNumber>95C21DD6</UnpredictableNumber>

      </ICC>

      </Verification>

      <Origin>POS</Origin>

      <IndustryInfo Type='RETAIL'>

      <TipAmount>0</TipAmount>

      <BaseAmount>500</BaseAmount>

      </IndustryInfo>

      <ReaderUsed>CHIP</ReaderUsed>

      <Application Version='4.2'>VirtPOS</Application>

      <Device Version='1.0'>Fake POS</Device>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      <EMVKernel>602</EMVKernel>

      <Gateway>JetPay</Gateway>

      </JetPay>

      <JetPayResponse Version="2.2">

      <TransactionID>201702211222450003</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST63</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QkVnYoUbQlPiRjQlQhTkXcSm</UniqueID>

      <RRN>705217004817</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      <ICC>

      <ATC>0035</ATC>

      <IssuerAuthData>472AD94F9FECD47D3030</IssuerAuthData>

      <IssuerScript2>9F180430303031860E04DA9F580903C0DC6EF04E9C8A09860E04 DA9F590908460C835744CE4E5C</IssuerScript2>

      </ICC>

      </JetPayResponse>

      The presence of the ICC data indicates that EMV chip processing has been performed; cardholder verification processing is completed.

      Note: IssuerScript1 and IssuerScript2 may occur multiple times in some instances, dependent on the card brand and issuer.


    3. . Chip and PIN Transaction Example

      image

      A so-called Chip and PIN transaction is one that includes both an EMV cryptogram and an encrypted PIN. Because an EMV chip is implemented during cardholder verification, the XML transaction gets declared as EMV type authentication (in spite of the presence of the encrypted PIN). The PIN gets included with the cryptogram in a Chip and PIN' transaction.


      Request

      Response

      <JetPay Version='2.2'>

      <TransactionType>SALE</TransactionType>

      <TerminalID>TESTMERCHANT</TerminalID>

      <TransactionID>54321SZPDFRQN67890</TransactionID>

      <Track2>;412345******2349=21121011000012345678?</Track2>

      <Origin>POS</Origin>

      <ReaderUsed>CHIP</ReaderUsed>

      <TotalAmount>1559</TotalAmount>

      <Debit Type = 'NONE'></Debit>

      <Verification>

      <ICC>

      <AIP>35433030</AIP>

      <ATC>30303138</ATC>

      <TermCapCode>453042000000</TermCapCode>

      <TVR>34303030303031383030</TVR>

      <UnpredictableNumber>433638******4141</UnpredictableNumb

      <JetPayResponse Version="2.2">

      <TransactionID>201605191242540001</TransactionID>

      <ActionCode>000</ActionCode>

      <Approval>TEST71</Approval>

      <ResponseText>APPROVED</ResponseText>

      <UniqueID>QkVhQbWoQmPnQbQlTiUhTcQh</UniqueID>

      <RRN>614017013193</RRN>

      <RawResponseCode>00</RawResponseCode>

      <CardProgram>0</CardProgram>

      <TimeStamp>2016-01-06T20:55:08Z</TimeStamp>

      <ICC>

      <ATC>0035</ATC>

      <IssuerAuthData>472AD94F9FECD47D3030</IssuerAuthData>

      <IssuerScript2>9F180430303031860E04DA9F580903C0DC6EF04E9C8A09860 E04DA9F590908460C835744CE4E5C</IssuerScript2>

      </ICC>

      </JetPayResponse>



      er>

      <TransType>00</TransType>

      <AuthorizedAmount>303030303030303030353030</Authorized Amount>

      <CardSeqNum>3031</CardSeqNum>

      <TermCountryCode>383430</TermCountryCode>

      <CurrencyCode>383430</CurrencyCode>

      <TransDate>313330393237</TransDate>

      <TransTime>313535383237</TransTime>

      <ARQC>41393335343338303532324336313743</ARQC>

      <IssuerAppData>06010103109000</IssuerAppData>

      </ICC>

      <PINBlock Encoding='HEX'>F2F9F1234A5A5A6E</PINBlock>

      <KSN>44325663749000000009</KSN>

      </Verification>

      <IndustryInfo Type='RETAIL'></IndustryInfo>

      <Application Version='4.2'>VirtPOS</Application>

      <Library Version='1.5'>VirtPOS SDK</Library>

      <EMVKernel>602</EMVKernel>

      <Device Version='1.0'>Fake POS</Device>

      <Gateway>JetPay</Gateway>

      <DeveloperID>JetPay</DeveloperID>

      </JetPay>


      image

      Remember that all PIN-based transactions require the submission of valid track data in order for the PIN to be properly decrypted. Without track data, PIN submission becomes unnecessary and the transaction is better submitted as a manually-entered credit card transaction (without a PIN).


    4. . EMV REJECT Transaction Example

A REJECT transaction is to be when the merchant, terminal, or ICC chooses to reject an approval received from JetPay.

The REJECT must happen immediately at the time of the approval, and timeliness checks for that may apply, additionally a REJECT can only be submitted using the UniqueID returned with the approval.

Currently defined REJECT ActionCodes are:

601: REJECT – EMV Chip/ICC Declined Transaction

602: REJECT – Suspected Fraud; (Such as the AVS or CVV results not being sufficient).

603: REJECT – Communications Error; (This may be useful for example with gateways, where they have lost communication with the terminal and are unable to notify it that the transaction was completed. This is also used for cases where a contact chip card was removed from the terminal during the authorization).

604: REJECT – Insufficient Approval; (For partial approvals where the approved amount is unsufficient).


The ActionCode and possible Approval returned for a REJECT are for the reverseauth done as part of the REJECT.

image

REJECT transaction request (the initial EMV transaction followed by the REJECT):

EMV Request

Response


<JetPay Version='2.2'>

<TransactionType>SALE</TransactionType>

<TerminalID>TESTMERCHANT</TerminalID>

<TransactionID>ef63c030cf1a11e498</TransactionID>

<Track2>;476173******0119=21122011758954089?</Track2>

<Origin>POS</Origin>

<ReaderUsed>CONTACTLESS CHIP</ReaderUsed>

<ReadersFailed><Reader>CHIP</Reader></ReadersFailed>

<TotalAmount>500</TotalAmount>

<IndustryInfo Type='RETAIL'></IndustryInfo>

<Verification>

<ICC>

<AIP>5C00</AIP>

<ATC>0018</ATC>

<TermCapCode>E0B000</TermCapCode>

<TVR>4000001800</TVR><UnpredictableNumber>433638******4141

</UnpredictableNumber>

<TransType>00</TransType>

<AuthorizedAmount>000000000500</AuthorizedAmount>

<CardSeqNum>01</CardSeqNum>

<TermCountryCode>840</TermCountryCode>

<CurrencyCode>840</CurrencyCode>

<TransDate>130927</TransDate>

<JetPayResponse Version="2.2">

<TransactionID>ef63c030cf1a11e498</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST31</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QnRjYiWnQnPhRkQmPnSjPkRk</UniqueID>

<RRN>510414000002</RRN>

<RawResponseCode>00</RawResponseCode>

<CardProgram>0</CardProgram>

<TimeStamp>2016-01-27T22:26:44Z</TimeStamp>

<ICC>

<ATC>0035</ATC>

<IssuerAuthData>472AD94F9FECD47D3030</IssuerAuthData>

<IssuerScript2>9F180430303031860E04DA9F580903C0DC6EF04E9C8A0 9860E04DA9F590908460C835744CE4E5C

</IssuerScript2>

</ICC>

</JetPayResponse>



<TransTime>155827</TransTime><ARQC>41393335343338303532 324336313743</ARQC>

<IssuerAppData>06010103109000</IssuerAppData>

</ICC>

</Verification>

<Application Version='4.2'>VirtPOS</Application>

<Library Version='1.5'>VirtPOS SDK</Library>

<Device Version='1.0'>Fake POS</Device>

<EMVKernel>602</EMVKetrnel

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>



REJECT for the EMV Request

Response

<JetPay Version='2.2'>

<TransactionType>REJECT</TransactionType>

<TerminalID>TESTMERCHANT</TerminalID>

<TransactionID>ef8aca36cf1a11e488</TransactionID>

<Verification>

<ICC>

<AIP>5C00</AIP>

<ATC>0018</ATC>

<TermCapCode>E0B000</TermCapCode>

<TVR>4000001800</TVR>

<UnpredictableNumber>433638******4141</UnpredictableNumber>

<TransType>00</TransType>

<AuthorizedAmount>000000000500</AuthorizedAmount>

<CardSeqNum>01</CardSeqNum>

<TermCountryCode>840</TermCountryCode>

<CurrencyCode>840</CurrencyCode>

<TransDate>130927</TransDate>

<TransTime>155827</TransTime>

<ARQC>41393335343338303532324336313743</ARQC>

<IssuerAppData>06010103109000</IssuerAppData>

</ICC>

</Verification>

<UniqueID>QnRjYiWnQnPhRkQmPnSjPkRk</UniqueID>

<ActionCode>601</ActionCode>

<Application Version='4.2'>VirtPOS</Application>

<Library Version='1.5'>VirtPOS SDK</Library>

<Device Version='1.0'>Fake POS</Device>

<EMVKernel>602</EMVKernel>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.2">

<TransactionID>ef8aca36cf1a11e488</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST14</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QnRjYiWnQnPhRkQmPnSiPkRi</UniqueID>

<RRN>510414000002</RRN>

<RawResponseCode>00</RawResponseCode>

<TimeStamp>2016-01-27T22:26:44Z</TimeStamp>

<CardProgram>0</CardProgram>

<ICC>

<ATC>0035</ATC>

<IssuerAuthData>472AD94F9FECD47D3030</IssuerAuthData>

<IssuerScript2>9F180430303031860E04DA9F580903C0DC6EF04E9C8 A09860E04DA9F590908460C835744CE4E5C

</IssuerScript2>

</ICC>

</JetPayResponse>

EMV Track 2 Request

Response

<JetPay Version='2.2'>

<TransactionType>SALE</TransactionType>

<TerminalID>TESTMERCHANT</TerminalID>

<TransactionID>ef7a3a18cf1a11e491</TransactionID>

<Track2>;476173******0119=21122011758954089?</Track2>

<Origin>POS</Origin>

<ReaderUsed>MAGNETIC STRIPE</ReaderUsed>

<ReadersFailed>

<Reader>CHIP</Reader>

</ReadersFailed>

<TotalAmount>500</TotalAmount>

<IndustryInfo Type='RETAIL'></IndustryInfo>

<Application Version='4.2'>VirtPOS</Application>

<Library Version='1.5'>VirtPOS SDK</Library>

<Device Version='1.0'>Fake POS</Device>

<EMVKernel>602</EMVKernel>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.0">

<TransactionID>ef7a3a18cf1a11e491</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST17</Approval>

<CVV2>P</CVV2>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QnRjYiWnQnPhRkQmPnSiPkRj</UniqueID>

<RRN>510415000004</RRN>

<RawResponseCode>00</RawResponseCode>

<CardProgram>0</CardProgram>

<TimeStamp>2016-01-27T22:26:44Z</TimeStamp>

</JetPayResponse>


REJECT for the EMV Track 2 Request

Response

<JetPay Version='2.2'>

<TransactionType>REJECT</TransactionType>

<TerminalID>TESTMERCHANT</TerminalID>

<TransactionID>ef9bb698cf1a11e4ba</TransactionID>

<UniqueID>QnRjYiWnQnPhRkQmPnSiPkRj</UniqueID>

<ActionCode>603</ActionCode>

<Application Version='4.2'>VirtPOS</Application>

<Library Version='1.5'>VirtPOS SDK</Library>

<Device Version='1.0'>Fake POS</Device>

<EMVKernel>602</EMVKernel>

<Gateway>JetPay</Gateway>

<DeveloperID>JetPay</DeveloperID>

</JetPay>

<JetPayResponse Version="2.0">

<TransactionID>ef9bb698cf1a11e4ba</TransactionID>

<ActionCode>000</ActionCode>

<Approval>TEST69</Approval>

<ResponseText>APPROVED</ResponseText>

<UniqueID>QnRjYiWnQnPhRkQmPnSiPkRh</UniqueID>

<RRN>510415000004</RRN>

<RawResponseCode>00</RawResponseCode>

<CardProgram>0</CardProgram>

<TimeStamp>2016-01-27T22:26:44Z</TimeStamp>

</JetPayResponse>

8. Visa Readylink (PrePaid Cards)

    1. . BALANCE (Inquiry) Transaction

      A BALANCE transaction will return the available dollar amount that is on a specific card. In a BALANCE transaction, JetPay accepts the XML transaction information, retrieves the response message from the issuer of the card and responds back to the original sender with the resulting data and the available balance.


      REQUEST

      <TransactionType>

      BALANCE

      <TerminalID>

      Terminal ID, assigned by JetPay LLC.

      <TransactionID>

      Character string, exactly eighteen characters long and preferably a unique value.

      <CardNum CardPresent>

      Manual Entry

      Valid credit card number with CardPresent value of True or False.

      <CardExpMonth>

      Credit card expiration month (two digits).

      <CardExpYear>

      Credit card expiration year (two digits).

      Track 1 or Track 2

      Swiped Entry

      The Track 1/Track 2 data gleaned from the magnetic stripe on the back of the credit card. Either Track 1 or Track 2 data is required when <ReaderUsed> is set to MAGNETIC STRIPE.

      <Origin>

      POS

      <IndustryInfo Type>

      RETAIL/RESTAURANT

      <ReaderUsed>

      MAGNETIC STRIPE or KEYPAD

      <Application>

      Identifying the system originating the transaction.

      <Device>

      Identifying the system originating the transaction.