Credit Card Payments/Gateways

phiber

Expert Member
Joined
Dec 7, 2005
Messages
4,303
Hi All, I am busy building an online service and I would like to take credit card payments. I am not keen to offload to another site, but would rather have the payment done on my site. In order to do this I understand I need the following:

Compliance with PCI DSS
An agreement with a card payment originator (payu, paygate etc). - Cost here is approx R1.50/R2.00 per transaction
A card acquiring account with a bank - Cost here is 3-5% of the transaction

My dilemma is I want to flatten the fee per transaction to a set rand amount rather than a variable % of the transaction fee (my business model suits a fixed fee structure).

Is there any way to get around paying a variable fee to banks, and go with a fixed price solution somewhere? I will take some time to go chat to banks as well to see what solution they offer, just hoping some has got an idea of some products that might be able to help me.
 

Se@n

Senior Member
Joined
Sep 30, 2013
Messages
951
AFAIK merchant account fees / discount are always going to be percentage based. Worked in the mobile acquiring space and as far as i remember even for our clients with large transaction volume/low transaction value a percentage was still charged. May be wrong though, a few years ago, chat to the banks.
 

phiber

Expert Member
Joined
Dec 7, 2005
Messages
4,303
Thanks Se@n, I have spoken to a few banks on the phone, and it is all percentage based. Need to see them to get a more definite figure on what that percentage would be, ranges from 3 to 10% it seems (quite steep and not very feasible for small businesses). I am hoping Capitec come in cheaper.
 

MagicDude4Eva

Banned
Joined
Apr 2, 2008
Messages
6,479
I would honestly look at Payfast and avoid doing your own PCI compliance. Depending on the number of transactions and volume, your PCI compliance audit costs can become quite steep. Also remember that depending on PCI level you will not be able to use shared/virtual hosting and would have to go as far as getting your own lockable rack. Unless you are trying to become a payment gateway, I would not try and process myself...
 

AdrianH

Expert Member
Joined
Feb 27, 2005
Messages
3,222
From a technical development point of view, we used SetCom for our debit and credit card payments on our website as it allowed us to build the payments into our site and not redirect to a payment gateway. For the most part they are stable and we have hardly any issues. That said, on 2 occasions they merely went ahead and changed their API and return codes which caused issues for a couple hours, but overall I am pleased with the service.
 

phiber

Expert Member
Joined
Dec 7, 2005
Messages
4,303
From a technical development point of view, we used SetCom for our debit and credit card payments on our website as it allowed us to build the payments into our site and not redirect to a payment gateway. For the most part they are stable and we have hardly any issues. That said, on 2 occasions they merely went ahead and changed their API and return codes which caused issues for a couple hours, but overall I am pleased with the service.

Cool, thanks Adrian. have you done your own PCI compliance? I have spoken to a few of the gateways, and if I want to do payments on my site, they say I need PCI compliance. This looks like a viable alternative.

Tx MagicDude4Eva, will look into it, do they let you build your own payments page? I am looking to build this into an app, so its not an option to offload to a payment gateway and redirect. Not keen to touch or embed the browser, it just isn't clean enough.
 

AdrianH

Expert Member
Joined
Feb 27, 2005
Messages
3,222
Cool, thanks Adrian. have you done your own PCI compliance? I have spoken to a few of the gateways, and if I want to do payments on my site, they say I need PCI compliance. This looks like a viable alternative.

Sorry for only replying now. We do not store any credit card info at all so PCI wasn't required. We send SetCom our reference number during the payment process and then they return with a transaction/authorization number. With that we can match our order with the actual payment.
 

AdrianH

Expert Member
Joined
Feb 27, 2005
Messages
3,222
I'd avoid DIYing this tbh....some headaches should rather be outsourced.

Any reason why? When you say outsource, do you mean the entire integration into my backend or just the acquiring portion?

We are moving over from our own capturing forms into "hosted" payment portal for the simple reason that 3D Secure is being forced on the 28th February 2014. As we don't store credit card details, its just makes more sense for us to integrate and use SetCom's "hosted" forms as they handle the process from start to finish on their website. We just initiate the process with a HTTP Post, and have to handle call backs to our website with the transaction results by a redirect and HTTP Post. Just made more sense to us to offload this whole process.
 

phiber

Expert Member
Joined
Dec 7, 2005
Messages
4,303
We are moving over from our own capturing forms into "hosted" payment portal for the simple reason that 3D Secure is being forced on the 28th February 2014. As we don't store credit card details, its just makes more sense for us to integrate and use SetCom's "hosted" forms as they handle the process from start to finish on their website. We just initiate the process with a HTTP Post, and have to handle call backs to our website with the transaction results by a redirect and HTTP Post. Just made more sense to us to offload this whole process.

It definitely makes sense to offload, but it breaks the entire User experience that I am going for.
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
15,199
We have built our own payment platform and collections platform, we had to register as part of PASA and also do the compliance. You're better off using an existing product. You are in for some very nice costs.

A lot of payment providers are willing to give you volume discount, but you will have to give them viable proof that you will anticipate those volumes. But no provider will give you a discount on say 1,000 transactions a month. Our one product has a minimum threshold of at least 50,000 transactions a month before any form of discount starts.

Another option:

https://developer.paypal.com/webapps/developer/docs/classic/products/payflow-pro/


But in all fairness people are very skeptical with regards to new systems wanting credit card details. Your users will feel safer knowing you use paypal or another redirected payments provider. I myself hate entering my details into github for example, it just feels so insecure. Just stay away from paymate, their platform is shocking.

Also if people dont want to use a credit card, and you want to support naedo you could just do a PAAF collection (Payment against available funds).

Considering you are a startup the viability of you writing compliant payments engine is very far fetched (sorry), you will need to integrate into various banks that in itself is costly, standard bank with direct connect starts at 100K, ABSA at around 20+- you then need permanent servers with diginet connections or hosted in a secure server farm, then there is services fees for codes on various switches such as bankserv.

Maybe accept bitcoins?

A payment gateway and a payment processor are two different things. A payment gateway, like Authorize.Net, allows a website or software to send payment information to a payment processor to process the payment. The payment processor does the actual handling of the payment (e.g. checks to see if funds are available on the card, is it approved, AVS, CVV verification, etc).

To get a relationship with Visa and MasterCard you need to become a Member Service Provider (MSP) and Independent Sales Organization (ISO). This costs about $10,000 up front and then $5,000 a year if you are approved. A background check and review is involved. This is done by your sponsoring bank, which you also have to find.

To build a payment gateway you have a lot of work ahead of you. This isn't a project you would write with a language like PHP. You would need to use a higher level language such as C or C++. Something compiled that will be much faster and more robust then PHP. You can power your web based front end with PHP (i.e. user control panel) but the backend stuff, including payment processing, will need to be in the higher level language. You'll also need an enterprise level database as open source databases could never handle a task like this. Basically you're looking at using an Oracle database which is expensive but also designed for this sort of thing.

Your first major issue will be PCI DSS compliance. You will have to secure your system from top to bottom with regular compliance checks. This is a lot more difficult then it sounds. And expensive, too.

Your second major issue will be getting certified by the processing networks. To be a successful payment gateway you must be certified on every processing platform and there are at least 16 of them that I can think of off of the top of my head. Being certified takes about two months for each. You can do them simultaneously but you would be looking at at least a year to be certified on all of them. And each one has a different API so you will need to code your payment gateway to work with all of them.

Your third major issue will be the data you store. Not only do you have the PCI DSS issues to deal with, but you will need to capture and store every transaction that runs through your system for years. That kind of data will require tons of storage space (that will also need to be secured).

Your fourth major issue will be processing volume. A gateway must be able to perform transactions in a second or less. This means your hardware solutions must be able to scale for heavy traffic especially over the holiday season. It will need to be able to handle hundreds of transactions per second (thousands if you become successful). That is a big reason why you'll need to use a higher level language over PHP.

Your fifth major issue is that you will need to create a powerful yet easy to use API for web developers to use to connect to your payment gateway. They need to be able to do everything a credit card terminal can do through code. Documenting that should be fun! ;)

Minor issues include:

Making sure you are ECI compliant (Electronic Commerce Indicator is required for all Internet transactions)

Securing all data transfer (SSL)

Offering a user control panel

If you want to be successful you will also need to have anti-fraud tools available

Building a payment processor is an even more herculean task. It will require relationships with banks (a friend just went through this process for their new venture and it took over a year just to get a bank to agree to work with them). I suspect it will require you having a lot of money set aside to deal with potential processing issues that result in your customers being owed money. I'm talking at least six figures.

The technical stuff would be at least as complex as building a payment gateway. You'll need to be interfacing with banks. Lots of them. And your uptime must be 100%. I have not been this deep in the technical aspects of it all so I can't give you anything more specific then that.

The payment gateway is a huge project but doable. It becomes easier if you limit the networks it will work with. Maybe stick to the most popular to start and go from there. A better idea might be to partner with a processing bank and sell merchant accounts through them. Then make your payment gateway work only for them at first. Then you can launch quicker and also make money on the credit card processing. The payment processor part is huge and probably beyond the scope of what you want to do. If not, it's a huge undertaking that goes way beyond a handful of programmers. You're gonna need lawyers, too.

I suspect you wont go this route ;)
 
Last edited:

phiber

Expert Member
Joined
Dec 7, 2005
Messages
4,303
Thanks for the post... We are probably going to go through paypal or the like. Bitcoin isn't viable as the user base is not very tech savvy, hence the need for a user interface that is as simple as possible.

Looking into the paypal in app option, going to have one of my front end developers mock it up.

Not too worried about complex back end code, my business partner works for a bank writing quite a complex banking solution - pretty confident he can manage, it just time we don't currently have.



We have built our own payment platform and collections platform, we had to register as part of PASA and also do the compliance. You're better off using an existing product. You are in for some very nice costs.

A lot of payment providers are willing to give you volume discount, but you will have to give them viable proof that you will anticipate those volumes. But no provider will give you a discount on say 1,000 transactions a month. Our one product has a minimum threshold of at least 50,000 transactions a month before any form of discount starts.

Another option:

https://developer.paypal.com/webapps/developer/docs/classic/products/payflow-pro/


But in all fairness people are very skeptical with regards to new systems wanting credit card details. Your users will feel safer knowing you use paypal or another redirected payments provider. I myself hate entering my details into github for example, it just feels so insecure. Just stay away from paymate, their platform is shocking.

Also if people dont want to use a credit card, and you want to support naedo you could just do a PAAF collection (Payment against available funds).

Considering you are a startup the viability of you writing compliant payments engine is very far fetched (sorry), you will need to integrate into various banks that in itself is costly, standard bank with direct connect starts at 100K, ABSA at around 20+- you then need permanent servers with diginet connections or hosted in a secure server farm, then there is services fees for codes on various switches such as bankserv.

Maybe accept bitcoins?



I suspect you wont go this route ;)
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
15,199
Not too worried about complex back end code, my business partner works for a bank writing quite a complex banking solution - pretty confident he can manage, it just time we don't currently have.

Its not just as simple as writing a backend. There is an entire wide range of algorithms (that don't fall under the banking sphere) that need to be in place.

So yes your best bet is paypal, it works, its tried, its tested. Nothing wrong with it.
 

AdrianH

Expert Member
Joined
Feb 27, 2005
Messages
3,222
Thanks for the post... We are probably going to go through paypal or the like. Bitcoin isn't viable as the user base is not very tech savvy, hence the need for a user interface that is as simple as possible.

Looking into the paypal in app option, going to have one of my front end developers mock it up.

Not too worried about complex back end code, my business partner works for a bank writing quite a complex banking solution - pretty confident he can manage, it just time we don't currently have.

Why not give SetCom a call. As I said previously, we originally used their server to server integration model which means you write your own front-end and keep your UI and your users never have to leave your application/website when making a payment. You have the choice of keeping the credit card details on your side which means you will have to be PCI complaint, or let SetCom handle that and you keep track of the transaction details only. I don't know the costs and transaction % costs, sorry.

I dealt with a lady named Rabia.

PS: I don't work for SetCom, just have experience with them since 2008.
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
15,199
Why not give SetCom a call. As I said previously, we originally used their server to server integration model which means you write your own front-end and keep your UI and your users never have to leave your application/website when making a payment. You have the choice of keeping the credit card details on your side which means you will have to be PCI complaint, or let SetCom handle that and you keep track of the transaction details only. I don't know the costs and transaction % costs, sorry.

I dealt with a lady named Rabia.

PS: I don't work for SetCom, just have experience with them since 2008.

Or he can just use paypal, and not have down time ;)
 

phiber

Expert Member
Joined
Dec 7, 2005
Messages
4,303
PayPal looks great but ends up being quite pricey. 2.4%-3.4% + R3 per transaction as well as 1.5% to FNB to withdraw the money as rand. That's about 50 bucks on a R1000 transaction, just in fees. ZAR is also not an accepted currency on PayPal thus putting us at Risk to the USD.

Going to contact SetCom as today, see what they can do for us.
 

phiber

Expert Member
Joined
Dec 7, 2005
Messages
4,303
How many transactions are you anticipating?

About a hundred a month when we launch, but the product can scale based on market take on.

Taken a look at Setcom, looks really good - developers are making sure they can integrate, but I don't foresee any issues there.
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
15,199
About a hundred a month when we launch, but the product can scale based on market take on.

Taken a look at Setcom, looks really good - developers are making sure they can integrate, but I don't foresee any issues there.

Ah okay, i was going to see if we could tailor a package. But ye 100 is not entirely feasible. We need a starting point of around 20,000.
 
Top