Software Downloads

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 Compatible devices page.

Release notes for v1.69

• Support of the Ingenico Self/3000 unattended device for Hosted. This device supports credit only, No CVM, chip, contactless and swipe.
• Whitelist BIN range 100000-199999 for IDTech VP3300. The whitelist is loaded during an EMVParamDownload.
• For PAX devices for Return transactions, added 0xCB tag to EMVBeginContactTxn to trigger a Full EMV flow. Coupled with PAX PxRetailer version 2.00.45 or above, causes the EMVContinueContactTxn to perform properly allowing for PIN entry and a response with all EMV tags. A Full EMV flow is important for Returns since they now go online to the card issuer.
• For PAX insertion reader devices (A60, Aries6, Aries8), using PxRetailer 2.00.47 and above, turns off MSR "inserted" and "removed" statuses allowing for a much more reliable magstripe read. PAX provided a new system variable – PXR.MSRHYBIRD, allowing these statuses to be turned off.
• Support for <FSAWithLookup> amount for EMVSale transactions allowing FSA/HSA chip cards to be processed successfully. This feature is supported for Hosted only and currently only when the backend processor is Rapid Connect. For an EMVSale transaction, the integrator can pass in the amount of FSA eligible items in a new tag <FSAWithLookup>. The gateway will use a BIN lookup to determine if the card presented is an FSA or HSA card. If it is, the TranCode will be changed from EMVSale to EMVFSASale and the <FSAWithLookup> amount will replace the <Purchase> amount. All other amounts will be removed. The Rapid Connect MM NETePay now supports the TranCode EMVFSASale. If the card is not an FSA or HSA card, then the transaction will be sent for processing unchanged. The integrator can also send any of the optional FSA amounts for prescription, dental, vision, or clinical. The integrator should inspect the TranCode returned and the amount authorized.
• Support for EMVSaleWithSplit transactions. EMVSaleWithSplit is a new transaction (new TranCode) supported for Hosted. This transaction is expected to be used in the government space where a cardholder pays a utility bill in person and is also charged a separate fee to a separate service organization. It provides a way to process a normal EMV Sale transaction along with a separate, second transaction for a "split fee" amount. New request fields include <SplitMerchantID1>, <SplitFee1> and <CustomAmountFormat>. The <SplitMerchantID1> is the Hosted Merchant ID value that should be used to process the split fee payment. <SplitFee1> is the amount of the split fee payment. <CustomAmountFormat> is a field that contains a display message to be shown to the cardholder on a PAX PIN pad showing the amount of the EMVSale and the amount of the split fee. An EMVSaleWithSplit example is below. The receipt print data is for the primary transaction. There is currently no print data produced for the secondary "split" transaction. The primary transaction is processed with the card data collected from the cardholder. The secondary transaction is processed with manual card data from a token.

The value of the <CustomAmountFormat> tag maps to a variable contained in the latest PAX forms package. dsiEMVUS checks the PAX forms package version to know if the variable exists before populating the variable for amount confirmation and when displaying the form to collect card data (Please Insert, Swipe or Tap Card). The <CustomAmountFormat> tag includes the following predefined elements …

1. #PAYMENT# - The amount of the payment (Purchase + Gratuity + Cash Back).
2. #N# - A new line.
3. #FEE1# - The amount of SplitFee1.

An example of the CustomAmountFormat sent on an EMVSaleWithSplit is …

• <CustomAmountFormat>Payment Amount: $#PAYMENT##N#Fee Amount: $#FEE1#</CustomAmountFormat>

An example of the CustomAmountFormat sent on an EMVSale is …

• <CustomAmountFormat>Sale Amount: $#PAYMENT#</CustomAmountFormat>

For an EMVSaleWithSplit transaction, it is very important for the ISV to supply the CustomAmountFormat tag that includes both #PAYMENT# and #FEE1#.

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.88

• For PAX insertion reader devices (A60, Aries6, Aries8), using PxRetailer 2.00.47 and above, turns off MSR "inserted" and "removed" statuses allowing for a much more reliable magstripe read. PAX provided a new system variable – PXR.MSRHYBIRD, allowing these statuses to be turned off.
• For the latest PAX forms package, the STR.AMOUNT_TEXT variable is cleared when displaying the “swipe screen”.
• If an ISV performs a SecureDevice Init for the IDTech VP3300, then the whitelist BIN range 100000-199999 is loaded.

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

1/5/23 - New DSIClient test application released to remove username from the usertrace field.