Forum Moderators: buckworks
Thanks.
It requires a knowledge of how banks communicate with each other on the back end - something you wouldn't know unless you've ever worked in banking and something you wouldn't be able to program unless you've written banking software. You need to have a lot of money to put up front if you're going to middle-man transactions. You basically have to become a merchant bank, working directly with MasterCard and VISA. A $100,000 deposit would be the minimum, and it has to be liquid (ie; you can't get a LOAN for 100k and use that as a deposit). You have to have damn good credit along with a hefty income to even get this far.
And of course there are certain local and federal restrictions that must be met in most areas as well. Then once you get all of that settled, you have to BUILD it - you're basically building your own Gateway and front-end to your Gateway. You don't have to worry about MIDS/TIDS because its your own proprietary system, but you will still need to interface with MC/VISA/whoever and that takes a programmer who knows what they're doing.
Then you have to build and debug a front-end to your gateway so your customers can log in, manage their accounts, buy crap, etc. Thorough bug testing should be done by an independent organization, not the programmer who developed it - as a programmer myself I know when I do my own testing I get buggy software :P
While your software needs are being met, you have to start thinking about hardware. That means load balanced servers with SSL accelerator cards (I recommend the F5 BigIP series for that) because SSL is required by MC/VISA for all Payment gateways. You have to make sure your service never goes down. Your database, probably SQL, should be clustered. You should have near-realtime replication to another SQL server in another data center in another part of the country or even in a different country. You should also have daily off-site backups of both. If your data center is blown to pieces you need to be able to get back up and running to where you were the minute before it happened as soon as you have replacement hardware. Data loss is not an option.
You need to have a full support staff - this will never be something that you can manage alone.
Then after you've done all of this, you have to market it - why would someone use your service over the next guy's? How are they going to hear about you?
Anyway ... this is only a small fraction of what's involved. I hate to be a buzz killer but this sort of thing is a long-term investment that takes a lot of time - you'll be putting up a lot of money and probably won't make it back for at least 5 years.
Thanks.
If you're just looking to provide the cart functionality, without ever actually holding the money yourself or middle-manning the transaction, you can write something like this in whatever language you want and interface with the existing gateways like Authorize.Net, etc. I'm not really sure what you're asking - if you can code it, you can do it :)
I read this thread just for the heck of it. I didn't realize what it takes (from a high level viewpoint) to be a decent CC processor. It makes me all the more wary of less established players and more comfortable with 2Checkout and PayPal who seem to have done a thorough job...but then again, how do I know for sure.
Any others people might recommend?
Thanks.
What about gateways? I saw a site that is a gateway to authorize.net. It seems as if they have their own company name, and I didn't see "authorize.net" mentioned anywhere. Are they considered a "shopping cart" as you say? Or did they pay the huge fees? I've been reading allot of stuff online, but can never seem to find enough details to figure all this stuff out.
Authorize.Net is what's called a "payment gateway". They don't handle the money, or have anything to do with the funds, they just provide the "link" between the Internet and the bank. The real verification/processing is done by the merchant bank. Authorize.Net does not take a percentage of the transaction, you pay a flat one-time fee for access to their service - If you're using Authorize.Net and didn't pay this fee, your access is leased by your merchant provider and you're paying monthly for it.
I'm not sure what the requirements are to be an Authorize.Net reseller, all I know is that there are a lot of them. Wells Fargo, for example, is a bank who uses Authorize.Net. If you get a merchant account through Wells Fargo you'll be using the Authorize.Net payment gateway. If you don't want to pay the $600 or whatever the Authorize.Net fee is up front, they will bill you monthly for it until it's paid.
Shopping carts are separate pieces of software that you can purchase, although some merchant providers do offer them as part of a packaged deal. The carts aren't created by Authorize.Net, just designed to work with it. I actually posted some code in another forum recently which shows how to use Authorize.Net's advanced itegration method in ASP for sending transactions to their server and getting a response, if you want to take a look at it it should be a "recent post" in my profile.
There are no shortcuts to understanding this stuff. Read anything you can get your hands on and read all the posts on any discussion board you find.
I'm a newbie as well and have spent many hours trying to make sense of e-commerce. Having a good grasp of it is critical but trying to do so via discussion threads is not effective IMHO
The reason I'm asking is that I own a website that is designed for micropayments, but want to offer cc support for the larger priced items - that's why.
Thanks again.
Are you selling a product YOURSELF, or do you want to accept credit cards on behalf of other people and then give them the money somehow?
If you're selling products on your own, just apply for a merchant account with any bank or e-commerce provider that uses the Authorize.Net gateway. I recommend Wells Fargo. They will set you up with a merchant account so you can take credit cards and an Authorize.Net account so you can process them online. You run the card and a few days later the cash is in your checking account. That part is easy and doesn't require any kind of deposit unless your credit is really bad. How much you pay per month/per transaction will depend on how well established your business is and how good your credit is.
If you want to middle-man other people's transactions though, that's where the stuff I was talking about in my first post comes in - it's a real hassel to accept responsibility for other people's money with all of the fraud out there, and I wouldn't recommend doing it to anyone.
These are the steps I'm *looking* for:
1. A Content Provider creates an "item entry" in their account. A link is provided to them to be placed on their web site.
2. A customer of the Conent Provider's site clicks on the content link.
3. A CC purchase form is shown (preferrably with my logo/design)
4. Transaction takes place, and an automated notification is sent to my server.
5. My client's (the Content Provider's) DB profile is updated (minus our fees of course) according to the amount successfully transferred.
The funds would be in our account, and we would "owe" the content provider the funds reflect in their database profile (aka their account).
A somewhat unrelated question for anyone reading: How can I build an automated system to transfer money to a clients bank account?
James
Get a merchant account so you can accept credit card charges. Not a big deal for most product lines, high ticket, adult items, subscriptions, and gambling is more difficult.
Get a shopping cart that has affiliate support built in or join an low cost affiliate program with a standard shopping cart. Send the content provider text links to your buy here page with their id in the reffer tag. The text link could (I think) be a buy now button that goes straight to your cart if your cart can track sales by reffer,
