Problems with Card Swipe – Multiple Authorizations

Monday, June 13th, 2011 | FAQ, General, eAuthorize 5.0 | Comments Off

There may be two scenarios when multiple authorizations of a single card may occur:

First:
Typically the swipe and the command to send the transaction for processing are two different things. The card is swiped through the reader so the card number is be captured and appear in the correct payment field on the screen. Then, once you know you have gotten the track data off the card, you press the button to send the transaction.

Some cards are hard to read. The mag strip is warped, dirty, etc. So you may have to swipe multiple times before you get a card number to register. Other times the reader might manage to read the card info, but a problem happened causing it to not parse and appear on the screen properly.

If, on the other hand, the scripting is setup to do this all in one step, i.e. the action of swiping the card initiates the capture of the card number as well as the next step of attempting to send the transaction, it might result in multiple authorizations.

This is not recommended because it would send a transaction attempt to the gateway for every single swipe of the card. No regard would be taken into whether or not the swipe was successful and this could potentially cause multiple authorizations from multiple swipes of the card.

Second:
The card is swiped, the info goes into the right fields to show that card as the form of payment, the card is sent for authorization and it looks like no response comes back. The user then goes back to another blank payment screen, re-swipes the card and repeat the steps. In the end, two transactions appear as processed.

This scenario usually has to do with the internet connection. You have to remember that the plug-in sends the request to the gateway and then waits for the reply. The plugin is waiting for a response for as long as 30 seconds (default timeout). If you don’t get a reply, that means one of two things. First, that the transaction never made it to the gateway. Or second, that the transaction made it to the gateway but you didn’t get the reply because of some issue with the network between you and the gateway.

In the second scenario it’s possible that you can have a transaction go through and you don’t see the response on your screen and don’t know it processed.

A connectivity issue can sometimes be indicated by a long wait before the timeout. And there is little that our plugin can do to combat a loss in network connectivity once the transaction attempt is underway. If the plugin can’t see the network at all and can’t reach the gateway it will usually error quite quickly, but you will still see a plugin generated response message “Error – no result obtained.

Can you submit a batch of transactions using eAuthorize?

Wednesday, May 4th, 2011 | FAQ, General, eAuthorize 5.0 | Comments Off

This is a yes and no type answer. eAuthorize does not support a batch upload of a single file containing multiple transaction requests for the gateway to process. Receiving reporting back on the success or failure of the transaction is part of the problem when doing a batch upload. There is no way built into the plugin to make this possible.

However, if you have a group of transactions in your database that you wish to run, you could consider using a looping script in FileMaker to execute the transactions one after another. This way, each transaction would be handled individually by the plugin, the results would be brought back into your FM database, and the “batch” would be processed after the loop completed going through each transaction.

We do know of a number of clients that are using such a looping method with success. It also has the advantage of allowing the logic in your database to execute for each transaction based on the result. If the transaction is successful, you can proceed with order fulfillment and so forth. If the transaction is denied, you can flag the account for follow up.

Using eAuthorize with Terminal Server

Wednesday, January 26th, 2011 | FAQ, General, eAuthorize 5.0 | Comments Off

Several of our clients have reported that they are running the eAuthorize plugin in a terminal server environment. Our plugin runs inside of FileMaker, so if FileMaker is supported in this configuration, then our plugin should be as well.

If the terminal server is where the FileMaker Pro is installed, where the plugin is installed, and where the eauthorize license is being read from, then you may have another problem to contend with. Every user that loads FileMaker will also be loading and registering the plugin every time they open FileMaker Pro. A single user license in this configuration will not know how to work only for the one user that requires it.

There is a solution, however, that will allow you to use a single user license code. I would recommend that your developer look into the documentation that is included with our plugin download. The documentation folder has a ‘how to register’ text file and it explains a method of registration where the registration code is passed to the plugin by using a function call to the plugin itself. This way a script can be run that calls the plugin to register it. Then limit this script so that it is run on the login for any users that are allowed to run credit card authorizations. Anyone else that logs in to your database will not try registering the plugin that way. This would allow you to have a single user license and make sure it’s only being used by the individual that needs it.

Authorize.net New MasterCard and Discover Processing Requirements – Update

Thursday, May 20th, 2010 | FAQ, General, eAuthorize 5.0 | Comments Off

Recently, users of Authorize.net where notified of changes to the gateway prompted by MasterCard and Discover modifying their rules concerning the processing of debit, prepaid and gift cards.

We have been researching the impact of these changes on the eAuthorize plug-in and have determined that a modification will be required to keep the plug-in compliant. We have begun the process of updating the plug-in and expect release of eAuthorize 5.2 in September. Pricing for this upgrade has yet to be determined.

There are a few important things to note regarding these changes:

1- Simply installing the updated version of the eAuthorize plug-in will not automatically make your FileMaker database solution compliant with these changes. Some modification to the scripting in your database will be required to support the Balance Response, Partial Authorization and Authorization Reversal transactions outlined by Authorize.net

2- There is a danger that older versions of the eAuthorize plug-in will not continue to work after Authorize.net enforces these changes on June 30, 2011. To avoid this you should update to the latest version of the plug-in prior to that date.

3- If you are currently using eAuthorize 3.x or 4.x on Mac, you must be running FileMaker version 7 or later to upgrade to the 5.x version of eAuthorize. If you are still running FileMaker 6 or earlier on Mac, you will need to migrate your database to a later version of FileMaker to continue using the plug-in.

4- For more information on these changes please see the FAQ at Authorize.net

Check this space periodically for updates. New information will be posted when it becomes available.

eAuthorize 5.1 compatible with FileMaker 11

Monday, April 12th, 2010 | FAQ, General, eAuthorize 5.0 | Comments Off

WorqSmart is pleased to announce that we have tested eAuthorize 5.1 and can confirm that it is compatible with FileMaker 11.

eAuthorize 4 not compatible with FileMaker 11

Monday, April 12th, 2010 | eAuthorize 3.5, eAuthorize 4.0, eAuthorize 5.0 | Comments Off

We have recently gotten several reports of eAuthorize 4 not working with FileMaker 11 on the Mac OS.  After our own testing, we have found this to be the case.  While eAuthorize 4 appears in the preferences list, you will receive the error message that the plug-in can not be enabled.

The resolution to this problem is to upgrade from eAuthorize 4 to eAuthorize 5.1.

Registration Errors/Permission Errors

Tuesday, February 16th, 2010 | Events 3.0, Events 4.0, Events 4.5, FAQ, eAuthorize 3.5, eAuthorize 4.0, eAuthorize 5.0 | Comments Off

Registering your plug-in by entering your license information in the plug-in configuration screen will sometimes fail due to permission issues (i.e. forgets the registration or cannot create registration) file on the installation computer. When this happens, typically it can be resolved by logging in with an account that has administrative permissions and then conducting the registration.

However, in cases of a networked computing environment that uses centralized authentication and application servers, there can still be problems with the permissions that prevent the plugin from storing and retrieving the necessary license info. The best resolution in such a case it to register the plug-in by using the plug-in’s built in registration function call.

From a startup script in your database, simply call the plug-in with the registration function and pass the necessary license code parameters. That way every time the database is opened the plug-in will be automatically registered.

Tags: , , , , ,

Does data transfer via eAuthorize automatically or does it require a user interface?

Monday, February 8th, 2010 | FAQ, eAuthorize 3.5, eAuthorize 4.0, eAuthorize 5.0 | Comments Off

It doesn’t require that you login to any interface on the payment gateway. You never have to leave your database to conduct the charge. You can fully integrate it into your database so you can pull up the record that contains the card info you wish to charge and press a button to execute a FileMaker script that will do the payment processing … instantly and without you ever having to leave your database.

Is the information sent via eAuthorize more secure, encrypted?

Monday, February 8th, 2010 | FAQ, eAuthorize 3.5, eAuthorize 4.0, eAuthorize 5.0 | Comments Off

The information is transferred to the payment gateway over a standard Internet connection. The entire transfer is done using encryption to provide security as the credit card information and response is sent and received.

We currently pass credit card data to the payment gateway via an import file. How is eAuthorize different, can it help us?

Monday, February 8th, 2010 | FAQ, eAuthorize 3.5, eAuthorize 4.0, eAuthorize 5.0 | Comments Off

If you are currently exporting your transactions from your database in a file, uploading that specially formatted file to a payment processor, and then the processor is running the transactions, eAuthorize can help

The advantage of eAuthorize is that it will send the transaction straight from the database to the gateway, and eAuthorize will be able to receive an immediate response back from the payment gateway as to whether the charge was approved or not. So, it’s instantaneous and it allows the scripting in the database to check the result of the charge so different things can be done depending on the result of the charge request. These are things you can’t do when you’re batch processing them via an upload file.

Cart

Post Categories

Post Archives