Recent Topics

Shopping Cart in b2evo

Started by on Aug 01, 2018 – Contents updated: Aug 15, 2018

Aug 01, 2018 11:54    

Hello, I have been using b2evo in the past for blogging ... starting around 2005 and have always loved it just for that. These days I have found a new customer who is running a store and he wants to move away from Magento to another platform. He doesn't like WP ... no wonder. I have been reading up on the newest b2evo releases and have not been able to find any plugins or skins that allow me to create a reasonably structured store front. I can't use Paypal as processing fees are way too high. Maybe I just missed something obvious? Can anybody of the experts point me towards a store integration with b2evo at the core?

Aug 03, 2018 22:47

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?

Aug 06, 2018 11:17

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.

Aug 06, 2018 12:01

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

Aug 06, 2018 15:31

@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?

Aug 06, 2018 15:41

...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.

Aug 07, 2018 09:14

@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.

Aug 07, 2018 09:51

@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.

Aug 07, 2018 11:37

@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.

Aug 07, 2018 11:41

@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?

Aug 07, 2018 12:01

@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.

Aug 07, 2018 12:05

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...)

Aug 07, 2018 12:07

@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.

Aug 07, 2018 12:11

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.

Aug 07, 2018 12:19

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.

Aug 07, 2018 15:00

@fplanque wrote earlier:

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


Thank you.

@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.

Aug 07, 2018 15:07

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.

Aug 07, 2018 15:26

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.

Aug 07, 2018 15:44

@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.

Aug 07, 2018 17:18

@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

Aug 07, 2018 18:20

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).

Aug 08, 2018 10:13

@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

Aug 08, 2018 13:09

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

Aug 08, 2018 15:00

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?

Aug 08, 2018 16:45

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.

Aug 08, 2018 16:46

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

Aug 08, 2018 18:02

@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.

Aug 15, 2018 00:54

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.

This post has 2 feedbacks awaiting moderation...


Form is loading...

powered by b2evolution – This forum is powered by b2evolution CMS, a complete engine for your website.