The Fuzzy Lines of Setting Up Financial Transactions on Web Sites

There’s a fuzzy line in the scope of online payments that web developers often have to explain to clients for any site that takes such payments. For purposes of this discussion, I’m not referring to ACH payments, which are a different kettle of fish.

Actually there are two lines. One is who does what. The web developer is often responsible for creating a secure purchasing area where the web site’s customers can make online purchases in a way that works with the client’s financial institution(s).   But it’s really only the first step of the transaction journey.

The other line is WHAT does what, in terms of software and electronic transactions.

The client sets up the payment gateway.  There is almost always a payment gateway. Payment gateways include PayPal, Stripe, Authorize.net, etc. The payment gateway takes the transaction data from the web site software and determines whether the transaction information provided, such as credit card number, address, name, etc., is legitimate. If NOT legitimate, it will fail the transaction, and often provide that information back to the web site’s secure purchasing software. The payment gateway is set up by the client, as it has sensitive financial institution account information.

If it IS legitimate, it then goes on to the client’s financial institution, and again is usually communicated back to the web site software as well.

The point of this article is to specify responsibility for each piece IF you contract with a web development firm. A contracted web development firm should not set up a payment gateway for you, but may need some access to information within the payment gateway account to set up the online shopping environment. The web development firm’s job is to set up the software on the site that interacts with the payment gateway. To those who have not dealt with payment gateways this may seem like the same thing, but it is not.

The client is responsible for the Payment Gateway.  This means going forward as well.  Payment Gateways, like everything else on the Internet, is subject to change for competitive purposes as well as security purposes.  It may require the client to notify the web developer if there’s a software change.  Clients should pay attention to alerts and notifications sent by their Payment Gateway provider.

Before you choose a Payment Gateway, it is best to determine what web site software you plan to use to run transactions. This can be based on the content management system you may be using for the site, or the functionality of the shopping cart and account software. Most shopping cart software packages can work with many – but not all – payment gateways. So this should be coordinated first.

Back in the old days of the web, financial institutions would limit account holders to a specific payment gateway, which turned this software determination process around. This has loosened up in the past several years and most will allow at least a few which should provide you with plenty of options for your shopping cart software selection.

This can sound intimidating, but once someone has dealt with a payment gateway (I hesitantly include PayPal in that group because there’s some quirky things there) it becomes fairly comfortable quickly.