Hosted Payments ID Tech Augusta KB EMV Overview

Document created by on Mar 27, 2018Last modified by on Nov 13, 2019
Version 7Show Document
  • View in full screen mode


This document contains information on processing ID Tech Augusta KB device EMV transactions via the Hosted Payments solution on the Express payment platform.  Note that this device supports Credit Card transactions only (no PIN Debit).  The use of Cascading Style Sheets with Hosted Payments is also available, and details regarding this type of implementation are discussed later in this document.


The Augusta KB device can only be used with Express/Vantiv integrations at this time.  No other gateway processors are supported.


Hosted Payments Transaction Types Supported using ID Tech Augusta


Express Method














    • Only Swiped and EMV Insert Credit Card transactions are supported.  Keyed and PIN Debit transactions are NOT supported.
    • Hosted Payments does not support unlinked refund transactions (i.e. CreditCardCredit) due to security risks involved with that transaction type.
    • Hosted Payments does not support Check/ACH processing because Check/ACH data does not fall under PCI scope.
    • The Hosted Payments page can be displayed in a number of different ways, including a full-page redirect, an iFrame, a popup, etc.
    • The Hosted Payments page can be displayed in an embedded or non-embedded format.  Refer to the TransactionSetup method in the interface specification for additional details.
    • If TransactionQuery (using the TransactionSetupID) is utilized to obtain additional transaction details immediately following a Hosted Payments transaction, please note that there may be more than one transaction associated with a single TransactionSetupID (such as both a Decline and Approval received during the single Hosted Payments session). Because of this, during the TransactionQuery, integrators should review the appropriate TransactionType and approval response to obtain transaction details regarding the successful Hosted Payments transaction.
    • Through the use of the Boolean AddressEditAllowed input parameter within the TransactionSetup method Address node (XML interface only), both the standard Hosted Payments page (Non-Embedded only) and the mobile Hosted Payments page (Non-Embedded only) can allow the individual entering the card information to edit the Billing Address details prior to submission to Express.  This is supported for card-present and card-not-present transactions, regardless of whether or not the Billing Address information is initially submitted in TransactionSetup.  Set AddressEditAllowed to “1” to allow users to edit the Billing Address details directly on the Hosted Payments page, and set AddressEditAllowed to “0” (or leave out entirely) if no Billing Address edits are allowed.
    • Because the Augusta KB device does not collect cardholder signatures, merchants should collect cardholder signatures (if applicable) in the same manner they are collected with any other non-signature capture device.


Helpful Links (basic Hosted Payments flow)



Hosted Payments ID Tech Augusta EMV Chip/Magstripe Reader Sample Flows


Single Sale Transaction using ID Tech Augusta EMV Chip/Magstripe Reader

  1. Your application collects the non-sensitive transaction details such as amount, transaction type, and address information where necessary, and submits a programmatic request using the TransactionSetup method in the interface specification (e.g. TransactionSetupMethod of 1/CreditCardSale for a single sale transaction).  When the Augusta reader is used, a TerminalCapabilityCode of 6 (ChipReader) should be included in the TransactionSetup request.  AutoReturn must be set to 1 (True) in all scenarios.
    • For EMV Insert, Swiped, or Keyed support in Hosted Payments:
      • Set TerminalCapabilityCode to 6 (ChipReader)
      • Set CardInputCode to 0 (UseDefault)
      • Set DeviceInputCode to 0 (NotUsed)
    • For only EMV Insert or Swiped support in Hosted Payments ("waiting for input" icon):
      • Set TerminalCapabilityCode to 6 (ChipReader)
      • Set CardInputCode to 0 (UseDefault)
      • Set DeviceInputCode to 2 (Terminal)
    • Note that Hosted Payments explicitly sets the CardInputCode value submitted to Express based on the entry mode used by the cardholder.
  2. Element responds with a TransactionSetupID (a GUID) if the request was successful.
  3. Your application performs a redirect (embedded browser control, full, popup, or iFrame, etc.) to our Hosted Payments URL and appends the TransactionSetupID to the end of that URL. For example, it might be:
  4. The end user inserts (if using an EMV chip card) or swipes (if using a non-EMV card) the card on the reader and the encrypted data output will flow into the Hosted Payments text box. If the EMV card cannot be read by the device, the Hosted Payments page will request the user to swipe the card. Once the insert or swipe data is parsed by Hosted Payments, the user can click the Submit button. Be aware that for any card-reader-in-progress timeout scenarios, the Augusta may take up to 30 seconds to provide a timeout response. When in a situation where the cardholder/merchant has unsuccessfully interacted with the reader, and they no longer wish to proceed, the Hosted Payments page should not be closed until the reader is back in an idle state.
  5. Element redirects the response details to the ReturnURL you originally provided in your initial TransactionSetup request from the first step (we append the response details in name/value pairs to the end of your ReturnURL). If using the embedded browser control, the Navigation URL in the object contains the response values that can be parsed. If the transaction was declined, pressing the Cancel Transaction button will redirect declined transaction details (and EMV tags) to the ReturnURL provided in the original TransactionSetup request.
  6. Your application receives the URL and parses out the response details, which you can then display on your own page/application. If processed as an EMV transaction, the EMV tags associated with the transaction will be included in the ReturnURL in a Tag/Length/Value (TLV) format to be parsed by the calling application for EMV receipt-printing purposes.


Use of Embedded and AutoReturn parameters with ID Tech Augusta

  • Integrators may use the Embedded (1) or Non-Embedded (0) option during the XML TransactionSetup request.
  • Integrators can ONLY use the AutoReturn option set to True (1) during the XML TransactionSetup request. An AutoReturn value set to False (0) will not support the return of EMV data.


ID Tech Augusta EMV Chip/Card Reader Troubleshooting



Insert LED

Small LED





Solid Blue


Device is idle and waiting for insert or swipe.

Insert Valid Chip Card

Solid Blue, then flashing Blue (success and remove card)

Solid Blue, then flashes Green, then flashing Blue (success and remove card)

2 short beeps, then continuous long beeps indicating card can be removed

EMV insert was successful.

Insert Invalid Chip Card

Flashing Blue

Flashing Red

Continuous short beeps

Device cannot read the inserted card.  Hosted Payments will display fallback message of “Unable to read input. Insert card again or swipe.”  Retry or fall back to swipe (within 30 seconds or timeout).



Flashing Green


Device is in EMV fallback mode.  Swipe card.

Insert Valid Chip Card

Solid Blue

Solid Blue


Chip card may have been removed too early.  Insert chip card again.  If the reader beeps twice and returns an error, retry the transaction.



Flashes Red 3 times

1 beep

Device could not read the swipe attempt.  Retry.

Swipe Chip Card

Flashing Blue

Flashing Red

No beep

Chip card was swiped.  Please insert card instead (within 30 seconds or timeout).

Insert Invalid Chip Card

Flashing Blue back to N/A

Flashing Red back to Solid Blue

Long beep

Device cannot read chip card after 4 attempts.  Transaction is cancelled.  Retry using another card or fall back to swipe.


ID Tech Augusta EMV/Chip Card Reader ReturnURL Response Parameters

When the ID Tech Augusta reader is used to process an EMV transaction, the EMV tag information used for the transaction is returned in a Tag-Length-Value (TLV) format in the EmvData response field. To view an example of the parsing of TLV EMV tags, integrators can visit A full list of EMV tags is available at Integrators must be able to parse this TLV format for the purpose of printing the necessary EMV tags on the cardholder transaction receipt (for both approvals and declines). Refer to EMV Tags-Augusta Receipt Printing Purposes.xlsx from Developer Integrations team for EMV tags to display on receipts.


Below is an example of a raw ReturnURL containing EMV tag data (with EMV Data parameter and tag data in red).


Additional Parsing Option (to be used only if ReturnURL data is corrupt/unavailable)

In the event that the EMV tag data returned in the ReturnURL query string value from Hosted Payments, the Express platform supports the ability to utilize the programmatic XML TransactionQuery method with the ReceiptEMVData input field set to 1 in the request (example request/response below).  Please note, though, that the ReceiptEMVData returned may not contain all necessary approval and/or decline EMV tags to be printed/displayed on cardholder receipts.


<TransactionQuery xmlns="">


- <TransactionQueryResponse xmlns="">
- <Response>
- <ReportingData>
- <Items>
- <Item>
<Name>Merchant Name</Name>