Well, I was just working on a friends site, and we NEEDED a payment gateway. I was then given CCAvenue api kit. Its nothing much to look at really, it has a .doc file which has basic documentation. Its pretty easy to implement, even though you have your own shopping cart. However, since I personally only work with PHP, I was only interested with their PHP API. Thats when things started getting interesting.
QUICK INFO:You see PHP currently is in PHP5 [php-5.1.2 as this moment]. Thats the latest greatest version out. However, [PHP-4.4.2 at this moment] is still a branch off and is current. And well, I really prefer working with PHP5 to take advantage of certain features unique to it. Not to mention the performance advantage.
Now heres the disturbing news, the kit comes with .php3 files. PHP3 has been obsolete since YEARS now. This alone was quite a shocker, since most webservers today including mine DO NOT run .php3. There was effectively NO WAY for me to run the files ’out of the box’ or in this case out of the zip file. So you MUST rename the files for it to work, else make sure your webserver is configured to run .php3. Ofcourse if you change the file name, you will also have to change the include/require statements to run it. So this is when things started getting really interesting. I started thinking and immediately started opening the php scripts to see what else could be the issue. First thing, I changed the include/require statements to make sure it can start running. Now, the quick test.
As soon as I uploaded the scripts to my test server, I got an error; in function ’cdec’, ofcourse, it didnt take more than a few seconds to rectify the problem, it was a simple uninitialized/out of scope variable; but its amazing that this problem should even occur. Well, I started thinking, OK THIS IS DEFINITELY GONNA BE A BIT OF A GO.
The names of the files are pretty self explanatory, redirecturl.php3, is supposed to handle the redirect page (once the payment is complete). To a general programmer in first glance, things would look OKAY, IT SEEMS FINE. But if you take a closer look, this has a flaw. Firstly the script refers to ’register_globals’ to be on. For those of you who dont know what it means, its a security flaw. The concept of register_globals was done away with in php4.1, thats around OVER 15 months if I am not mistaken. Therefore, the first thing I had to do was rewrite this script for the security standards. Else, it WOULD NOT RUN. So if you are using this, PLEASE MAKE SURE YOU FIX IT UP.
Generally when you work on such scripts, you expect API’s to be CURRENT, and running without any issues. Here there were a few fixes that were needed to even get it off the ground. Anyways, you can see the commenting in the script finally, so you can go ahead and do your development on it. The rest of it was OK, no real problems or anything as such, (since the kit had only 3 files for php api and 2 had issues), I really couldnt expect the 3rd file to have an issue as well now, could I ?
Customer Service was alrite, I didnt really have much waiting time, maybe 40 seconds to a minute when waiting for chat. However, they do need to work up on their conversation skills. A simple question like ’HOW DOES MY SCRIPT COME TO KNOW WHEN THE PAYMENT IS MADE’. could only be solved once I read the integration kit. A simple answer of the basic understanding would have sufficed at that moment, but I didnt get it. So, dont expect any real technical issues to be solved in the first run with them. If you do have an issue, they will call you and speak to you, for any doubts. So atleast they ’CALL BACK’. which isnt bad.
Ofcourse there is 1 thing that has bugged me, I found a HUGE SECURITY FLAW and I am not referrng to the register_globals, which is mentioned above. Its something that will effectively hit any site that REQUIRES instant activation on payment. Lets just say thats a hint on its own on where the bug lies. Its sad really, since it took me less than 30 seconds to see the bug take place in a dry run, let alone an actual test. Imagine how easy the bug must be if I could dry run and see it in my head that this error exists. As of this second, the bug still exists [2006-04-16]. I have no clue when they will fix it or if they will fix it at all or no. However, I have informed them of this, who knows what they plan to do with this information. MAYBE GIVE ME A FREE PAYMENT GATEWAY FOR MY USE AS FINDERS FEE? hint, hint ;) Who knows how many other people know of this security breach and are using it to their advantage??! They better fix this or ALOT of sites are gonna find themselves in big problems. I want people to know of this issue, perhaps persuade them to FIX it. As I said, I already informed them of the issue, but I will NOT repeat myself, since really, they should have heeded my advice in the first place.
Dont get me wrong, the service seems nice, but lets face it, you gotta know what you are doing in this business, and if it took me 30 seconds, it would have taken someone even more knowedgable 10 seconds !
I am not sure if this effects their built in cart tho, I dont think that is effected by this, or theoretically shouldnt. So for those of you using their built in cart, frankly it shouldnt effect you.The rest of you, keep your eyes open for any updates.
As for the other API’s frankly, I dont know, but from what I gather, you could have similar issues.
As for its payment terms, If you have an INR account, its good, specially since alot of people today work on netbanking, this can gain you huge performances as people sometimes are not ready to share their credit card information, but wouldnt mind paying directly through their account. Also its faster than paypal to receive payments, paypal takes around a month to send a cheque. Thats a good time loss for your business, specially if you require rolling credit.