I'm looking to build an online store and would like to know how to handle the credit card transactions, from a developers point of view.
January 3, 2011 10:34 PM   Subscribe

I'm looking to build an online store and would like to know how to handle the credit card transactions, from a developers point of view.


Well I'm a developer, but I've never actually connected a site to any type of payment system. I assumed there's services for this and I have vague knowledge of how that type of stuff usually works. I'll also be googling and researching myself, but if anyone has the 'things everyone should know' type of info that might help me get started... I'd really appreciate it!

What I would like is to create my site in PHP and MySQL. This would be for personal small business, such as selling arts and crafts.

I'd like to have as much control over the credit card transactions, but obviously there is a layer I'm not likely to control, which is the part the credit card is verified and money is transfered.

How does this work?

I assume there is some 'broker', basically some service somewhere I sign up with, and they supply me with some connection info.

I assume I can write my PHP and add the form, which is sent to some predetermined host IP, which handles the credit card transaction. I'd like to code as much myself, not relying on 3rd party unless it's diving into the bank's territory.

Ideally, I'd like to have something that can deposit into my personal bank account.

For instance, I want to create a test site right now, with just a field for credit card #, security code, name, zip code, etc. I want to put my own credit card number in for some test amount, say $10, and ideally, see it show up in my bank account.

I'm guessing it's not that simple ;P

I'm guessing I would also need to use a SSL service to encrypt the info.

I see small business all the time using some credit card processing, usually I see the little logo or link somewhere on the page, but I'm wondering, is there something I have more control over?

I want to use as little unnecessary middlemen... But would rather learn it myself unless it's too complex.

Does anyone create their own sites in this manner and control your own credit card processing?

Any help or info is much appreciated. Also any good links to getting started on this. I know it's a big topic, but I like diving in so any info is of help. Thank you!!!
posted by Like its 1997 to Computers & Internet (24 answers total) 19 users marked this as a favorite

You don't want to control credit card processing. Trust me.
posted by quadog at 11:04 PM on January 3, 2011

I think you're better off using something like Yahoo.

If you want to see an example of a store which uses their services, try this one. They have their own URL and you won't see any Yahoo cruft on the site. But it's hosted on a Yahoo server, and all the credit card transactions are handled by Yahoo.

Dealing with that kind of thing yourself is very risky. If there's any leak at all, you could be liable for boucoups damages.
posted by Chocolate Pickle at 11:05 PM on January 3, 2011

You don't want to be in the pci-dss audit end of things, use a 3rd party.
posted by iamabot at 11:11 PM on January 3, 2011 [1 favorite]

Check out a service such as Authorize.net. The actual code and integration is easy, it can be as simple as a form post with a redirect back to your site when the payment is processed. Setting up the account is tbe hassle.
posted by wongcorgi at 11:38 PM on January 3, 2011

Things everyone should know about doing this on your own: don't. Seriously, don't. The middlemen in this case are not unnecessary. If this is an area that really interests you, try to get a job with one of the existing companies in the space.

Things you personally should know: if you are having problems installing Wordpress themes, writing a credit card processing back end is not the next project you should be taking on. Baby steps, walk before you run, etc.
posted by hades at 11:52 PM on January 3, 2011

Response by poster: Thanks ok I agree haha.

But, for real.. I have worked for big projects before, in a professional setting.

I'm just extremely d-i-y in nature and so I like doing these things on my own for interest of self-learning and knowing the nuts and bolts, but I do eventually use things built by those dedicated to it fulltime.

It's just that I like "knowing" what THEY are doing because it allows me to know when I'm being screwed or not. Ya know??

But thanks... Trust me I been doing web work since 95 and I realized 95% of what I did was actually VERY simple yet those type of things only 'some' people realized. The rest are business school grads managing us hehehe.. j/k.
posted by Like its 1997 at 12:34 AM on January 4, 2011

Response by poster: And hades.. I was actually just being VERY lazy in asking for help on that, because, some problems are the type that are not due to being technically insufficient rather things like... If I coded my site so you had to know to type .2352xxyy in order for it to work, you wouldn't know right? And would need to ask? But that doesn't mean you don't know technical stuff....

posted by Like its 1997 at 12:37 AM on January 4, 2011

Related on Stackoverflow: 1, 2
posted by benzenedream at 1:30 AM on January 4, 2011

This is the service we used for a while in a point-of-sales application: tender-retail.com. I don't know if they would work for you, but worth a look, I suppose.
posted by converge at 3:01 AM on January 4, 2011

Yeah... integration with authorize.net or any similar service isn't that hard, at least from a technical point of view. You're basically just posting xml to their API via soap... or maybe they do JSON these days. At any rate, there are tons of code examples you can look at. No idea what their costs are like at all.... but yeah, I'm told setup can be a hassle.

That said, I wouldn't necessarily rule out Paypal as a payment gateway. There are a number of fairly sophisticated things you can do with their API and whatnot... just kinda depends on your needs.

Maybe you should just start clicking on those links and seeing what the various merchants describe, see if that meets your needs.
posted by ph00dz at 4:45 AM on January 4, 2011

foxycart is worth a look too.
posted by backwards guitar at 5:09 AM on January 4, 2011

Generally, if you screw up your word press theme, you won't end up in court. I'm not sure that's the case for credit card processing. I'd go with paypal or google check out, personally.
posted by empath at 5:52 AM on January 4, 2011

Yes, read all the PCI DSS documentation, that's what your merchant account and payment gateway (e.g., authorize.net) are going to require that you comply with. I've done it and it's not a weekend hobby sort of thing.
posted by Brian Puccio at 6:13 AM on January 4, 2011

Just did this at work using PayPal's payment gateway.
Here are some sites we found helpful:
paypal specific
posted by rmless at 6:45 AM on January 4, 2011

I have created an online store in PHP/MySQL from scratch, including credit card payments. We stopped doing business that way, so I don't have a site to show you -- just take my word for it :)

You need a "transaction gateway" to perform website CC transactions: your server performs a request to their server, and their server does all of the high-level credit card transactions. This is often separate from your 'merchant account'. The merchant account is how the money gets moved around; the transaction gateway is how your server tells the merchant account to move the money.

My gateway was e-onlinedata, and I didn't have any problems with them. I don't recall who my merchant account was, but they recommended e-onlinedata. e-onlinedata provided the API documentation for how to connect to their gateway. They even had some custom plugins for common carts and a shim for quick custom cart development. I made mine from scratch. Pretty much the short of it was that my PHP performed a SOAP-like HTTP GET request to e-onlinedata's servers, who responded with a delimited string, which my PHP broke up and used to determine if it was accepted/declined, what the authorization code was, if the address validated, etc., etc. It's pretty much just fill-in-the-blank stuff: you send this data, you get this data in return.

That, however, is the easiest part: you have to get data to send to the gateway first. Integrate credit card check-digit validation. Manage billing address versus shipping address so that you have a good address to send to the credit card gateway for verification. Verify that the expiration date is a valid date AND is in the future.

The gateway will have a "sandbox" setting for testing -- you send it data, you tell it how to respond, and you can make sure your scripts work but without running real transactions.

Then, lastly, you need to make sure you are PCI compliant. While I was tightly secured, my server logs were full of attempted SQL exploits and other attacks of people trying to get credit card data from my stores. If you have a homebrew store, you have to do your own PCI compliance, or pay somebody else to do so.

As far as development goes, there's nothing particularly difficult here -- 99% of the work is just accepting, validating, and responding to user-entered data. The gateway's API is the only special knowledge, and they're helpful about it. Still, PayPal is the way I'd go if I were to do it all over again -- they make things easy and they're a trusted source, plus it would have been easier to integrate PayPal sales in with credit card sales.
posted by AzraelBrown at 7:33 AM on January 4, 2011

thirding authorize.net and/or e-onlinedata -- don't reinvent this wheel
posted by omnidrew at 8:17 AM on January 4, 2011

When I first read your question, I thought of Braintree because (as they say), "We ♥ Developers." (Full disclosure: I have a relative who works there -- still, I just thought it would be another option for you to consider.)
posted by Zephyrial at 9:57 AM on January 4, 2011

A quick overview of the steps. I've done this in ruby myself.

1) Get a merchant account. It's basically a bank account connected to a credit card processor. You can't do this on your own, and banks make it a pain in the ass since they are "loaning" you the money in the account until the chargeback period is over. So they are tight about handing these out. The bank will take a cut here, nothing you can do except negotiate.

2) Get a payment gateway. This is a web service like Authorize.net (but there are dozens of other ones) that converts internet traffic into credit card network traffic. The gateway will take a cut, deal.

3) Get a SSL certificate. Set it up right. Understand what it does and doesn't protect (just over-the-wire from User to You)

4) Setup a form, collect the data, send it up to Authorize.net, get money.

5) Secure the heck out of your server. A gimpy shared host will have more security holes than a properly secured (public/private key logins, alt port ssh, patched) private host. You're making money, you can spend a bit more on hosting.

Note #1:

Never ever store the CC number. It never touches the hard drive, or the logs, or the database. You simply never need to store it. Every payment gateway has a storage mechanism where you hand them all the data you just collected, and they give you a unique ID number. Store that unique ID in your database, and you can then have "access" to the CC number later without ever being able to get at that data. This alone gets you past most of the CC handling rules, since you never store it. Be very vigilant that it never hits disk, logs are easy to screw up.

Note #1.5

Don't echo the credit card number back to a mis-entered form. So when I forget expiration date, and you re-show the form, have a hidden field saying "already_entered_number = true", and a masked version of the CC (value = "XXXX-XXXX-XXXX-1234").

Note #1.6

That reminds me, watch for leaky sessions. Remember, for security reasons, you never want to let a CC hit the disk. Sessions often hit the disk. Might wanna watch out for that.

Note #2:

Getting the workflow and error messages right is surprisingly annoying. Not hard as such, just lots of different error cases, with lots of different messages, and data to keep track of, and.... and....

Recurring subscriptions are even more annoying. Lean on your payment gateway as hard as possible to do the work for you.


Re: Paypal - they have several layers of fanciness. Their medium level may be enough for you. Their high end is equivalent to Authorize.net (requiring a merchant acct and everything).

Re: Others - I like braintree, but I've never had a chance to actually use them. Well documented API.
posted by cschneid at 10:58 AM on January 4, 2011 [1 favorite]

Response by poster: Thank you all for the great info!! Yes, it's a plethora of a topic I need to dive into, but I just wanted to narrow down some of my options and this definitely helps.

I guess I was being a bit naive but I'm sure you guys are used to that ;P

I would want control over the things I can control, such as the shopping cart and all the UI, the look and feel, etc.

I just don't care for visiting sites and feeling like I'm leaving their site once I add to shopping carts... Gives it that 'untrusting feel'.

I realize I don't even know about the hosting options yet as I'm using some hosting that doesn't offer SSL, so that is a whole nutha' topic... sigh.

I was hoping I can use my El-cheopo hosting to set up some test pages, passing it over to the merchant accounts that would take care of all the compliance/security and leave it transparent. So I'm guessing that's what paypals/authorize.net/google etc would be doing.

One last 'basic' question. If I do use those services, at bare minimum, must I find a new hosting service offering SSL?

It's difficult doing this when I'm not even sure how reliable our 'product' is as I'm sort of testing the water... hoping just to get something up that allows a few of our 'friends' to buy online, before we even THINK about selling to the public.

Thank you all once again!!
posted by Like its 1997 at 4:41 PM on January 4, 2011

I don't think you're understanding. A lot of us gave good starting points and cschneid spelled out a lot for you. You claim you don't want people leaving a site to go to a shopping card because it gives an "untrusting feel" ergo you want people on your site and your site only entering their payment information. You must SSL this. Authorize.net or any other gateway doesn't matter. You're taking in the payment information on your site and that must be secure. Please read the PCI DSS information, it spells it all out. Shared hosting is not PCI DSS complaint by any stretch of the imagination. See also PA DSS.

Seriously, read this. Then read this. Check out the self assessments.

(And given how easily it is to steal someone's session cookie over a non-SSL connection [and do basic HTML injection a la upside-down-ternet], I'd argue you should SSL everything, but that's another story for another day, but something you should be completely familiar with as someone competent in the web technologies you've mentioned. I.e., you talk about writing PHP, which means you're writing PHP to generate (X)HTML which means you already know about things like web servers and markup and CSS and you talk about MySQL which means you already know that database input needs to be sanitized [if this doesn't make you laugh, you need to learn more about secure web development practices], etc. If you aren't already familiar with these topics, get familiar before handing information like this. No one wants to hear that their credit card numbers were jacked/identity was stolen/whatever because some guy wanted to see if he could make an ecommerce site one weekend.)
posted by Brian Puccio at 5:06 PM on January 4, 2011

Response by poster: Yeah I know, I'm just getting all the info now even if it's something I "don't" understand yet.

But I will, as I just heard of the terms PCI DSS today, and I'm reading it. I get it now. I do want to have the CC transactions on my site eventually so I am going to look over that.

I found this site http://www.webasyst.net/support/help/shop-script-pci-dss-compliance.html

That talks about it, so I get that. I can use a 3rd party and do the transaction off site and then I'm not responsible for being compliant.

Most likely, yeah, I will do things the safe and easy way....

But... I'm learning, and got to start somewhere. Thanks again....
posted by Like its 1997 at 5:12 PM on January 4, 2011

Response by poster: Again sorry if I come off as an idiot but trust me I'm using this site to go back to for future reference as I learn more, so I very much appreciate all the info.
posted by Like its 1997 at 5:14 PM on January 4, 2011

No problem, we just want you to understand why we said maybe outsourcing either the shopping cart entirely or at the very least the payment part might be an easier way to go. The entire problem becomes someone else's problem. Taking the credit cards on your site, even if you're not storing them and just passing them on and are a level four site, still requires a lot of knowledge.
posted by Brian Puccio at 6:34 PM on January 4, 2011

Response by poster: Haha Thanks odin, I may have to go that route......

So I checked some of these sites, so far shopify or foxycart looks like best choice for me.

Okay this all makes sense now. My mind was just clusterf**ked over some other things but yea, ok, I see the light.

(I really just wanted to know cause I have been offered some jobs asking for this-- I been at big .com's hosting their own but I was only doing UI work and so didn't talk to those people. But smaller companies, I wasn't sure if they all hosted their own too, as I assumed it was a relatively 'easy' thing. But now I'm thinking most smaller companies probably use 3rd party too... ??)
posted by Like its 1997 at 3:08 PM on January 5, 2011

« Older How to deal with a break up when the person is...   |   why are there not any other podcasts with stories... Newer »
This thread is closed to new comments.