Please follow the steps below to complete your installation of NETePay Monetary - Host Server - MTR 5.07.34 Rental

Step 1 - Install Client Control

In order to communicate with this NETePay your POS may use one of the following ActiveX controls depending on the integration method chosen by the POS developer. If you are unsure of which to install please contact POS technical support.

dsiEMVUS® 1.53

Release date: 03/22/2021

Datacap’s out-of-scope ActiveX control for NETePay supporting a variety of EMV-enabled hardware options.

For information on supported devices please see our PC based POS solutions page.

Release notes for v1.53

  • Support is added for the following IDTech devices via USB/HID. The VID/PID values are the same between VP3300 and VP8300 devices.
    • VP3300 for TSYS
    • VP8300 for TSYS
    • VP3300 for EVO with TDES DUKPT PAN encryption
    • VP8300 for EVO with TDES DUKPT PAN encryption
    • VP8300 for Mercury with TDES DUKPT PAN encryption
    • VP8300 for Datacap Hosted with TDES DUKPT PAN encryption
    • VP8300 for Monetary with TDES DUKPT PAN encryption
  • For IDTech devices with PAN encryption, the masked card data is now masked with zeroes rather than asterisks or any other character. This change allows IDTech transactions to be stored using Store and Forward.
  • Support is added for Tetra LANE devices for Global Payments.
  • When Calling "ProcessEasyCheckout", if "<MsgPump>Allow</MsgPump>") is included in the XML request:
    • The ocx will create a new thread to process the connection to EZCheckout and mainatain the windows message pump on the calling thread.
    • Depending on the software design this may be needed.
      • A single threaded integrator (since by definition the ocx is in the GUI thread) will not be able to process windows messages, therefore the new function of sending a windows message reporting progress will never be delivered to the caller.
      • A multithreaded integrator who uses the OCX in a separate thread only blocks that thread and he is fine AS LONG AS he follows the rules and never calls across the thread boundary to the OCX(this could lock the entire POS).
      • A multithreaded integrator who uses the OCX in the GUI thread can process his background stuff in the other threads. Windows messages will still be blocked in the calling thread, but he can steer messages to any thread with a (window and) message pump, so he can use this as he sees fit. This can lead to a nicer GUI experience for the cashier depending on how much control the integrator wants to give the human being.
Microsoft Windows 10 Pro / 8 Pro / 7 Pro / Vista Pro / XP Pro

OR

dsiPDCX® 1.73

Release date: 03/22/2021

Datacap’s out-of-scope ActiveX control for NETePay and GIFTePay software that supports dozens of plug and play hardware options, including PIN Pads, Mag stripe readers, all-in-one touch terminals and contactless readers.

Release notes for v1.73

  • Support is added for the following IDTech devices via USB/HID. The VID/PID values are the same between VP3300 and VP8300 devices.
    • VP3300 with clear card data
    • VP8300 with clear card data
    • VP3300 for EVO with TDES DUKPT PAN encryption
    • VP8300 for EVO with TDES DUKPT PAN encryption
    • VP8300 for Mercury with TDES DUKPT PAN encryption
    • VP8300 for Datacap Hosted with TDES DUKPT PAN encryption
    • VP8300 for Monetary with TDES DUKPT PAN encryption
  • For IDTech devices with PAN encryption, the masked card data is now masked with zeroes rather than asterisks or any other character. This change allows IDTech transactions to be stored using Store and Forward.
Microsoft Windows 10 Pro / 8 Pro / 7 Pro / Vista Pro / XP Pro

OR

DSIClientX® 3.86

Release date: 09/01/2011

Datacap’s long-standing in-scope ActiveX control for NETePay and GIFTePay software.

Microsoft Windows 10 Pro / 8 Pro / 7 Pro / Vista Pro / XP Pro
Step 2 - Install Administrative tools (optional)
Local Batch Report Viewer

Release date: 05/11/2020

Local Batch Report Viewer can be used to view the locally stored batch report of Host based NETePay who support support this feature and have it enabled via PSCS.

Release notes for v1.03

  • Fix for an issue which prevented errors from the open batch being shown in the decline/error tab.
Microsoft Windows 10 Pro / 8 Pro / 7 Pro / Vista Pro / XP Pro
Step 3 - Install NETePay Monetary - Host Server - MTR 5.07.34 Rental

This NETePay is available via the NETePay 5 Director which provides a simplified installation process and go-forward automatic software updates. NETePay 5 Director is recommended but if needed the classic installation process is still available by clicking Download as usual.

To learn more about the NETePay 5 Director click here.

Release date: 01/10/2019

This version supports a new Local Batch Inquiry feature. This allows an ISV to programmatically retrieve transaction data from the Local Batch Reporting tables. When using Store and Forward, it provides an easy way to review transaction data for declines which translate directly to merchant losses. The Local Batch Inquiry feature include two new TranCodes – BatchReportQuery and BatchReportTransaction. These are both <Admin> functions. The Local Batch database contains two tables, BATCH and DECLINE. The BATCH table contains all approved transactions. The DECLINE table contains all declines and errors.

  • The following are optional XML fields for BatchReportQuery
    • <TransDateTimeBegin>
    • <TransDateTimeEnd>
    • <CmdStatus>
    • <SAFOnly>

For <TransDateTimeBegin> and <TransDateTimeEnd>, a date range may be supplied with or without times. Valid formats are “YYYY-MM-DD” or “YYYY-MM-DD HH:MM:SS”. If these tags are not supplied, today’s date is assumed.

For <CmdStatus>, valid values are “Approve”, “Decline” or “All”. Use “Approve” to retrieve data from the BATCH table. Use “Decline” to retrieve data from the DECLINE table. Use “All” to retrieve data from both tables. If this tag is not supplied, “Decline” is the default.

For <SAFOnly>, valid values are “Yes”, “No”, or “All”. Use “Yes” to retrieve data only for transactions that were stored and forwarded. Use “No” to retrieve data only for transactions that were not stored. Use “All” to retrieve data for all transactions whether stored or not. If this tag is not supplied, “Yes” is the default.

Using all defaults, the BatchReportQuery will return transaction IDs for today’s stored transactions that were declined when forwarded. Transaction data returned for BatchReportQuery include <IdNo#> to uniquely identify each transaction, where # is a numeric value. Other response fields include …

  • <InvoiceNo#>
  • <Status#> - Approved, Declined, or Error
  • <TransDateTime#>
  • <IsSAF#> - Yes or No

Using the <IdNo#> value, the BatchReportTransaction can be used to retrieve the detail information for the specific transaction. The value is sent in the <IdNo> tag. Transaction data returned for BatchReportTransaction include values from the BATCH or DECLINE table …

  • <IsSAF> - Yes or No
  • <Status> - A, X, V, Declined, Error
  • <TranCode>
  • <CardType>
  • <AcctNo> - truncated showing last 4 digits
  • <ExpDate> - truncated
  • <AccountSource> Swiped, Keyed, etc.
  • <Purchase> - Purchase amount
  • <Authorize> - Authorized amount
  • <AuthCode>
  • <RefNo>
  • <TransDateTime>
  • <InvoiceNo>

Integration documentation will be updated in the near future to include full examples with all XML fields. These new Admin functions can be implemented via DSIClientX or dsiPDCX. No cardholder data is collected since these are Admin functions.

New build released 1/29/19 - Change to store and forward logic which will allow PreAuth/EMVPreAuth transactions to be captured even if stored records exceed the maximum time length. This prevents a situation where PreAuth/EMVPreAuth transactions must be captured prior to forwarding but can't be

Microsoft Windows 10 Pro / 8 Pro / 7 Pro (Windows XP and Vista do not support TLS 1.2 which is now an industry requirement)