I'm looking into building a web app that allows multiple e-commerce stores to coexist on the same installation and lets allows each individual vendor manage their own products, pricing, sales reports, etc. I know that there have been a number of previous questions on the Stack regarding the best shopping cart software, but this is a bit of an unusual twist and I couldn't find it answered elsewhere.
Obviously, open source is better from a pricing standpoint, but I've got no problem with spending money on a quality product that meets my needs. The ideal package would allow each store to be uniquely skinned, would minimize the amount of time that it takes to get a new store up and running, and would include payment gateway and shipping integration.
I've run across a few things in my scouring of the web, but haven't found "the one" yet--I know that osCommerce sort of supports what I'm trying to do, but I'm looking for something designed with this functionality in mind. Any ideas?
Thanks!
Justin
I am at present looking into the same thing. After looking at all the different cart on the market I have settled on PHP Mall 2. I have had demos of X-Cart Pro, iscripts multicart and a few others.
There were only 2 that were any good at handling payments direct from buyer to seller without any added costs of have a mod done for that. They were PHP Mall 2 and iScripts Multi cart. iScripts Multicart didn't really have alot happening in the backend, and vendor shops were really just an about us page with their products showing.
I settled for PHP Mall 2 becuase each vendor can have their own website as such and can customise it to the way they want it. They can choose from a number of templates for their shop.
The part I really like about it is the payments system, there are a number of payment gateways out of the box and the vendor can choose which ever he/she wants. (because not everyone use paypal right!). Its also a fair bit cheaper than all the others and provides alot more from a site admin and seller admin side of things.
I was tasked with looking into a multi vendor cart for a project that was canceled. Before it got canceled, I felt that the below were strong contenders. This is not a comprehensive list but it's somewhere to start. The requirement for multi vendor was paramount, so the listed have varying amounts of CMS/blogging etc; so they are not necessarily apples to apples.
I did get to try out magento community and using information found here http://www.magentocommerce.com/boards/viewthread/145/ got what I felt was the correct experience for multi store/vendor for my purposes. Mileage may vary depending on requirements. It's a beast though and for some reason comparison doesn't indicate the multi vendor capabilities. My impression was that Magento was definitely for the technically minded, with a very high degree of configurability available. It's a meta system for sure. The average joe business owner wouldn't stand a chance with it. However, it might be a perfect for resellers.
http://www.x-cart.com/mall_solution.html
http://www.php-shop-system.com/products/iq-cart-for-joomla-our-new-cart-component-for-joomla.html
http://www.magentocommerce.com/product/compare
I am also in search of a multi-store solution. Magento Commerce is too expensive. OpenCart now supports multi-shop but only a single user can manage the stores. I would have preferred setting up multiple stores and have different users manage each store.
I've also been undertaking research within this area and discovered the following options;
For joomla = http://www.ijoobi.com, IXXO
For Magento = http://www.unirgy.com, MVDE
There is also an interesting product called MultiCart from iScripts, and the X-Cart Pro from Qualiteam.
Related
I have a mobile app that allows people to upload information of clothes they have and share it with their friends. I have good traction - increasingly more users every day.
I want to create a new feature that allows users to sell unwanted items on eBay. Ideally, they'll click a button and the item will be available for sale on eBay.
I went through the developer APIs and I'm not even sure where to start. I can't tell whether I should try Retail-Standard Selling (New Sell APIs) or Traditional eBay Selling (Trading APIs) or even something else. Please could someone point me in the right direction?
Since we're speaking of unique items I would suggest to use "old" trading API AddFixedPriceItem
that's made for garage-sale and can do everything with just one call. (1)
while new Sell APIs are meant for stores selling new items in multiple quantities
and requires several calls to achieve the same result (create depo, images, listing, offer...)
BUT
despite what eBay writes (that will continue to support Trading APIs)
we see that every month some Trading APIs are decommissioned or deprecated:
for example last January they removed GetCategorySpecifics
and for next April there will be others..
Clearly you could mix the APIs, using the best combination of both
but since you're at beginning and since the 2 API family are completely different, I suggest you to use new Sell APIs
(1) Just to create the Listing, then several other are required to find proper category, itemsSpecifics, creating the profiles.... and so on..
I'm just wondering if anyone can provide me with some information into how e-commerce websites automatically calculate the postage and shipping costs for items ordered on-line?
Do these websites use plug-ins/web services to dynamically request this information from the postage/shipping provider? Or do developers manually retrieve the postage costs from the associated shipping provider and then develop their own approximate postage/shipping cost calculation algorithm (in agreement with the e-commerce business of course)? Or are there any alternative approaches used?
Any help is much appreciated. Thanks.
EDIT: I have done some basic research on the topic. I've seen some plug-ins for WordPress but each plug-in was limited to specific postage/shipping companies only.
Do these websites use plug-ins/web services to dynamically request
this information from the postage/shipping provider?
Yes, this is certainly an option. In my experience, the APIs provided by UPS and FedEx are decent and work for the UK market.
Or do developers manually retrieve the postage costs from the
associated shipping provider and then develop their own approximate
postage/shipping cost calculation algorithm?
I would not recommend this - a maintenance headache for one reason - and have never seen it done.
Or are there any alternative approaches used?
Sometimes, fixed shipping-costs can be used - for example, when delivery is to a single country or products weights are relatively static. No API call is needed in these scenarios.
Based on my research, I've found that there doesn't seem to be a single standardised way of calculating shipping/postage costs on e-commerce websites. Some companies provide plugins for WordPress, etcetera, to assist in this process, while others companies provide API's.
Primarily, I'm interested in using a UK based shipping/postage provider.
The Royal Mail is the largest postal provider in the UK and it provides an API for a number of tasks; however no official API appears to be available for cost calculation. I did however manage to find an unofficial Royal Mail cost calculation API. It can be found at the following link.
Before jumping in I'd like to know what all of my options are, and, if possible their pros and cons.
The two I know of are using ActiveMerchant, or the paypal_recurring gem, but will they satisfy these requirements?
Ability to accommodate monthly and annual billing
Ability to suspend, cancel accounts etc
Deal with out-of-date card details or failed payments
The to-do list for the paypal_recurring gem includes 'adding support for IPN' - how will not having this impact functionality?
I know there is the railskit SaaS but I'd rather code something myself as the railskit is still on 3.2.1.
I know there are services like cheddergedder/chargify etc, but do they tie you in? Are they US only? Are they worth considering - or are they usually just aimed at non-developers?
Thanks in advance.
I just finished going through this, so I'll try to shed some light on your options. I ended up using Paypal Express Checkout for all recurring purchases through Paypal. We had a custom-rolled recurring billing setup that charges a customer's credit card monthly through Authnet, but had to switch because we needed an international solution, and Paypal was one of the only ones that supported the currencies we needed, and wasn't entirely a nightmare to code.
You can use ActiveMerchant for recurring billing with this plugin, though keep in mind that it is not officially a part of ActiveMerchant, and therefore is subject to break if ActiveMerchant changes how it handles certain things. Because of that, I ended up using the paypal-recurring to handle communication through Paypal, and then rolled my own IPN parser, with help from Railscasts. Another link that helped me a lot was this, though all the :txn_type values ended up being different.
With regards to that last link, here are the 4 :txn_types that I specifically watch out for:
express_checkout - first postback.
recurring_payment_profile_created - sent on first postback when the user first subscribes.
recurring_payment_profile_cancel - sent if user cancels subscription from Paypal's site.
recurring_payment - Money has been transferred to your account. This is what I wait for before I renew their subscription on a monthly. This post also comes with payment_status, which needs to be completed.
The other stuff you mentioned, like handling failed payments and out-of-date cards, is handled through your Paypal account.
Just a word of warning - the only reason I ended up using Paypal is because it is universally recognized and trusted, and it accepted international currencies. There is an enormous amount of documentation on their site, and most of it is redundant, confusing, and entirely too long. My recommendation is to make sure you really want/need to deal with recurring payments, as they are difficult to implement correctly and can be more trouble than they're worth.
I'm currently looking at Ryan Bates example of Stripe. They are a California based company that uses/offers the features you have listed.
www.stripe.com
They only charge when you receive money. I think that they are 3% plus $0.30 per successful transaction. Much better than some other companies that have a monthly minimum. Right now you have to have a bank in the USA to use their services as a merchant. However, anyone can use your site with out of the country credit cards.
The SaaS Kit is now tested with Rails 3.2.2. :) It doesn't support IPN yet, but it's on to the todo list. With all the info here in one spot, I suppose I have no excuse not to get it done. :)
I am looking to implement the following;
For an Ecommerce platform build with Ruby on Rails, it is likely that there will be a situation where many people are trying to buy a product while there is limited stock. E.g. product X which will become available today at 13:00 has 100 items in stock. At 13:00 however 300 people come to the website and try to buy product X.
For these type of situations; what is the correct approach/best practice to implement a queue? What kind of technology is used? Is this possible with RoR?
use inventory locking system.
study out how Magento ( PHP based ecommerce open source ) handle all these things.
better to use Magento fro E-Commerce application. try it out once.
get back to me if you need further help.
I have been tasked with selling made-to-order products online. We have a web-based product configurator and order processing system set up that produces prices, interfaces with our inventory system, etc.
I've reviewed Magento and Ubercart and they appear to do too much; the management perceives integrating something like that as an unnecessary abstraction from what we already have going. In addition, our pricing structure is arranged in such a way that it would be an overwhelming task for me to extend the pricing system in a feature-rich ecommerce platform.
I need to be able to send an arbitrarily generated product description and price to a cart and then have it handle the sale checkout and secure payment gateway headaches.
Is there anything out there that allows that?
I ended up going with a fairly-basic Drupal site and rolled my own very-basic cart module.