Newbie Query on Online Payment

Hi Ciaran187, welcome to TWF

It would depend on the company's existing payment processing system, and if it has the ability to accept payments from a website.
Firstly, the store payment system would have to be online and publicly accessible for the website to be able to use, which if it isn't already, that would be a large and costly task to implement.

Most large companies keep their online accounts and sales separate from their store's accounts anyway.
For a few reasons, the main one being that online payments for a website are much easier to put through an online payment system, as both are online, such as Paypal, Google or even a system created for the store's website.

There are other reasons why online payments are different to their in store ones.
A lot of company's prices are different online to their in store prices.
It makes accounting easier in most cases, in terms of different taxes and tracking where profit/sales/expenditure is going to and coming from.

There may also be a shipping charge from the site, which their store account/payment system might not have the ability to handle (i.e. no place to store that data/price etc)

I guess it's a case by case situation, and which method being the best will depend on the store, their current system's abilities and their preferences.

Two systems I have worked with are Authorize.Net and YourPay.com, both have API's for various web languages. The API is code (usually a class), which you pass it order information (customer's info, card info, order costs, etc) and it gives you a result back as to if the transaction was approved (and then have things like a transaction id#, Authorization #) or denied (usually with detailed coded to tell why).

Most of the systems once you have an account setup, have a variable you can pass to it to let it know you are in testing mode (make sure you undo this before going live.. speaking from a bad experience...)

Another reason to have separate accounts from a retail and online store

There can be huge differences in the rates you pay between a transaction where you actually swiped the card through a reader and ones where they are just entered online (or even typed into the machine). Having the card being read indicates to them you actually had the card in hand, and less likely to be a stolen card, so they usually charge less for this.

Also, payments processed online can be more sensitive to charge backs and refunds. The worse record you get in, the more they may charge for fees or worse, especially for newer accounts, the longer they hold your funds before releasing them to you.

A note for at least Authorize.net. Even if you do a transaction that fails for something like wrong CVV code, wrong address, and/or wrong expiration date, Authorize.net will still "Authorize" the amount from the account which freezes it from being used for at a few days. I have first hand experience on this happening for the wrong address.

I used my own debit card and purposely entered the wrong address to test the error messages, and surprise to me, even though it came back declined, they still authorized the amounts on my debit card which put it in the negative. Luckily, my bank was nice and when the authorizations cleared, they refunded all the fees, and really lucky i had no other payments go out on the card.

Basically it is not to hard, most of the hoops is the client getting an account set up.

Lastly some notes: Do not store anything you shouldn't. At best, only store the last 4 digits of a credit card in case you have to reference it with a customer. YOU ARE NOT ALLOWED to store certain items, such as the CVV (the number on the back of the cards) for any reason per rules that MasterCard and Visa both have, that trickle down to you as end merchant.

-Greg