Note:
I spent some time thinking about this question before choosing which StackExchance site to post it on. I have decided on this domain because of the description: "For professional programmers interested in conceptual questions about software development". I am not looking for an implementation, I am only looking into the concept of accepting credit/debit card transactions. I did not go to a site dedicated to the discussion of law, business, or startups, because at this time I am not considering the legal issues. If you believe that I have placed this question in the wrong site, please leave a comment explaining why and where you think it belongs before flagging.
Thanks!
What I am considering is the following:
Is it possible to implement a credit/debit card payment processing system in my software?
I am currently working on a personal side project which is a point of sale(POS) software that you would possibly find running on a cashier's or waiter's computer.
A use-case to describe what I am looking for:
- A cashier takes an order from a customer, who then hands over their card to pay for the products
- My software gets the card's data when it is swiped through a card swipe connected to the computer
- The data is sent in a request somewhere for authorization, perhaps to the acquirer(my bank) or perhaps to a third-party company who processes transactions for a fee
I am certain that steps 1 and 2 can be relatively easily implemented, but I am not sure if step 3 is possible. That is the only part I am concerned about as of now. Before beginning development on this project, I would like to focus solely on the feasibility of accepting credit/debit card transactions.
I would not like to move forward unless I can accept credit and debit cards from the major card companies and banks.
What I am NOT looking for:
I do not want to use paypal or an online site that takes users to their portal to process payments. Since I am developing a POS system, all interaction with the computer should be limited to inside my software. A customer should not have to provide any information other than a card, and either a PIN or signature – remember the customer won't ever see the screen.
What I've found so far:
To be able to accept credit or debit card transactions, a store or, merchant, must have a merchant account. This is an account which is set up to accept requests for authorization from a the accound holder (the merchant). The merchant submits a request to the merchant account (the acquirer) then the acquirer queries the issuer (the card company of the customer) who then will respond with an authorization code if the card owner has enough valid credit for the purchase. The acquirer then sends the result back to the account owner (the merchant).
I read that to accept transactions from customers without the use of any third-party software, your software must be evaluated and pass extremely strict security standards. I've also read that there are third party companies that process payments so your software doesn't have to meet these rigid standards.
This information may not have been correct, and I may not have understood the transaction process correctly.
From these conclusions I have come up with the following questions:
Questions on not using a third-party company
- If you can just set up a merchant account and start sending requests, why not do that? I don't see a need for a third-party.
- Would the implementation be different for each merchant bank?
- Would these merchant banks all require their own set of security standards?
- Does this method still allow you to accept transactions from other banks or even other countries?
Questions on using a third-party company
- When using these theoretical third-party companies, do they provide API's to integrate the transaction process into your own software?
- Or, do they provide you with some software that you then customize to meet your needs?
- Can you just send an amount and some CC info to these companies and they handle the rest?
- How could this be more secure (or any different) than sending the request to the acquirer with your own software?
- Could this work with most merchant accounts?
Other general questions
- Are any of my conclusions about processing CC transactions incorrect?
Besides the payment transactions, I still like the idea of building a POS software that is very user friendly, customizable, robust, and that doesn't look as terrible as some of the ones I've seen. But, with payment processing being such a large portion of what the merchant needs…
- do you think a merchant would ever consider buying a POS software that itself used a another software to process transactions?
Best Answer
You have asked for a great deal of information, but I'll try to summarize the whole process as much as possible.
You can definitely build your own merchant processing software. Quite a few companies have done that (these are a few of them: WorldPay, PayPal, BluePay, National Bankcard, etc.). Most of them can process card payments (for a fee) very quickly. I would expect all of them to have an API to that will allow you to submit purchase information. I would also expect all of them to process refunds (which you haven't mentioned).
You can build your own going through your own acquirer, but most banks (especially the small ones) don't have the knowledge base to take any information you have collected for billing through an internet connection. And even when they do, they don't want to get into the business of clearing credit cards (this is the term the banks use when they talk about processing billions of credit card and other transactions).
One of the main reasons to use a merchant processor is to not have to create an interface with each and every bank out there that issues cards, including international banks. Yes, each bank will have its own set of rules that vary slightly for both processing and security.
When you start processing international banking transactions (anywhere in the world outside your country), then you start getting into legal requirements, up to and including treaties. Speaking of legal issues with banking (which processing credit cards falls under legally), you would also have to check with each nation's version of the "Do Not Sell" list. Here is the US list.
For your last question (about companies purchasing software that uses 3rd party software for processing credit card), you probably find a few that may balk at the idea. My experience has been that most of the companies (at least in the US) expect some level of 3rd party software in what they buy. Very few companies have the resources to be experts at everything...