Installation
Step 1 – Install the module

    Simply unzip PreAuth.zip in your application directory.  All the files contained within are named with the prefix Pre-.  There shouldn’t be any problems with overwriting one of your existing files.  If you run into that, try to rename your existing file rather than the module file.

Step 2 – Add a Preauthorization button

    The preauthorization is normally done right after the first items are rung and before it is stored.  For the Table Service application, the best place to put this button is on the Server control page.

      1. Create a button labeled Preauthorize Credit Card and give it the following command:

          Chain to Pre-Init

          This chain initializes the preauthorization variables, draws the initial screen, and starts the KBMSR utility that will read the swipe of the credit card.
         
      2. Add the TraPr:PreAuthAmt variable to the screen with some text that might say something like Pre Authorized For: so the user knows if a check already has a preauthorization and, if so, how much.

Step 3 – Check for Preauthorization when Tendering

    When it is time to tender the check, the application needs to screen the check for a preauthorization and take it to a separate Tender page if applicable.  This should be done after any pretender housekeeping commands and prior to bringing up the Tender page.

      1. In the Table application this is done through the CloseChk chain.  Insert the command

                Chain to: Pre-Scrn
      2. This command brings up the Pre-Tendr control page.  The buttons at the top match those on the Table application’s Tender control page.  If styled into a different application, you may need to change these buttons to match.

Operation

Preauthorizing a credit card is a very straightforward process.  Start a new check or recall an existing check and press the Preauthorize Credit Card button.  The screens for swiping the card or entering the information manually look identical to the regular authorization pages.  The module will verify TraPr is running, then wait for a result.  The user will be informed the result and given a choice whether to store or modify the check.

When the Close Check button is pressed, the module checks for a preauthorization and if it exists reroutes the order flow to a special Tender control page.  This page allows the user to apply an actual amount to the credit card, or cancel the preauthorization and tender it through the regular Tender page.
Technical

A preauthorization request is essentially a standard authorization request which is not added immediately to the batch.  Instead, preauthorization information is kept within the PreAuthFIFO.dat file located in the TraPr folder.  When TraPr receives the TraPr:PreAuth Complete command from Touchnet, the authorization with the final amount is added to the batch.

As with a standard authorization, a preauthorization reserves a portion of the credit to be used as payment for the vendor.  If no authorization is sent through, that portion will remain reserved for several days before it is released by the bank for use with another vendor.  For that reason, preauthorization should be done judiciously.  The styling module prevents the user from retransmitting a preauthorization on a check that already has a preauthorization.  TraPr does support sending additional preauthorizations which replace the original preauthorization.  However, the stylist needs to be aware that the bank will treat replaced preauthorizations as unreconciled ones, and leave that amount reserved and unavailable to the customer for several days.