View Full Version : shopping cart recommendations?
I've been hard at work getting osCommerce set up the way I want and thought I was pretty much good to go, but now that I've spent a fair chunk of time fiddling with the Authorize.net modules, I'm quickly running out of patience with it. The fact that it isn't certified as Authorize.net compatible threw up a bit of a red flag, but searching osCommerce forum posts more or less eased that concern; guaranteed to work by many. Unfortunately, delving into it proved otherwise. The module is at best buggy. Severely under-documented, unsupported, and apparently lacking in important functionality would be more like it. Here's the tip of the iceberg:
http://forums.oscommerce.com/index.php?act=ST&f=7&t=63771
Their MySQL connection has been pretty shaky the past few days, so you might have difficulty accessing the forum.
Communication with the payment gateway is not something that should be trusted to a potentially buggy process. Unless the development team shows an intention of fixing this weakness and soon, I'm thinking I'll need to turn to an alternative cart. That's where my question comes in...
From the Authorize.net list of certified carts, do any of you have feedback on any of them, either as an administrator or customer?
http://www.authorizenet.com/alliances/carts_cert.php
There's next to nothing in there I'm familiar with. My strong preference is for it to be a PHP/MySQL application so I can actually modify it as needed. A well backed, professional program is a must, and a decent user community is desirable. Cost is not a factor at the moment. I've wasted far more time with this osCommerce nonsense than a commercial application is likely to cost...
Dan
Good grief, going through the list of certified carts, they're pretty much all hosted Perl or ASP setups. I sure hope there's at least one good option out there...
Dan
Evoir
10-30-2003, 03:57 PM
Yes!
Quikstore is a really cool program. Click Here (http://www.quikstore.com/)
If you only have a few items for sale, you can just use html mode and use standard HTML pages, or they have an online catalogue builder, where you can have it set up on a databse (flat file) where you can sort the products by category etc.
I've done two sites with this script and one site with another script. (by Gossamer-threads) and I like quikstore better.
Oh, they also have a very good online community Here (http://66.227.119.174/cgi-bin/newbbs/ultimatebb.cgi) That is almost as quick and helpful as this one. It does have authorize.net plugins and comes with a FREE install.
I don't make anything by refering you, but I am happy to let people know about it. :)
Thanks for the recommendation, but it doesn't look to be Authorize.net certified (I'm growing distrustful of anything that isn't ... it makes sense that any cart would want to be certified it if were able to be) and isn't the PHP/MySQL platform that I consider to be a basic requirement. "No programming knowledge necessary" is another way of saying, "good luck setting it up the way you want."
Dan
Evoir
10-30-2003, 04:26 PM
"No programming knowledge necessary" is another way of saying, "good luck setting it up the way you want." Not true in this case. It is a pretty strong program, well written and well supported. I've worked with it for a few years now, and am almost as happy with that company as I am with FQ. And that's a pretty good reccomendation.
I've found the software to be well written, easily adaptable, well supported. Ok, so it is not in php/mysql... but a cart doesn't really need to be.
I am not sure if this is what you were looking for, but it does support Authorize.net - Look Here (http://www.quikstore.com/ezic.html) and look about 4 items down on this (http://www.quikstore.com/products.html) page.
S'okay if you don't want to use it, but I am kind of a quikstore zealot. :D
I should clarify why I say it needs to be PHP/MySQL: This needs to be closely integrated with various aspects of my site. I'm not interested in just sharing a header/footer template and calling it good, because much of the important functionality will be lost.
Lots of carts say they're compatible with Authorize.net, but my experience so far is that is pretty much meaningless unless Authorize.net lists them as a certified compatible cart. They've got a process (http://www.authorizenet.com/alliances/carts.php) for becoming certified, and obviously being on the list is a big form of advertisement, so my thinking is anyone not certified lacks those credentials for a reason.
Dan
tappel
10-30-2003, 05:45 PM
Dan, you may want to look at X-Cart (http://www.x-cart.com). It's what I'm using at www.bassguitarstrings.us which is hosted here at FQ.
There are some caveats, however. X-Cart requires that safe_mode be disabled. This is only an immediate problem if you intend to use a shared or private cert here. Secure_mode isn't implemented yet on Apache/SSL. It's in the works though (I've contacted FQ service regarding this). I eagerly await its rollout as I own a merchant acount and a private cert in anticipation. :)
Also, the X-Cart team is Russian. The out-of-the-box version is written in english but will require some tweaking to make the grammar and syntax acceptable.
There's a busy user forum, though I've found that only the routine questions get answered there. For more complicated questions you'll need to contact the developement team. They're quite helpful, though they only work regular business hours.... Russian time. As I said, some caveats.
Tom
That's a nice looking product, and it would seem to meet the platform requirements just fine (tough to tell from #5 (http://www.x-cart.com/cart_system_requirements.html) about the Authorize.net tie-in, though), but that safe_mode issue is a pretty major one. :( Do you know what about the cart requires safe_mode to be disabled?
I'm thinking I might go back to fiddling with my home-made cart and see if I can tie it into Authorize.net properly. At least that way, I'd be confident it's doing what it is supposed to and I'd be able to feed the proper transaction data through to the end.
Dan
My blood pressure has returned [almost] back to normal, and after nearly 36 hours straight of working on this, I think I've got it figured out:
http://forums.oscommerce.com/index.php?showtopic=63771&st=0&#entry249363
Unless I discover any drawbacks to my modifications, it's probably solid enough to go ahead with, so that may eliminate the need to look for alternative carts. Keep your fingers crossed...
Dan
From the oscommerce forum post:
Also, as best I can tell, position 38 in $response (key 37 when you explode the comma delimited string -- Authorize.net's instructions number from 1, not 0 like with an array) is a md5() encrypted transaction key corresponding to the purchase. I sure hope that's right, because it's what I'm using for a post-purchase processing tie-in to identify the transaction... If anyone knows otherwise, I'd appreciate the info.
Be careful about treating the returned Anet response as positional! The response returned is a POST response so it is in a name,value,name,value,... format.
The hash field returned by Anet is named x_md5_hash and is generated from pre-defined transaction fields. You can use the md5 hash to confirm that the returned results did, in fact, come from Anet by generating the hash yourself and comparing to the hash send. I would not, however, assume that the has is unique for each transaction.
The response returned is a POST response so it is in a name,value,name,value,... format.
That's what I assumed at first from the osCommerce examples, but it does not appear to be the case. The returned response is a comma delimited string of values, no names, that has to be exploded to form an array. I don't see any way to get name-value pairs out of that other than to trust it is indeed returned in the order stated by the Authorize.net documentation. (I confirmed that it matched up in my test cases.)
The hash field returned by Anet is named x_md5_hash and is generated from pre-defined transaction fields.
Hmm, that's not what I expected. As far as I can tell, that field is not being sent from osCommerce, so Authorize.net is generating it based on something else. Here's the wording from page 21 of the AIM guide available here ("with password" version) (http://wellsfargosecure.com/customer/sss.htm):
MD5 Hash: System-generated hash that may be validated by the merchant to authenticate a transaction response received by the gateway.
I take "system-generated" to mean their system... Maybe it means you can pass in a value, otherwise it will generate one? I'll have to see if I can find more references to it in the guide...
Dan
In addition to the above, I just noticed in the list of response fields that all the merchant-specified ones mention the x_* in the description, whereas the Authorize.net-specified ones do not. The md5 hash #38 field does not mention an x_* variable... Maybe they changed it at some point, or maybe you're thinking of a merchant defined field at use in the past in one of the unreserved positions (69+)?
Dan
That's what I assumed at first from the osCommerce examples, but it does not appear to be the case.
You are correct. I apologize for the detour in thought. Anet has two different interfaces (AIM and SIM). SIM returns a post that can be processed into a hash while AIM returns the positional comma-separated string. I'm so used to most people using the SIM method that I assumed (incorrectly) that was what you are using.
Hmm, that's not what I expected. As far as I can tell, that field is not being sent from osCommerce, so Authorize.net is generating it based on something else.
This is a hash value that is generted by Anet and returned by Anet to your application. See Appendix D of your documentation for more info. Note that the hashes are used differently between the SIM and the AIM implementations. In SIM, the merchant is required to calculate and send the hash but in the AIM implementation, the gateway returns the hash. Also, in SIM the md5 useage is required while in AIM it is optional.
Phew, that's a relief to hear! I hate relying on guesswork for something this important...
I may have neglected to mention I'm using ADC/AIM, sorry. SIM is the default module for the osCommerce setup, but even Authorize.net describes it as being less secure, so I wasn't interested in doing anything with it beyond initial testing. I didn't realize the two methods return response data in a different manner.
See Appendix D of your documentation for more info.
I haven't gotten that deep into it yet, but I'll definitely be reading it cover to cover.
Dan
To follow up on this, the hash value is a bit different than what I expected. Better, actually. I haven't run it through a valiation test yet to make sure I've got it right, but it is a md5() encrypted string that consists of:
MD5 Hash (value is set in your Authorize.net admin area)
Login ID (for logging into said admin area)
Transaction ID (returned in the Authorize.net response code)
Amount (as submitted to Authorize.net)
It would be pretty tough for someone to duplicate all of those pieces without having hacked into your server and Authorize.net account, in which case you've got a much bigger problem than validating a few transactions...
I'm still only running stuff in Test mode, but I found a few surprises that maybe only spring up in Production mode. For instance, the Wells Fargo SecureSource plan I'm on apparently requires either customer SSN/Tax ID info or full driver's license info (number, state, dob), as well as company, to be specified in order for the transaction to go through. That must be part of the extra layer of fraud screening? I just hope it isn't too much information for customers to be willing to proceed. I'll be sending in a support question this evening to hopefully shed some light on that.
Dan
For instance, the Wells Fargo SecureSource plan I'm on apparently requires either customer SSN/Tax ID info or full driver's license info (number, state, dob), as well as company, to be specified in order for the transaction to go through. That must be part of the extra layer of fraud screening?
LOL, I had almost forgotten about that "fraud control" method.
I will be VERY interested to see how this reduces your fraud. My opinion is that you can save yourself a lot of money and not use SecureSource and just limit all your purchases to U.S. customers because these are the only ones who will be able to submit orders to you using the SecureSource implementation!
Dan:
I am very interested in how things are progressing with Authorize.net and osCommerce. I am investigating using osCommerce for 2 sites coming down the pike and looking very seriously at this combination.
The two banks I am looking at are Wells Fargo (reputation) and Humboldt Bank (prior experience).
---
BenV
just limit all your purchases to U.S. customers because these are the only ones who will be able to submit orders to you using the SecureSource implementation!
Urgh, I hadn't thought of that. There aren't international equivalents of those fields that get accepted? If that's the case, I think I'll be demanding that they switch me over to the non-SecureSource plan with no new setup fees... I clearly told them in the signup process that I receive international orders and was never told this plan would make that impossible.
I know you think I should disallow all international orders, but I cannot agree with that. I might as well just throw up my hands and quit the business if I'm to that point. I have to go down this road and hope it works, otherwise there's no point in going on.
Dan
It may have been a false alarm. According to the support response I received:
Company is not required- if you do pass and there is no company just put in something - even if not correct. This info is not verified.
Driver's license info or tax/SSN # is only required of eChecks- not credit cards.
It isn't entirely clear from that info if the added SecureSource fraud screening consists entirely of optional company/TaxID/SSN/DL fields (despite being described as required in the documentation), or if there is more to it that I agreed to pay extra for...
Also, they provided the list of allowed countries, according to the SecureSource package:
BE Belgium BEL
BR Brazil BRA
CA Canada CAN
CL Chile CHL
CN China CHN
CZ Czech Republic CZE
DK Denmark DNK
FI Finland FIN
FR France FRA
DE Germany DEU
GR Greece GRC
GU Guam GUM
HK Hong Kong HKG
IS Iceland ISL
IN India IND
IE Ireland IRE
IL Israel ISR
IT Italy ITA
JP Japan JPN
KR South Korea KOR
LULuxembourg LUX
MY Malaysia MYS
MX Mexico MEX
NL Netherlands NLD
NZ New Zealand NZL
NO Norway NOR
PH Philippines PHI
PL Poland POL
PT Portugal PRT
PR Puerto Rico PRI
SG Singapore SGP
ZA South Africa ZAF
ES Spain ESP
SE Sweden SWE
CH Switzerland CHE
TW Taiwan TWN
TR Turkey TUR
GB or UK United Kingdom GBR
US United States USA
VI The Virgin Islands VIR
So, there is at least some attempt there to weed out problematic ones like Indonesia. Still, Malaysia, Singapore, and the Philippines are allowed ... I was under the impression much of that region is prone to internet fraud.
Dan
Driver's license info or tax/SSN # is only required of eChecks- not credit cards.
That's more reasonable. The service needs to be effective without driving all the customers away. :)
I know you think I should disallow all international orders, but I cannot agree with that.
Oh, no, I did not mean to convey that message. You need to elimante transactions from your high-risk souces, but how you do this is by just turning off the country that is responsible for the most fraud...collecting data and evaluating results...taking the next step...etc. I would never advocate making changes without testing everything and only keeping in place those things that work.
Still, Malaysia, Singapore, and the Philippines are allowed ... I was under the impression much of that region is prone to internet fraud.
These might be considered "marginal." They are very suspect transactions but there are also a fairly large number of legal cardholders in these areas. But, some places, like Indonesia, almost never generate a valid purchase.
The service needs to be effective without driving all the customers away.
Agreed!
I did not mean to convey that message.
Sorry, I guess I misunderstood. I suppose that puts us on the same page, then. :)
I've got a plan of attack that I believe is fully implemented and ready to roll now. Since virtually all of my fraudulent orders have been for D-Man, and I believe the majority of those have been international, my pre- and post-purchase processing system looks at anything that meets either of those criteria (I'm treating Canada as domestic and may add others if they prove reliable) as suspect and sets it up as an AUTH_ONLY transaction with no auto-processing for downloads access. If it is a domestic order for a program not [so far] prone to fraud, it is sent as AUTH_CAPTURE and receives the auto-processing. I'll keep an eye on that and make sure I don't get burnt... Hopefully, that will provide a good balance between making as many customers happy (auto-processing for instant access) as possible without leaving me needlessly open to all the fraud and chargebacks.
Dan
vBulletin® v3.6.8, Copyright ©2000-2012, Jelsoft Enterprises Ltd.