Web Hosting Talk : Web Hosting Main Forums : Ecommerce Hosting & Discussion : CC processing API's for roll your own shopping cart

[stdunbar]

Just a warning: there is a reason that I'm still listed as a newbie...

I'm trying to understand the different API's that are available for someone who is creating their own shopping cart software. I've looked so far at the authorize.net API and the LinkPoint API. My concern is vendor lock in. While conceptually similar, these two API's are drastically different at the implementation level. I've also looked at CyberSource and a few others. I was heavily involved in an integration with CyberCash which is the catalyst for my concerns.

Is there a list of the available API's out there? Please understand that I'm turning this around from the normal discussions in this forum - initially I'm less concerned about fees and the back end processing and more concerned about how difficult it is to implement. CyberCash was, perhaps, one of the poorest API's I've ever dealt with in 16 years of software engineering. Add that to the fact that everything I'm doing is in Java and that CyberCash is a native interface and the problem was doubled.

Any help would be appreciated. And CC processor people - make those API's easy to find on your site! Realize that the technical people need to approve you too, not just the business folks.

[brevig]

I agree with you, more effort needs to be made to alert potential customers of available APIs. For this reason alone, I signed up initially with eNom instead of Directi...because I could download eNom's API documentation and see if it was even worth my time.

I am currently implementing CDGcommerce's API: CDGvault. It works by posting to a CGI script, and then it simply returns a page with something similar to success, failed, or valid, with an authorization/approval number. It may seem, and is fairly easy to implement. However, it's power lies in the fact that it stores the full credit cards off of your server and in a secure environment. You can reference the card for processing by using a unique token ID.

CDGcommerce is currently working on CDGvault version 2, so if you had anything particulat you would want added, they may be able to do it for you. Otherwise, this is obviously merchant provider specific.

Richard

[Corey Bryant]

One thing to keep in mind - you need to be looking for the API on the gateway - not the CC processor. A credit card processor does not actually own a gateway - they might lease it. It is against the anti-trust laws that came into effect about 6 years ago or so.

Here is some information on a few gateways & their APIs:
http://www.linkpoint.com/product_sol...lpa_index.html
(you can get a test store number with Linkpoint to test it all out for free)
http://www.authorizenet.com/solution...tionMethod.php
(you actually have to be a member of Auth.net to get a test store)
http://www.verisign.com/products/payflow/pro/index.html

Remember that these are only gateways - not the processor. You would need to find a processor as well.

[stdunbar]

It's time to make this a standard, isn't it? A fairly simple web service, serviced over SSL, would allow greater competition and reduce the cost to both the customer and the service provider. Compete on the quaility of the implmentation and your service, not the API.

Or is that the point for authorize.net, LinkPoint, etc.? A user spends so much time getting the API correct that the cost of changing it too high?

Thanks for the information.

[stdunbar]

Remember that these are only gateways - not the processor. You would need to find a processor as well.

Certainly - but the processor costs are far easier to figure out than development costs.

I want to avoid the business folks picking out a processor only to find that the API to interface with them was written poorly.

Honestly, I won't even consider using someone if I can't see their API upfront. If everybody used the same thing then both processor and development costs are known upfront.

[Corey Bryant]

Well to build a gateway costs quite a bit of money. It has to be maintained by Visa / MasterCard rules & regulations. And then that gateway will normally connect to a platform - some of the bigger ones for example the First Data Omaha Platform. That is then connected with Visa / MasterCard. So in essence if you really think about it - you are getting to know if a CC is good or bad within a few seconds - even though it has to "talk" to all these people in between.

If you had a few $100,000 to spend - you could write your own gateway to talk to a platform. Of course the gateway would need to be approved.

Yes, I know it seems ridiculous - but then again - they do not want just anyone accessing the platforms.

And basically yes. When yu build an e-commerce site - you need to know what it is going to connect to. LinkPoint even has something they call LinkPoint Connect - which you can connect via just basic HTML. And have the CC captured on their Gateway.

We connect to quite a few of them - LinkPoint, Authorizenet.com, PayFlow, and a few others as well.

[Corey Bryant]

You're right. When we first started - it was interesting to see all the rules & regulations that each company had. And to get their API. Some were very difficult & some were pretty easy. Auth.net was really bad because we could not test it until I found someone who trusted me & gave me her info so we could pass thru a dummy transaction.

Most processors market themselves. Auth.net is a gateway that actually markets the gateway. And that seems to be turning around more & more. LinkPoint is marketing tis gateway as another name as well actually to help boost their business.