Forum Moderators: LifeinAsia
Here are the options that I have come across so far:
authorize.net
worldpay.com
verisign.com
Please advise.
Securepay has a pretty good interface, but the customer support is pretty crappy.
Paypal is great on many levels if you don't want large set up fees.
Again, it depends on the client, the size, and the product. It seems like a ton of software vendors send us through 2checkout so apparently, that has some fans.
Plus, nearly every bank chain offers merchant accounts directly through them for cc processing.
Good luck!
Pat
I've used authorize.net from day 1 to right now. They have had their problems, but not significant enough to make me switch.
6+ years in the business, Authorize.net all the way! Are there better options......maybe......but, I'll be sticking with them as they not have created a reason for me to "shop around" in the last 6 years :)
As has been said, it depends on what works for you. Connecting to a gateway requires:
1. That you have a secure server on your site that you can post data FROM. Gateways won't accept unencrypted posts.
2. A bank account that supports the gateway. Generally the bank will now want a piece of this pie, esp. if you are business. Most of the time this is an online merchant acount, different or at least integrated with an offline merchant account.
3. The gateway account itself, which generally entails a setup fee and monthly fees. Sometimes it's a flat fee, sometimes revenue based, sometimes both.
4. A programmer who can make the connection in a secure and solid way.
Because of the costs of the above, many merchants say, "I already have a merchant account. Just set it up so the CC info gets emailed to me."
BAD IDEA, with one exception. Email is not secure, this data can be intercepted and stolen. The exception is if you are using an encryption method such as GPG to encrypt the data before sending and the data is decrypted by the recipient's mail program. This requires a public key on the server to generate the encrypted data, and a PRIVATE key, owned and kept safe by ONLY the recipient, used to decrypt it. I believe even Outlook supports this method of decryption. The problem here is someone has to physically set it up at the recipient's computer and train them in its use, both are fairly complicated.
The other alternative is to write the data in an encrypted format either to a file or a database, and email the company that an order is in. In this way, the data never leaves the secure server. This requires constant vigilance; as soon as you get the order, you log in via some web interface, get the info (via custom programming to decrypt it,) and immediately take action to remove the CC info from the server (this should also be part of the custom programming.) This narrows the "window" in which a hack attack may compromise the data.
THIS IS STILL NOT 100% SECURE. If someone manages to root your server and is free to browse your programming, they can easily figure out how you're doing the encryption and with a few commands unencrypt and gather any CC info that may still be stored on the server. Since this all takes place on a secure server, it is highly unlikely but is still possible, which is why it is so important to monitor such a system constantly. If your email notification fails, this widens the opportunity for theft. If you're not going to be able to monitor the system and data can sit for more than a few hours unattended, this is also a very bad idea.
In any case don't eliminate paypal, it's easy to implement and a lot of people love it. Whatever you do it should be an additional option.
My further question thus is: which is the "best" service for CC transaction as fare as the following requisites are concerned:
1) Amount of countries (countries, not just states) payments are accepted from
2) Rates applied to the transactions
3) Possible set up fees
4) Amount of data echoed back to "my" site
5) Possibility to avoid https - I want to pass the client who wants to pay directly to the processing service with a mere Id: the processor takes care of the httpS and sends back to me the paying client to a specified page on my server with at least echoed the sent ID and the result of the transaction
6) easy installation: I _just_ wish all I'd need to know is how to name form names, what type of data they need, which one are truly mandatory, and where to submit them. don't want to read 200 pages in a pdf file, full of technicalities whose 80% I don't even need to know.
Particularly point (1) seems to be a possible issue with many services. Authorize.net is _apparently_ a Usa only thing, correct?
Also point (6) is thorny: we have set up instructions made in 200 long pdf files normally....
thank you
Alberto
[edited by: Alberto at 3:31 pm (utc) on Aug. 18, 2006]
I have a paypal account, validated.
Now, I sell only _one_ product, at a fixed price, which may ned a one year recurring billing. Nothing to dispatch, it's a subscription to a portal.
I also need that data is echoed back with two flags at least, success of transactiona nd an id i already sent.
Do I really need to read all the 134 pages of the paypal adobe file uh?
Feel free to say yes you do :-)
Alberto
Other than basic setup of your Paypal account, here are the basics...
1 - Setup the subscription buttons with at least one custom field. It's fairly easy and there are online tools to do them if you want.
2 - Setup the IPN page to receive notifications and log them to the database/update records. I used a template somebody else did that's free and available online. It took me about an hour to modify it to my needs.
Just PM me with any detailed questions.