Thanks for your opinion on this. I see what you mean, but I think it would offer more legit benefit to customers instead of fraudulent ones. My main concern personally is ensuring a person's billing address matches what they entered. If I tell somebody they entered an invalid address, how will that help them to magically come up with the proper one?
Maybe the Invison folks can make it an option we can enable or disable?
I have Nexus' anti-fraud rules enabled. Some users have emailed me saying they don't know why their purchase is being blocked. Once I inform them of the reason (ie, an invalid billing address), they say "Ahhh", and handle it as appropriate.
My request is that when a user receives the error saying something like "Your purchase did not pass out Anti-Fraud rules".... please be more specific as to why it failed.
The overall ability to search for products in IP Nexus is not working very well. Don't get me wrong: it "works", but the results tend to be difficult to digest. I have a large store (nearly 3,000 products, both physical and non), and trying to find anything using the search functionality is difficult at best.
I am using Sphinx search, and all my cron jobs and .conf files are working fine.
Here's an experiment you can try for yourself. The goal is to find an ebook entitled "Into the Darkness" by author Harry Turtledove.
Go to my storefront: http://www.dragonmount.com/Store
Search on any term you like. Examples: "Into the Darkness" or "Harry Turtledove" or "Into the Darkness Harry Turtledove" or "Darkness Turtledove"
Searching for "Into the Darkness" results in the item being shown at the bottom of a long list of products
Searching for "Harry Turtledove" results in the item being shown at the bottom of a long list of products, some of which are barely related to the key words
Searching for "Into the Darkness Harry Turtledove" results in NO results
Searching for "Darkness Turtledove" results in NO results
Is there any way that the search function can prioritize the product name over the description? How about returning result sets that don't show the ENTIRE description? (That gets huge and cumbersome). Probably better just to return the product name and the first few lines from the description.
Thanks, Mark. I didn't realize this was possible with today's software. I'm signing up for a trial with MaxMind, which is required for the address and phone number check.
I'll move forward with MaxMind, but I still think the ability to stop a transaction due to invalid credit card addresses should be built into the software without the need of a paid, 3rd party service. The Stripe.com gateway is already doing some of this work for you. Specifically, they are already checking the validity of the mailing address, and returning a code to you to tell you if it's valid or not. Can't Nexus take that code and act appropriately? Seems unnecessary to rely on a 3rd patty service when we already have the info being given to us by the payment gateway in this case.
Currently, AFAIK, when user buys something from my store using their credit card via the Stripe.com gateway (which I love, btw....) they can enter any address as long as the credit card number itself is valid.
PLEASE CHANGE THIS, or at least give us the option to require it. Every credit card should be validated against a current mailing address. Not only is this an important feature to prevent fraud, but it without it, some manufacturers will not allow me to sell their wares.
IPS devs: Here's a link to the stripe.com help section on how to enable this feature inside IP.Nexus
I spend a lot of time on this Nexus forum these days, usually asking for features and pointing out bugs. But I think it's worth being said that IP.Nexus has been an incredible tool for my website. Yes, it has defects, and yes I've had to create complex custom scripts to get it to do what I need... but at the end of the day, I love this product and it's already paid for itself and then some.
The strongest features it has, IMO, are the support for a wide variety of gateways (Stripe.com in particular is awesome!), the very good support ticket system, and the very good invoice managing, approval, refunding, and package tracking system. Outstanding stuff. Oh, and my favorite... the ability to sell IP.Download files!
Thank you, IPS, for working so hard on this product. For only being version 1.5, you've done a great job.
(... now get back to work on 2.0, and be sure to implement all my requests!!) :thumbsup:
Thanks for your insight into the history of your thinking. It's appreciated.
However, I'd like to respectably challenge your comment above. Currencies should not always be sorted out at the payment gateway level. The main reason is that products cost different amounts in different countries. And I'm not just talking about conversion rates. For whatever reason, right or wrong, fair or unfair, the reality is that the same product frequently costs different amounts depending on the region it's in, even after you factor in your exchange rate.
This is exactly what I'm running into with my store. I sell eBooks. And those eBooks get priced differently depending on the country they are in. I cannot simply say "this book costs $9.99 US", and assume it will properly convert to the proper Canadian price, or UK price.
I am missing an opportunity for a lot of business because of this. I'd like to humbly request that you reconsider this feature. I'm happy to give more thoughts if it would help you out.
But my issue is that I need one set of products to be priced based on US $, and the other store to charge Canadian $. How do I do that? My impression (and based on my tests) is that I can only have one currency type per store. Right?