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.
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?