Mercury Payments TRANSENTRY
      Back to home
      1. INTERNAL - Bepoz Help Guides
      2. Interfaces | EFTPOS & Payments
      3. Mercury Payments TRANSENTRY

      1 | TRANSENTRY Software Setup

      This article covers Mercury Payments TRANSENTRY System commonly used in USA for Debit and Credit Card Authorisations and also details the type of users who can operate the system. TRANSENTRY is a Windows based system that will provide all the user screens and communication with Mercury Payments for Credit and Debit Card Authorizations. You must firstly install the TRANSENTRY software on each Windows POS that needs to communicate with Mercury Payments.

      This article covers Mercury Payments TRANSENTRY System commonly used in USA for Debit and Credit Card Authorisations and also details the type of users who can operate the system.

      TRANSENTRY is a Windows based system that will provide all the user screens and communication with Mercury Payments for Credit and Debit Card Authorizations. You must firstly install the TRANSENTRY software on each Windows POS that needs to communicate with Mercury Payments.

      See the Standard TRANSENTRY documentation for configuring the TRANSENTRY software and connected hardware.

      EFTPOS Options

      • The EFTPOS (Card Authorisation) key has a few flags available in the Override Maps. This enables you to have different Card Payment keys setup

      EFTPOS Tender Button iSubItem Options

      • ForcePreAuth = 1
      • ForceSale = 2
      • ForceDebit = 4
      • ForceDebit & Sale = 6
      • ForceVoiceAuth = 8

      Other Functions

      • In Override maps there is an "EFTPOS Method" function. This allows for EFTPOS interface specific functions to be performed from within the Tills
      • For TranSentry only the Button Item field is used. Below are the functions that can be accessed from a Till Override Button

      EFTPOS Method Button iSubItem Options

      • UserSelection = 0(This displays a list of the below functions to select from)
      • Reprint Merchant Copy = 1
      • Reprint Customer Copy = 2

      EFTPOS Void/ Reversal

      • TranSentry supports Voiding Card Authorisations. There are 2 main ways this is done, Void/Reversal and Returns
      • A reversal must be done in the current batch. By default, the Interface will attempt a Reversal and if that fails, it will try a Void. Alternatively, you can process it as a Return

      EFTPOS Void/ Reversal Button iSubItem Options

      • ForceReturn = 1 

      PCI PA DSS Compliance

      • To use the Mercury TranSentry Card Payment system, BEpoz must be PA DSS Compliant. As not all BEpoz systems will need to use a Linked Payment System, there is a Venue Flag to turn PA DSS on and off
      • Note: There is a separate document outlining the full PA DSS Requirements for an installation that MUST be givern to the merchant
      • Once this flag is on the following will be enforced throughout BEpoz: 
      • An operator who can do the following is deemed as an Administrative User
        • Create or delete users
        • Access to user account security screens
        • Do Password resets or account lockout resets
        • Access to payment processing configuration screens
        • Access to delete the logs if such a function is available
        • Do Creation and deletion of system level objects
      • Whereas, an Operator who can do Card Authorisation Payments (Operator Flag) is deemed as a Basic User

      Basic User

      • Must have a password – no complexity required though
      • Must login using Number & Password or use card,RFID or Biometric reader

      Administrator User

      • Must login using Number & Password or use card,RFID or Biometric reader
      • Passwords must contain both numeric and alphabetic characters
      • Passwords must have a minimum length of seven characters
      • Passwords must be changed every 90 days
      • Passwords cannot be the same as the prior four passwords
      • Six consecutive incorrect passwords submitted for a user login results in that user account being "locked out." During account lockout, not even the correct password can grant them access
      • Locked out accounts must remain locked out for at least 30 minutes or until another administrator resets the lockout
      • If the user is idle (no activity has been performed by that user) for 15 minutes within Operator or Device maintenance lists or screens, those screens will be automatically closed


      • All Passwords are stored using MD5 encryption
      • There is extra logging of all login events
      • Users will have to either use biometric reader login or enter their password at the POS