Page 1 of 1
How do I create an Internet Payment Gateway System?
Posted: Mon Apr 23, 2007 9:02 am
by php_ghost
Here's the scenario:
I've been a web programmer for just about more than 4 months now. My boss want's me to create a Payment Gateway System. We will provide our clients, Online Processing services. We will act like the POS terminal between the e-commerce sites and the bank. E-Commerce Site --> Our Company --> Acquiring Bank.
What do I have to do to create this system? What are the processes involved? This system will be used/integrated to our clients' websites.
Btw. we are applying for a merchant account to become a licensed Third Party Processor.
Thanks and more Power!

Posted: Mon Apr 23, 2007 9:17 am
by feyd
If and when you pass all of the credit card companies often inform you of the needs and requirements. Generally around here we suggest using a third party processing supplier as it pushes the liability for the transaction safety and security to them.
Posted: Mon Apr 23, 2007 9:24 am
by php_ghost
but my boss wants our company to become the third party processor as well.
Posted: Mon Apr 23, 2007 9:28 am
by feyd
Then you guys need to be aware of all the added security that you will need because you will be storing sensitive financial information. The credit card companies can fill you in on some of those details.
Posted: Mon Apr 23, 2007 9:40 am
by php_ghost
If we use a third party processor, do we still get clients and offer them payment processing?
Can someone give me a clearer picture on what a payment gateway and payment processor is? are they different? will the process be completed without the other?
Google and wiki doesn't really help this time so I'm seeking answer from developers who have encountered these kinds of projects before. TIA again.
Posted: Mon Apr 23, 2007 9:41 am
by php_ghost
hmmm ok let's skip the security part first.
About the system that I need to develop, is it possible to do this without the merchant account yet?
Posted: Mon Apr 23, 2007 10:48 am
by onion2k
php_ghost wrote:hmmm ok let's skip the security part first.
Security is the most important aspect of the thing you're suggesting. Everything else is unimportant in comparison. You need to consider security at every single point during the production of the system.
php_ghost wrote:About the system that I need to develop, is it possible to do this without the merchant account yet?
The merchant account? Only one? Aren't you writing something to enable thousands of sites to connect to thousands of different merchant accounts?
I have two bits of advice for you:
1. Tell your boss that the creating a system to do this is far too complicated for 1 person.
2. Quit. Your boss is a moron.
Posted: Mon Apr 23, 2007 10:52 am
by John Cartwright
If you have to ask, you shouldn't be doing it
People would be essentially trusting you with very
important financial information, and if compromised would seek your head. Lawsuits anyone?
Why bother putting the burden on your own company when there are other companies that specialize as payment gateways.
Posted: Mon Apr 23, 2007 11:15 am
by JayBird
I always quote something like this when i client asks me something about payment processing. Scares them enough to back down.
from another thread wrote:First, there is the risk of compromise in transit. To properly protect against that possibility, we need to use SSL on our site, which will encrypt the data in transit.
Next, there is the risk of compromise locally (on the server). To properly protect against that possibility, we need to encrypt the data. Since we need to pull it back up for reprocessing in the future, it will have to be a method that allows decryption.
Since we are allowing decryption from the server in realtime, we have to assume an attacker that compromises the server can do so as well. As such, we need to reduce the likelihood of the server being compromised. That means external audits of our security, a dedicated server, physically secured, tight access controls (including account limitations - no logging in as root/Administrator), and more.
Even then, if the system is compromised, the data is still at risk, so I need insurance that covers loss of customer data. The loss of customer data in some jurisdictions is covered by extremely specific legislation that in some cases requires customer notification within 48 hours of breach - so I will probably need a lawyer to clarify my responsibilities.
All of this leads me to the simple conclusion that its not worth all of THAT to allow customers to not have to type in their CC info.
Better, I could use PayPal, or Google Purchase to allow them to still do so, without any additional risk for me."
Posted: Mon Apr 23, 2007 12:12 pm
by Burrito
if you're actually going to be setting up a payment gateway, you'll have tough row to hoe.
my suggestion would be to utilize existing gateways (like authorize.net) and do the credit card processing from your server. Each of your clients will have to have their own merchant accounts set up as well as their own unique gateways to plug into those merchant accounts.
using authorize.net, you can use the advanced integration method (AIM) to process transactions from your server. To set up your own payment gateway, you'll have to go through a very rigorous audit process and establish accounts with the different banks to process VISA, MASTERCARD etc...a very lengthy process that would be more work than it's worth. There's no point in re-inventing the wheel when you don't need to.
Posted: Tue Apr 24, 2007 12:41 am
by php_ghost
Ok guys thanks for all your feedbacks.
Yeah I really think this is too complicated for one person especially an inexperienced person like me.
So let me change the question.
What does our company need and/or what do I need to develop in order for our company to offer Online Payment Processing for other websites?
I'm asking you this guys because google really can't help me.
Posted: Tue Apr 24, 2007 8:25 am
by onion2k
php_ghost wrote:So let me change the question.
What does our company need and/or what do I need to develop in order for our company to offer Online Payment Processing for other websites?
I'm asking you this guys because google really can't help me.
You'll need (very roughly, having spent about 15 seconds thinking about it, so there's probably more required):
1. Secure links to different card companies. There may be a centralised system for this already.
2. An incredibly secure data centre.
3. A top notch security expert capable of designing a system that's secure.
4. A secure database system with security audit tracking throughout.
5. Some security conscious developers capable of writing secure code.
6. A secure procedure for allowing people to integrate the secure code into their websites securely.
There's a theme here; see if you can spot it.
Posted: Tue Apr 24, 2007 8:27 am
by feyd
Also.... don't underestimate the importance of insurance covering your liability in this situation. If there's a leak of the information, it will cost you guys dearly if you don't have insurance to protect against it.
Posted: Tue Apr 24, 2007 8:37 am
by php_ghost
@onion2k
If we offer online payment processing for other websites what is our company called? is it a payment gateway or a credit card processor or what?
@feyd
Yep about those insurance stuff I think I have to tell it to my boss too. Thanks
^_^
Posted: Tue Apr 24, 2007 8:40 am
by onion2k
php_ghost wrote:@onion2k
If we offer online payment processing for other websites what is our company called? is it a payment gateway or a credit card processor or what?
You can call it what you want. EPDQ call themselves a "merchant services provider", SecPay call themselves a "credit card processing gateway", StreamLine are something else. You'd need to think up a name that you think describes what you do. That's really a problem for your marketing guys though.