Can I implement a payment feature in my own software?

Question

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:

1. A cashier takes an order from a customer, who then hands over their card to pay for the products
2. My software gets the card's data when it is swiped through a card swipe connected to the computer
3. 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?

Answer 1

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

Answer 2

The good news : This is not particularly technicaly hard to do.

The bad news : Your bank has to trust you. There are various credit card frauds which you could commit or be committed via you, so without a history if proceesing transactions your bank will be wary and charge you a higher rate.

Techincally. You need a merchant accout with your bank. Your bank will provide you with (sell you) apis and possibly hardware which will enable you to take credit card payments. This will cover all cards that the bank accepts

Often there is a hardware aspect to this with smart cards and registered users etc, but its not difficult to set up automatic processing. You will also have to set up reconcilliation of the payments with your bank statement. This can often involve a manual interaction when things dont add up.

Payments can be refunded by your bank and this may only become clear on your statement.

Dont expect your banks api to be overly helpfull or modern!

Your bank will charge you a fixed amount per transaction and/or a percentage of the amount. This amount will be based on how long you have been trading and the volume of transactions you process. It could well be higher than what 3rd parties offer you.

Your bank will want to audit any systems that are used to process payments. You may have to send web Page designs etc to them for approval.

You will have to be PCI compliant. There are various levels of auditing and self certification.

These are some of the reasons people opt for third party payment processing.

However, we shouldnt be too negative about doing it yourself. After all this is what 90% of shops on the street do, get a merchant account and some chip'n'pin machines and off they go!

Answer 3

THis answer is certainly not what you expect, but managing payment transactions natively in your software won't be a piece of cake. Let's be honest: it can hardly be done as a personal side project.

First, forget about the idea of swiping a card and let your software ask for the PIN and compare it to what is stored on the magnetic stripe. That is a an obsolete technology about to die. The credit cards are more and more smartcards, in which the PIN is encrypted on the chip. This is not yet mainsream in US (40% of consumers only have one) but credit card companies are actively pushing in that direction because it helps to reduce fraud. In many European countries you can't hardly find a credit card without a chip.

Fortunately there is a widely accepted dominant standard: EMV.

The major credit card companies are also implementing a liability shift to the merchant in case of fraudulent transactions, if their POS doesn't implement EMV. This means that if the system uses the magnetic stripe of a chip card, and this card proves to be a fake, the merchant won't recover his money. This will be a strong incentive for them to acquire EMV compliant systems.

Finally, payment systems is a very dynamic area. For instance, contactless payment become popular and offer a different workflow. Last but not least, the mobile payment is also an emerging technology.

If you operate a company with sufficient developers you can certainly make all this in your software. But if it's only an accessory of your core function, better subcontract this part to specialized actors and take benefit of their APIs/webservices and knowledge.

Answer 4

If you want to interface your software with ONE bank - they won't like that at all. They have no interest in supporting some bit player. And that would be ONE bank. You want to be able to play with any bank that any of your customer is using.

What you need is to interface your software with the software of a payment provider. A payment provider is capable of turning a credit card or debit card number into money in your account. No matter whose bank is involved.

The payment provider will want to know that you can be trusted. Like if I order an item for $12.95, then you need to be trusted not to charge me $1295.00, because if you do and run away with the money, the payment provider will have to pay for it. You must be trusted to not store my credit card number. And you must be trusted to be secure and keep hackers out. That's the real hard part, convincing people that you can be trusted to get money from my bank card.

Apart from that, they have an API. You will use the API. They will also have a contract, and they will take that contract very, very, VERY seriously. If they find out that you store credit card numbers, you're kicked out and most likely blacklisted. If they find out that you charge people money when you shouldn't, you are in even more trouble.