We have it on the todo list to add a shopping cart to b2evolution (at a technical level we already moved into the direction of supporting product pages with detailed properties) but we are looking for a real life test case to drive this.

Can you tell us more about what you need?

Which payment processor would you use instead of paypal?

If I may add my thoughts?

A shopping cart needs three 'platforms'

1 ) The Shopping cart :

a ) The shopping cart
b ) The Product admin UI for adding product details
c ) The Front Office Shop where products can be browsed, viewed and added
d ) A Checkout Wizard that handles:

step 1 ) Quick login/registration
step 2 ) Shipping Address Details
step 3 ) Billing Address Details
step 4 ) Shipping Options (Plugin must be able to integrate) that comes standard with a 'collect' and 'free delivery' option.
step 5 ) Payment Paygate (Plugin must be able to integrate) that comes standard with 'bank transfer', and pay 'cash on collection' option
step 6 ) Checkout completed - feedback (Gives user thank you message with order details, additionally allow for a quick feedback/comments/recommend from user)

2 ) Payment / Paygate:

The Shopping Cart, if offered as part of the b2evolution core, must come with generic default payment options that is expandable with a plugin. This is with a plugin, because some countries offer paygate specific or only available in a specific country. (Not all sales are for the international market)

3 ) Shipment / Courier:

Additionally, Shopping Cart must come with generic default 'Shipment/courier' options that is expandable with a plugin, that is because of the same reasons as per above.

Shopping Cart Integration must cater for product details as per follow:

1 ) Width, Height, Length of the package (Used to calculate shipping cost)
2 ) Weight of product (Used to calculate shipping cost)
3 ) Colour of product (from option list)(Say you sell an iPhone is it grey or gold)
4 ) Product Model (Say you sell an iPhone is it iPhone 8 or iPhone X)
5 ) Quantity in stock (Stock control - Available / Sold Out message )
6 ) Available in country / countries select list (This product does/ does not ship to your country)
7 ) Shipping Note (Some products may have a specific shipping note/notice)
8 ) Currency Settings (Trading/Advertized currency ie "$")
9 ) Price (The price the customer will pay)
10 ) Retail Price (The price the product cost anywhere else.) Used to show you save x
11 ) Discount (Used for specials / sales )
12 ) Product Short name
13 ) Product description
14 ) This products ships free option checkbox

When payment is processed it sends an email to the user, and a order to the shop owner.

Real life use case:

There are plenty. The world is moving towards online shopping EVERYWHERE, that should be enough reason, but if you need more I have a client who owns a stationery (office supplies) shop. His clients send orders via phone, email or come in to shop. If he had an online shopping front his business will become more accessable and will increase productivity. This client uses b2e and asks me why he needs this platform if other offers him better online store options. What do I say? I have been working on a shopping cart plugin for some time now in my free time, but have to make money to feed myself and my family so it is slow going.

Here are some pictures to show how it will work. Consider this a "Draft"

Pic1) Toolbar - Shopping Cart Status - Quick view
Pic 2) Product details in Post edit mode
Pic 3) Plugin Settings
Pic 4) Shop Front in Product view (Post disp single)
Pic 5) View Cart
Pic 6) Add to cart is clicked, shows cart quick view
Pic 7) Checkout Wizzard
Pic 8) Checkout Wizzard expanded

@achillis Thanks for all the details.

Globally we are on the same page with your description of what the core needs to handle and where plugins need to integrate (payment, shipping).

Our design is to store products as Items in b2evo (same as blog posts but I think you know what I mean) with infinitely configurable additional properties (already implemented) , all that in a collection of type "Catalog" and a skin that goes with it.

The shopping cart pages would be new disps.

I have a client who owns a stationery (office supplies) shop
What do I say? I have been working on a shopping cart plugin for some time now in my free time, but have to make money to feed myself and my family so it is slow going.

If we move froward with this in the core, are you willing to test it with you client?

• How many products would he have in the catalog?
• How many different currencies would he sell in?
• What payment and delivery plugins would he need to get started?

...and my favorite pet peeve: I really don't like all these shopping carts that make you create an account / log in before telling you how much shipping costs.

So we'll do it differently ;) If the user wants to log in, fine, but he can also just select his country and get a final offer before entering details. We only need create an account when he gives his shipping address.

@fplanque wrote earlier:

...and my favorite pet peeve: I really don't like all these shopping carts that make you create an account / log in before telling you how much shipping costs.

So we'll do it differently ;) If the user wants to log in, fine, but he can also just select his country and get a final offer before entering details. We only need create an account when he gives his shipping address.

Not that I'm desperate for a cart but yes, only logging in at the last moment to give address and pay.

@fplanque wrote earlier:

The shopping cart pages would be new disps.

Yes. Agree.

@fplanque wrote earlier:

If we move froward with this in the core, are you willing to test it with you client?

Absolutely

@fplanque wrote earlier:

• How many products would he have in the catalog?

It's hard to say for me as I do not know his business and marketing needs strategies as intimately as he would and since a shopping front was not yet available in b2e I ended up doing a ton of research on a sort of general use/need and discovered a few interesting things (I will share in a bit).

I can say this though, and I am pretty sure we are on the same wave. According to my approach every product is a new $Item such as in a Collection Post Type. So one could add as many as one likes, place them in categories, search and list them like one would expect in an intuitive and organic way. The Store front would be in a way a post list showing the teaser, a photo, and the shopping cart integration, meaning the price, discount, availability quantity input, add cart button... so the user could easily shop and if wanted could click on the product for more details that will show $more / $disp = single and there comments would probably be reviews?

So based on that, is there a limit on the products one could add to the catalog?

@fplanque wrote earlier:

• How many different currencies would he sell in?

This one could be technical, but honestly my approach was to use the currencies already part of b2e, the admin would just define it in global settings and then it will be default, but this could be changed on a post-by-post or item-by-item basis?

@fplanque wrote earlier:

• What payment and delivery plugins would he need to get started?

Honestly, for the client / would be test user, there needs to be nothing complicated. Simple default options for paying via bank transfer (also known as electronic funds transfer) and Cash on Delivery. So when the user completes the delivery, they will be provided with the Shop Banking details so that they can do a manual transfer. The admin will get the order via email and then will wait for the transfer to be done on the client side and for the funds to be cleared/released on admin banking side. Does this explanation make sense to you?

The alternative option is that the client pays on delivery / collection of the order. Simple enough.

Then for core default shipping / courier options it must be simple. Either 'collect' your order at the shop /outlet (Address provided in checkout process) or 'Free delivery'.

Free delivery will be available only if a checkbox was checked on a item-by-item basis and the admin can provide a delivery notice ie "Within a 50km radius from the outlet/shop".

This way b2e can offer a store/shopping front for small businesses to operate in their immediate area that is simple to maintain after implemented. A plugin integration will allow for more advanced configurations and integrations.

Paygate Plugin

I would not burden the dev workload with providing a plugin at the same time to ship with the feature but my research shows that a plugin for a paygate must offer \ allow the following:

1) Render in the checkout process during the payment step and must offer redirects as per follow:
a) a payment successful page (ie: disp=payment-success) and redirect to checkout
b) a payment declined page (ie: disp=payment-declined) and redirect to checkout
c) A unique order number for every order, successful or unsuccessful
d) pass some params back to checkout to the user email on successful checkout such as a order number

Shipment Plugin

I would not burden the dev workload with providing a plugin at the same time to ship with the feature but my research shows that a plugin for a shipping/courier must offer \ allow the following:

1) Integrate with the checkout wizard shipping step 'option list' to the user to choose their preferred courier service
2) return params to the checkout process, such as shipping cost

Shipping Rules:

Shipping / Courier Service Companies use different formulas to calculate the shipping cost for the order but the common school of thought is that it looks at dimensional weight (volumetric weight / or space it uses ) versus actual weight and calculate for the heavier weight.

Dimensional weight is 'width' x 'height' x 'length'

Thus shopping features must cater for those input metrics

The other part of courier costs gets defined by zoning and/ or distance. With google's API one could calculate the route between two addresses and one could use that distance to calculate shipping. I have working code that can do that (calculate distance by either route or as the crow fly between two GPS lat lon or tow addresses.) Google provides something like 2000 free API requests to calculate this per day for free and has pricing plans for larger needs.

@fplanque wrote earlier:

...and my favorite pet peeve: I really don't like all these shopping carts that make you create an account / log in before telling you how much shipping costs.

So we'll do it differently ;) If the user wants to log in, fine, but he can also just select his country and get a final offer before entering details. We only need create an account when he gives his shipping address.

I agree, but I think logging in is to autofill address details for returning clients saved address (if any) to calculate shipping and is intended to make the process easier.

Keep in mind that this feature won't necessarily be used for international shipping, and could be used in limited area such as a national, or regional area.

@fplanque wrote earlier:

Our design is to store products as Items in b2evo (same as blog posts but I think you know what I mean) with infinitely configurable additional properties (already implemented)...

@fplanque will there be (are there already) some demo to illustrate this?

@achillis wrote earlier:

@fplanque wrote earlier:

Our design is to store products as Items in b2evo (same as blog posts but I think you know what I mean) with infinitely configurable additional properties (already implemented)...

@fplanque will there be (are there already) some demo to illustrate this?

New install or demo site > blog A > post with custom fields and related.

So based on that, is there a limit on the products one could add to the catalog?

No there is no limit, but if you do a site that sells 10 products vs a site that sells 100 000, you have very different expectations in how the back office processes are streamlined (creating products, variants, updating stocks...)

@achillis wrote earlier:

@fplanque wrote earlier:

...and my favorite pet peeve: I really don't like all these shopping carts that make you create an account / log in before telling you how much shipping costs.

So we'll do it differently ;) If the user wants to log in, fine, but he can also just select his country and get a final offer before entering details. We only need create an account when he gives his shipping address.

I agree, but I think logging in is to autofill address details for returning clients saved address (if any) to calculate shipping and is intended to make the process easier.

Keep in mind that this feature won't necessarily be used for international shipping, and could be used in limited area such as a national, or regional area.

As said, we are not going to prevent users from logging in if they want to retrieve their data from their account. We’re just not going to force them to create an account before telling them how much it really costs, like 90% of the sites out there still do.

How many different currencies would he sell in?
This one could be technical, but honestly my approach was to use the currencies already part of b2e, the admin would just define it in global settings and then it will be default, but this could be changed on a post-by-post or item-by-item basis?

You did not answer the question. It is very different to select 1 currency from the list vs requiring exchange rates or multiple prices per item.

Honestly, for the client / would be test user, there needs to be nothing complicated. Simple default options for paying via bank transfer (also known as electronic funds transfer) and Cash on Delivery. So when the user completes the delivery, they will be provided with the Shop Banking details so that they can do a manual transfer. The admin will get the order via email and then will wait for the transfer to be done on the client side and for the funds to be cleared/released on admin banking side. Does this explanation make sense to you?

Yes. That part will be easy then ;)

Paygate Plugin

I would not burden the dev workload with providing a plugin at the same time to ship with the feature but my research shows that a plugin for a paygate must offer \ allow the following:

I am asking because we’ll need to provide one reference plugin so it’s easy enough to adapt to other payment gateways. So the more samples of paygates people want to use we get, the easier it is for us to make an informed decision about the reference plugin.

@fplanque wrote earlier:

New install or demo site > blog A > post with custom fields and related.

@fplanque wrote earlier:

No there is no limit, but if you do a site that sells 10 products vs a site that sells 100 000, you have very different expectations in how the back office processes are streamlined (creating products, variants, updating stocks...)

I see, again you think far ahead. Is it more practical to to address this now or expand the feature as the need grows? For the companies I have this in mind, there will most likely be products under a thousand. I would even say two hundred or less.
To cater for a large number as you pointed out it will almost be like a mass edit layout?

@fplanque wrote earlier:

As said, we are not going to prevent users from logging in if they want to retrieve their data from their account. We’re just not going to force them to create an account before telling them how much it really costs, like 90% of the sites out there still do.

I think this is an extremely productive approach as during my research I discovered many people had complains around the same issue. Some orders the shipping costs more than the product and they abandon the checkout and on top feel grieved because it was an intense process to get to that point. An effective shop will make this process as simple and pain free as possible.

@fplanque wrote earlier:

You did not answer the question. It is very different to select 1 currency from the list vs requiring exchange rates or multiple prices per item.

Okay, I understand but again I thought it should be as simple as possible to start with and I can't even begin to ponder on the technicalities with an ever changing exchange rate. My thoughts were that admin selects and display a single currency of their country origin and that the user would need to do an exchange calculation. Like in South Africa I have bought items in the USA and paid in dollars.

I know that there are some shopping carts that will do and display a price in your local currency by means of a drop down list. To be completely honest I have not completely applied my thoughts to this.

@fplanque wrote earlier:

I am asking because we’ll need to provide one reference plugin so it’s easy enough to adapt to other payment gateways. So the more samples of paygates people want to use we get, the easier it is for us to make an informed decision about the reference plugin.

You are very thorough and obviously think 5 steps ahead. I have requested a developers guide from a paygate service here in South Africa and can forward it to you? in a nutshell they require what I explained before, an approved redirect or a declined redirect, a unique order number for every order and then of course there are params passed.

For Paygate Plugin integration here is the transaction flow from a developer's guide for a service in South Africa (SA):

The transaction flow is as follow:

 Once the customer has completed the shopping process the merchant’s website must display a button showing for example, “Proceed to Payment”.

 When the customer clicks the “Proceed to Payment” button the merchant’s website diverts the customer’s browser to VCS passing a few parameters.

 The VCS website forces the browser into a secure mode and displays the payment methods offered by the merchant, e.g. credit card and MasterPass.

 The customer selects which payment method they wish to use.

 VCS displays a form requesting the necessary information for the payment method chosen by the customer.

 If credit card is chosen a form is displayed requesting entry of the customer’s information.
The customer enters their information and presses “Pay”.

 VCS performs a lookup in the MasterCard / VISA 3D Secure directory, and if necessary, performs the 3D Secure authentication process.

 VCS connects to the merchant’s acquiring bank and requests authorisation for the transaction from the issuer of the card.

 VCS diverts the customer to the merchant’s website, to an “Approved”, or a “Declined” page, depending on the response from the acquirer.

VCS can also enter the transaction into a call-back queue which operates independently of the browser to notify the merchant’s website of the result of the transaction.

You probably already thought of this, but the stats feature should integrate with the shopping cart to show admin how many carts were abandoned and if so at which stage? Also stats for completed/successful and declined transactions.

I vaguely recall coming across a case study on shopping carts and at which stage users abandon the process and it was around the shipping costs / shipping calculation phase but I can't recall what was the most common reasons. It could very well have been that users didn't want to login/register before knowing the final price tag.

https://www.barilliance.com/10-reasons-shopping-cart-abandonment/
https://www.granify.com/blog/shopping-cart-abandonment-11-reasons-happens-fix

@achillis

For the companies I have this in mind, there will most likely be products under a thousand. I would even say two hundred or less.

ok thanks, then we can focus on other areas that mass product management for now ;)

My thoughts were that admin selects and display a single currency of their country origin and that the user would need to do an exchange calculation.

ok.

What about quantity discount? (like : lower price if you buy more than x) Do you need this already?

I have requested a developers guide from a paygate service here in South Africa and can forward it to you?

yes please.

@fplanque wrote earlier:

What about quantity discount? (like : lower price if you buy more than x) Do you need this already?

Yes, that is needed. Will be interesting to see your approach on this.

Also a discount field. For example you have a special on a specific product and if the product's normal price is $10 you add a '10%' in the discount field in back office then in the front office it will show $9 and a 'on sale' icon/message?

I sent you a PM for the paygate dev guide

The idea (not final) is this:

Probably we need to store price in multiple currencies and also discount prices if user buys large quantities.

So maybe we can have multiple prices defined by currency and min_qty like:

• EUR, 1 : 1.59 €
• EUR, 5 : 1.49 €
• EUR, 10: 1.39 €
• USD, 1: $ 1.79
• USD, 8: $ 1.59

So if user buys 9 items with a cart in EUR, then he will pay 9 x 1.49 €.
If user buys 9 items with a cart in USD, then he will pay 9 x $ 1.59.

Also a discount field. For example you have a special on a specific product and if the product's normal price is $10 you add a '10%' in the discount field in back office then in the front office it will show $9 and a 'on sale' icon/message?

I guess we also need start & end dates for the "sale"/"discount" ?

This will also solve the case of the "normal / strikethrough" price that no-one pays. You can just override it with a "permanent sale" (no end date).

@fplanque wrote earlier:

So if user buys 9 items with a cart in EUR, then he will pay 9 x 1.49 €.
If user buys 9 items with a cart in USD, then he will pay 9 x $ 1.59.

Very clever, how will you allow its configuration, because it seems like it could have many different combinations depending on the quantities. Will it be a dynamic input field that gets added for each 'rule', (perhaps like an input group) or would it be a text area with each rule on a new line?

@fplanque wrote earlier:

I guess we also need start & end dates for the "sale"/"discount" ?

Perfect! Another think on the go is promo codes? Any ideas on that and how that will work/ if it is something you would like to think about now?

@fplanque wrote earlier:

This will also solve the case of the "normal / strikethrough" price that no-one pays. You can just override it with a "permanent sale" (no end date).

Great

My current thought on promo codes is that they will apply as extra lines (negative lines) on the shopping cart. Therefore I feel we can deal with them later.

Rough thoughts: a promo code has these properties:

• code itself
• validity dates
• applies to what?
  • all products in cart
  • products of specific category
  • products with specific tag
  • List of specific products (item IDs)
• minimum value for coupon to apply (multi currency issue)
• percentage off
• amount off (multi currency issue)
• currency / currencies the coupon applies to
• coupon category (any text code) : Coupons of the same category are mutually exclusive

I see what you mean.

Just maybe, the promo code feature could potentially be allowed as a plugin?

At this stage I don't think its a priority and if it were included in the design it will be more of a bonus than a requirement/deal breaker. But with that said, keeping it in mind, you will apply your genius towards allowing its integration in the future?

The irony is that the choice lies between:

• developing a plugin architecture, supporting it AND developing a test plugin for it, which is complex enough to test the thing and then hope for someone else to develop and maintain the full feature we need
• and just developing the part what would go into the test plugin (or sth marginally more complex)

See what I mean?

Plugins make much more sense when there is a virtual infinity of outside connectors that we cannot foresee (payment processors, shipping services... and in past examples: social networks, video formats, ping services... etc).

With coupon codes, I don't think there is a lot of variety.

PS: other payment methods that should probably be built in: store credit & gift card.

@fplanque wrote earlier:

With coupon codes, I don't think there is a lot of variety.

Thank you for explaining and highlight a very important aspect that I did not even consider.

@fplanque wrote earlier:

PS: other payment methods that should probably be built in: store credit & gift card.

Yes indeed, developing and implementing this is no small feat.

Quick update: All this will be in b2evolution 7. We're currently making progress on the "catalog" skin which is designed to browse a product catalog as well as on the shopping cart (tons of new widgets). Price calculations come next. Then the shipping options, then the payment, then the order tracking.

Wow!

@fplanque wrote earlier:

Quick update: All this will be in b2evolution 7.

I have been following your progress on b2evolution 7 and there has been some extensive, and if I may say, impressive work done. One of the b2e users said at some point that the core code is really beautifully structured/ written and this not something everyone will appreciate, but is indeed a work of art.

Considering your goals for version 7 and the progress made, will we see it released this year or do we need to wait for it along with Game of Thrones until next year?

V 7.0 will be this year. Shopping cart may be only in 7.1 but should also be this year.

@fplanque wrote earlier:

If we move froward with this in the core, are you willing to test it with you client?

I was prompted by another request on this feature by a different client and would appreciate any thoughts you may have on this.

A client who supplies a range of frozen vegetable products is currently running on b2evolution and asked me if the platform could offer a feature where his clients could place orders online. I explained the feature currently being developed (Shopping Cart) and how it will work. He indicated that it sounds great but asked me a question that I would like to forward on to you.

He sells his products to roughly three different groups:

1) Retail (directly to the public),
2) Whole sales, (Supermarkets selling to the public)
3) Distributors, (other suppliers who sell to their own clients )

The price on each product is sold with a different price depending on which 'group' the client belongs to.

When I look at b2evolution, admin could create different user groups such as moderators, editors, normal users... here admin could create a group each for the different type of client, or alternatively use the organization feature to create different client groups...

@fplanque my question to you is if the shopping cart could possibly cater to list a different product price for each client type as described above?

So basically it will display a generic price for anonymous (not logged in users) users (Group 1) but if a user who has supplier status (Group 3) log in, he/she will no longer see the generic price but the price allocated to his group type instead.

Looking forward to hearing your thoughts on this.

Sample idea layout

@achillis are they really going to carefully enter 3 different prices for each product or do they give a discount to distributors and suppliers? (in which case it's much easier to solve with an automatic coupon for group X which automatically applies a discount of x%)

@fplanque wrote earlier:

it's much easier to solve with an automatic coupon for group X which automatically applies a discount of x%

@fplanque I don't think your proposed solution will suffice because the price difference between the various 'groups' are not percentage based, but rather from product to product.

@fplanque wrote earlier:

@achillis are they really going to carefully enter 3 different prices for each product

In this case, the client will not list many hundreds of products but rather below a hundred and therefore managing it product-by-product basis will be fairly straight forward so I guess my answer is yes they will carefully enter 3 different prices for each product.

In that case we'll have to factor that in into our "price exceptions" list (by "exception" I mean: exception for quantity >= x, exception for currency == x, exception for coupon == x, exception for user group == x...)

Another exception: promo start & end dates.

Firstly, thank you for the pricing rules. That is perfect.

I know that this is an ongoing (developing feature) so my question might be out of context or irrelevant so please forgive me, I am just curious about one thing:

Availability

is this feature catering for a quantity field that will be auto calculated on the checkout process?

For example there are 100 items in stock for product: A.

1.) If a client buy (checkout) 99 items for Product A, will it reflect "Only one left in stock"?

2.) If a client buy (checkout) ALL Available items for Product A, will it reflect "Out of stock" automatically?

The ideal would be that the system accounts for the stock automatically, subtracting as it is sold and even send out an email to admin (or whom ever the assignee is) that there are only x amount left for product A, or that product B is sold out meanwhile automatically changing the notification in Front Office from "In Stock", to "Only 10 left" (or what ever alert limit is set) to "Out of stock"

Then my last question, out of curiosity. What happens (or is recommended) if a customer completes a checkout and some of the ordered items has been sold out in another (parallel) checkout process?

Hi Excuse me for butting in.
First off. The the database will be updated as the order is placed, before payment is a made but reversed if payment is cancelled. And yes email the stock controller once item is paid for.

As for parallel ordering, that shouldn't be a problem. If the server and database work quick enough and the database can only take one update at a time the then item count will always reflect what is available

It will take a few steps

1. order A > database decrease
2. 1 millisecond later order B - onclick reads new data and confirms availability
   Irrespective of whether order A checks out order two now has confirmation of availability priority over next order
3. Orders A and B will need to be notified that 'if the order is not paid for in 10 minutes' the item is reallocated back to the store.

Hope my views are not out of place??

Availability and stock control are a very separate process from pricing.
We have not implemented this yet.
Yes, in order to avoid selling the same item twice, we will have to lock items in stock for some period like 10 minutes while payment is completed.

@fplanque it seems I confused things for you a bit. I am aware that pricing and stock are two separate processes. I meant to say thank you for the pricing process and then move on to another different aspect.

Thank you for the feedback.

@amoun your views or input is very welcome. Thanks for that.

no problem.

1.) If a client buy (checkout) 99 items for Product A, will it reflect "Only one left in stock"?

Yes (at checkout, not when item is placed into cart)

2.) If a client buy (checkout) ALL Available items for Product A, will it reflect "Out of stock" automatically?

Yes and if "can order when no stock" is disabled it will be a "Sold Out" status.

@fplanque wrote earlier:

> 1.) If a client buy (checkout) 99 items for Product A, will it reflect "Only one left in stock"?

Yes (at checkout, not when item is placed into cart)

Referring to my earlier comment I would like to see item count updated as it is placed in cart so that another customer cannot act quicker and get to the checkout first, hence the idea that the count would be reduced with a warning that if checkout isn't completed within 10 minutes the item will be returned to the store.

Otherwise it is like someone stealing from my shopping basket as I'm waiting at the till :(

@amoun wrote earlier:

...item count updated as it is placed in cart so that another customer cannot act quicker and get to the checkout first, hence the idea that the count would be reduced with a warning that if checkout isn't completed within 10 minutes the item will be returned to the store.

This proposal does make more sense to me as it relates back to my earlier concern re parallel processes. I.E. There are only one item in stock but 2 customers has it in the cart? It just seems like updating the count on adding it to the cart and rolling it back if 'not checked out' seemingly would require much more complexity.

@achillis wrote earlier:

@amoun wrote earlier:

...item count updated as it is placed in cart so that another customer cannot act quicker and get to the checkout first, hence the idea that the count would be reduced with a warning that if checkout isn't completed within 10 minutes the item will be returned to the store.

This proposal does make more sense to me as it relates back to my earlier concern re parallel processes. I.E. There are only one item in stock but 2 customers has it in the cart? It just seems like updating the count on adding it to the cart and rolling it back if 'not checked out' seemingly would require much more complexity.

I guess the available C) quantity will be whatever is in A) database after deducting B) what is in the locked cache? This way the database is updated after checkout and payment is completed and the transaction is cleared from the cache?

Sorry, bad math. See revised figure. Anyway, you get the idea. It will be interesting to see the approach decided on.

You guys are neglecting a key difference between a real world shop and a web shop.

The web shop may as well have more robot crawlers than human shoppers. If you reduce stock when bots place items in their carts, you make items unavailable to real humans.

AFAICT it’s the best practice in the industry (to not allow spam stock manipulation).

And we’re not going to ask for a captcha when placing an item into the cart. Do I need to explain this would be detrimental to conversions?

Even worse industry practice: If there is 1 item in stock and 2 customers buy it “at the same time », Amazon lets both transactions complete and one will have the bad surprise of unexpected delays in delivery and/or refund offer. I’ve seen it several times.

I see your point @fplanque Well played.

Ps. In the real world shop there are pesky shoplifters to deal with d:

OK :)

ok, time for an update I guess.

This branch : https://github.com/b2evolution/b2evolution/tree/7.0feature/catalog-skin has had a lot of new developments.

At this point we have a proof-of-concept payment processor plugin using Stripe for credit card processing.

We also plan to make a plugin for processing payments with Paypal.

Additional payment processors could be added with custom plugins.

It will be possible to use several plugins simultaneously in order to accept various forms of payment.

One thing I haven't come to peace with yet: I was expecting payment processors to provide the billing and/or shipping address they might already have on file so we don't have to ask for it. This seams sort of feasible with Paypal but not really with Stripe. So I guess we'll have to do like so many others: ask the shopper to enter an address before payment :/

Will the feature come with built-in shipping options, for example such as:

1) Collect from the store
2) Collect from a distribution point

This will obviously require the shopping cart to define addresses for those delivery/pickup points, in which case the $Item owner would need to define a delivery address?

NOTE: Some credit card transactions, to my knowledge, requires the user to specify address details for the credit card holder.

Then on another question:

Will the shopping cart $Item allow the $Item owner to specify which countries the item is available or unavailable for? This would obviously integrate with the GeoIp plugin and the specified delivery address.

@achillis wrote earlier:

Will the feature come with built-in shipping options, for example such as:

1) Collect from the store

This one is already implemented (as a standard and very basic plugin).

2) Collect from a distribution point

That should be doable by a plugin.

This will obviously require the shopping cart to define addresses for those delivery/pickup points, in which case the $Item owner would need to define a delivery address?

Are you thinking about a different address for each item? Or a set of addresses for the store.

NOTE: Some credit card transactions, to my knowledge, requires the user to specify address details for the credit card holder.

Yes but that is completely handled on the payment processor side and they make it extra not convenient to connect that card address with an actual billing or shipping address.

Will the shopping cart $Item allow the $Item owner to specify which countries the item is available or unavailable for? This would obviously integrate with the GeoIp plugin and the specified delivery address.

Why per Item and not per Shop?

@fplanque wrote earlier:

Are you thinking about a different address for each item? Or a set of addresses for the store.

I think what would make most sense is an addresses for the store, however if for example, I have an online store but have different branches where an order may be collected, how will that work?

@fplanque wrote earlier:

RE: "specify which countries the item is available or unavailable", Why per Item and not per Shop?

I know from ordering via amazon, that some of their products doesn't ship to my country, so the user can't order it, or can't have it shipped. I think it has to do with distribution rights/licenses and customs requirements, but my guess is speculation only.

@achillis
many items are 'illegal' across borders, guns, marijuana, alcohol, sex toys etc.

if for example, I have an online store but have different branches where an order may be collected, how will that work?

As written above: "Or a set of addresses for the store.". But there are several pickup addresses attached to the store in general, not to each Item!

I know from ordering via amazon, that some of their products doesn't ship to my country,

That's because Amazon is not an online store. Pause to let it sink in. It's a marketplace. It has many different vendors on the same site. Some are not equipped to ship internationally. Some do not want to support the logistics costs of having their items stores in multiple warehouses internationally.

At this point we are considering building an online store with b2evolution. Not a marketplace.

many items are 'illegal' across borders, guns, marijuana, alcohol, sex toys etc.

I'm going to consider it an edge case that you will be selling both cell phone covers shipped internationally and guns -- heavily restricted -- in the same store.

@fplanque

In terms of addresses, I was never referring to each item, but for the order / transaction.

Then in terms of availability of items and country of shipping, I am not interested in arguing semantics around market places vs online shops. I brought something to your attention that may be worth considering while this feature is being developed. It is your prerogative if you feel it is necessary (useful) or not.

@amoun

I was not referring to illegal items. I was referring to instances where some items are subject to distribution rights. In my experience I was not able to order a Canon DSLR body, but was able to order DSLR Lenses. There are reasons why that specific Product would ship to the US and not to ZA. Think authorized or accredited distributors.

I might be able to ship Furniture to one country, but not to others, because of risk for cross border spreading of species of wood eating insects... customs restrictions... I am tired of explaining. Think on it.

@fplanque can we get an progress / release update?