tutorial for getting a payment processor set up?

[cardboardtube]

I'm new to handling ecommerce aspects of a site and have never set up a connection with a payment gateway on a site before. Can anyone please point me to a tutorial or introduction to what services are available, and/or how to get started? I'm really looking for a "here's the general way it works, and here's pretty much what your options are".

A friend suggested we "just use PayPal". I've never used PayPal for anything, and it looks like now they do credit card payment processing as well. Another that looks like it has pretty good documentation is Authorize.net.

I'd be grateful for any recommendations, or overviews on how this whole thing is supposed to work.

Thanks.

[cardboardtube]

Yes, I'm reading the "Ecommerce 101" sticky thread, "Gateways, CC Processors, & Merchant Accounts" section right now. :)

[cardboardtube]

One last thing: the site is a custom job, so I don't think I need a "shopping cart" webapp. In fact, it took me a while to figure out exactly what a "shopping cart" actually is. It looks to me as if the terms "shopping cart" and "catalog" are often used interchangably, where "shopping cart" is *also* used to refer to the list of things a user has selected from a catalog.

Do most shopping cart packages come with canned ways to interface with the various payment gateways?

[paladin]

You need to start by deciding which payment processor you want to use. Many of them offer sample code that you can integrate into your site.

[cardboardtube]

Thanks Paladin.

Can you tell me though, it seems like some sites don't even do their own payment gateway integration. That is, I think I've been to sites where, when you click "buy", you're taken to another site that looks sort of like the one you were just at (maybe the same color scheme), but it's a different site that's only used for the payment itself. Is this a common practice?

Also, is having your site talk to a payment gateway like authorize.net pretty much the same thing as with paypal (but with a different interface), or is there some fundamental difference between what the two are doing for you?

[paladin]

Like you said there are 2 main ways to go.

The first is when you click the buy button and a new screen opens on the Merchant site. 2CO and PayPal have these - I am sure there at least several more. In this case you are passing the cart and store information to the processing site where the user fills out their payment info.

The second option is where everything is done behind the scene (read backend - PHP, ASP, Perl etc...). This is where the customer eters the data on your site and your backend talks with the merchant processor. PayPal has an option for this as well. I did a similar Linkpoint integtation in PHP with this a while ago.

The second option look more professional to the user, but requires more effort on your end to set up.

[cardboardtube]

Ah! That's part of why I was confused: paypal does *both* kinds. Thanks, paladin.

So, it sounds like, when you're doing the seamless processing on your own site, there's only one way to do it: use the payment processor's interface and have your site's code talk to it.

I've dealt with one site in the past that had basically had 2 sites in one. The one that customers dealt with simply put their order in the database and sent them a "thank you for your order!" email. The 2nd site was the admin site where a person running the business would log in, approve the orders, and actually make the order go through (this admin site was the one that actually talked to the payment processor).

Can you tell me, what's the usual way of talking to a payment processor? Do you write the socket code from scratch? Or do they provide a secure URL to send and receive to/from? Or maybe a web service?

Thanks a bunch.

[Corey Bryant]

Basically you have what is known as an IPSP (Internet Payment Service Provider) (third party payment processing) and your own merchant account / electronic payment gateway.

The IPSP allows you to use their merchant account to accept credit cards online.

When you have a merchant account along with an electronic payment gateway, chances are you can use the electronic payment's API to integrate into your website to help to communicate with the transaction provider.

Usually, in the United States, if you are doing more than $1,000 a month, a merchant account along with an electronic payment gateway is more beneficial. You will get your money within a couple of days of the transaction, and you won't have to sign into anything to tell them to send you money. This might save you time / money in the long run

-Corey

[cardboardtube]

Thanks Corey. Ok, I see: your own business bank account is referred to as the "merchant account", even though you have an "account" (as a merchant, technically, I suppose) with the IPSP.

Alright, to go further, looks like I need to read about each individual IPSP's way of handling interactions. Perhaps they all do it differently.

Thanks.