what are the must have functionalities for an e-commerce web shop?
e.g.
unlimited categories and sub categories
multiple categories per product
multiple product images
product consumer ratings and comments
payment gateway integration
delivery service integration
Best Sellers
Newest Products List
discount facilities
promotional facilities (buy one get one free)
I know we shouldn't just link to elsewhere, but this link is within stackoverflow. I'll just quote it all here:
Do you need to build one at all? Most of this has been done for you in
various shopping cart packages
including google checkout,
oscommerce, and others, but if
you must take the plunge try to at
least think about the following...
Secure session for users
Storing 'items' in the cart via the session / cookies
Payment processing
what external systems do you interface with
what kinds of payments do you accept
what currencies do you accept
Some kind of dispatching system for when a purchase occurs
If a purchase occurs, who is notified to mail out the items?
where is the purchase logged?
Interaction with an inventory system of some sort
is the item in stock?
what to do when out of stock?
Total / shipping calculations
how much do you charge shipping for different customers/destinations
where do you want to ship / where will you not ship
A shopping cart is far more complex a
concept than it appears to be. The
specific answer to these questions
will depend on what kind of
organization you are working for. Big
company? Small startup? Family
business? High volume vs low volume?
Etc.
Related
New here and i hope i am in the right place to ask my question. We are having problem with submitting our app to Shopify App Store.
We have an app where people can create their own designs on our physical products and sell. So we can produce their products and dropship to their customers. There are many apps to that.
Problem is they forcing us to use Billing API for our product charges. They take 20% of commission which our margin is not that much. We are wholesaler and we our margin is super low. We use (well we were planing to use) Stripe for products charges, which is 2.9 % commission.
And Shopify Apps Team member is keep asking me my margin, and says: "We are requiring that all apps use the billing API, but I might be able to make an exception since it seems like your business model isn't compatible. If an exception is made, you will be required to sign a revenue share agreement based on your margins"
All other App (in our business line)they charge their customers with 3th party payment processors and i have spoken with some of them they say they never heard about it and they don't share any revenue (apart from membership fees) with Shopify.
Any idea about this?
Thank you so much for you help.
Shopify is charging 20% of the cost of the app not 20% of the cost of your finished products. I don't know if your app can be free and still in the app store but from what you have written free would work since you will actually make your money on the goods. Just bill normally for the orders you receive
I have described requirement flow using diagram http://creately.com/diagram/example/ifrthu1k1/Flow. I need help in figuring out which app helps in fulfilling my requirements.
In brief my requirement goes like this:
Our system contain multiple cities
Each cities can have one or more Central Distributed Center (CDC)
Each CDC will have one more Districuted Center(DC)
Each DC will serve customers belong to one or more regions identified by Zipcodes.
Each DC will have some set of products.
product mangement in inventory is done using barcode scans. (Good to have feature)
Inventory(for DC) planning - which product sold more/less. (Good to have feature)
Easily diffrentiate expired product.(Good to have feature)
This is a bit of a cart before the horse situation. What you really need is some sort of fulfillment management system. Usually this is part of your ERP (something like Intacct, Netsuite, or SAP) but for smaller businesses with fulfillment being handled by a 3PL you might need to integrate orders with that instead. Once you have a fulfillment management system in place you can integrate that with Shopify via the Shopify API to update Shopify's inventory and allocate Shopify Orders to the appropriate fulfillment center.
So the steps would be:
decide how you are going to manage the accounting and fulfillment side of your business.
Integrate that system with Shopify.
we have created a publishing platform that is similar to Zinio,
We have a website where we upload magazines, and publish them to our mobile App on iPad
Apple is rejecting the App for the following reason:
Apps that use IAP to purchase items must assign the correct Purchasability type We found that the Purchasability Type for one or more of your In App Purchase products was inappropriately set, which is not in compliance with the App Store Review Guidelines.
Your In App Purchases are set to Consumable.
However, based on product functionality, it would be more appropriate to use the Non-Consumable In App Purchase type. Non-consumable products are only purchased once by users and are always available on all devices that are associated with that user's iTunes account.
We have Replied and Explained them Several Times the following:
We are using consumable type of in-app products since we have a lot and frequently released magazines with different prices therefore we cannot define the purchases to be non-consumable.
We have set pricing Tiers from $0.99 until $54.99 so that each magazine will be classified appropriately and assigned to a certain Tier.
our system has a lot of magazines where each one has many issue releases. Magazines issues are sold within an offer.
We have "single issue offers" (offers containing only one magazine issue) and "multiple issues offers" (offers containing multiple isses, eg: get 3 digital issues of magazine x for $19.99).
We are using the Tiers from 1 to 55 to assign prices for our offers. Note here that the in-app purchases are consumable but our system won't let the user buy an already purchased item another time.
The application will contact our server each time when the user attemps to buy an offer.
If the offer is already bought, the application won't proceed with the in-app purchase and the user will be shown that he has already bought that offer.
Anyone has an answer to solve this problem?
As apple is insisting that we should not use consumables and use non-consumables which is not logical, as we need to be submitting the app every time magazines has been added to the system.
Help is Much Appreciated
For magazines, you are unlikely to get consumable in-app purchase ability from Apple. They've made it clear in the past that the expectations for media, levels, and content of this type are expected to be present on all of the users devices.
However, based on your description of what you are trying to do, I'm not sure that this is a problem. Remember that consumables are not the same as subscriptions, in that a subscription gives you access to potentially more than one issue, whereas a consumable just means that is something that may not be available after you purchase it, I.e. that it might be consumed.
It sounds like the real problem here is a catalog issue. For episodic content, such as magazines, you don't want to hard-code your in-app purchases, instead look at the server-based model, as described in:
http://developer.apple.com/library/mac/ipad/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html
With this model, your server can return a list of product identifiers that meet certain criteria, so you don't have to constantly update the app.
I'm building a marketplace application:
The customer pays the seller on the marketplace
The marketplace takes a cut of the payment
I would have a payment processing system with the following features
The cut and the 100%-cut are sent directly to the marketplace and seller accounts (ie, I don't want to have 100% on the marketplace account and then to forward the 100%-cut to the seller)
I would love to have a UI as much integrated with the marketplace website as possible. This implies that the customer in the worst case has to put only name, surname and credit card number on the payment processor interface (the ideal would be a payment interface totally integrated with our website)
I don't want to force the customer to register to any third party service
It should work nicely with Ruby on Rails
It should work for non US-based companies and should support multicurrency payments
What are the options out there?
Thanks.
I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
At a high level payments in are done via credit card like a normal payment processor, funds are deposited into an escrow account which is a sum of all funds collected - all funds disbursed. When you're ready to push funds out you can currently pay out via next-day ACH (US only) but we're building out international support which sounds like it would be useful for you.
I believe it matches your other requirements:
there is no requirement to send users offsite, they do require accounts but you can create and edit them via the API.
Balanced has an excellent ruby gem
You can split up the payment, taking a cut from the proceeds as profit
Balanced provides you with a merchant dashboard for you and your customers to get a head start but you can build the exact same thing via API access.
One area where it's not going to meet your requirements is multi-currency charges. Currently you'll need to charge in USD and convert.
Check out https://github.com/drhenner/ror_ecommerce It doesn't have all the features you want but will give you a big head start.
Basically active merchant will connect to most gateways. You need to add the custom code. Look at the video for more help http://ror-e.com/info/videos/1
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.