How to make a cart and authorization in an online store

E-commerce projects are some of our favorites. It is very addictive to think through the logic and states. We like to create comfortable and harmonious websites that help a user experience the pleasure of shopping rather than negative emotions. So we decided to compile our experience into a short post. Read on to find out what to pay attention to.

For example, a girl wants to buy a jacket, a decision that requires time. She adds it to the cart, ponders it and is ready to buy it a couple of days later. There are two possible outcomes in this case.

First (wrong one): we do not check anything, we receive payment, and when the order arrives with the money to the supplier, it turns out that the jacket is out of stock. We have to issue a refund, upsetting the girl who was already in anticipation.

What is the right way? Constantly, whenever the customer goes to the cart, notify them if the product is available. Maybe there are only a couple of pieces left in stock — you need to let them know, too.

But there is a more interesting case: various sales and Black Fridays. When the last item remains, you have to check its availability right up until the order is placed. After all, while you were entering the address, the item could have already been sold.

Another situation is paying for goods in installments, such as household appliances. Imagine that you add a TV, a sound system, and a microwave to the cart — all the items are with different terms and number of payments. Before the checkout, it will be necessary to harmonize them: for 15 months, for one year, for two months. It will be necessary to display it adequately for the user and calculate everything correctly. This is not an easy logic, which should be paid special attention to.

There should be a single point where the cart is calculated. Because it may depend on a particular user (individual discounts), promotions (e.g., additional discount when purchasing via mobile app), and others. In order not to get confused and not to lose anything, have one place where you will write all the logic, in our case it is the backend. That way, every time you change the cart, we pull the backend and recalculate it.

A person has one profile, but may access it from different devices. For example, at work they added items to the cart from their desktop, then they came home, browsed through the app some more, deleted something, added something, and the next day they decided to pay for them from their desktop — the cart should reflect the latest actions.

There are more complicated cases: a person, having logged in, browsed from a desktop account, selected a couple of items, added them to the cart. Then a few days later they opened the website in a browser on a smartphone, did not log in, looked through the website, and added two more items. Then they decided to place the order and logged in with their account. At this particular point you have to merge the two carts, which were formed in two states: logged in and logged out. But there is a nuance here.

We made the following logic: unique products with the largest amount go to the cart. So after logging in you will have: 2 blue t-shirts, 3 pairs of socks, 1 pair of jeans and 1 red sweater.

If two people use different devices and they are logged in with the same account, they will see their total when updating the cart (adding/removing items). One added a dress on their device, the other added underwear. The cart has updated, and everyone will see the dress and the underwear. The same logic is used when working with Favorites.

There should be a single point where the cart is calculated. Because it may depend on a particular user (individual discounts), promotions (e.g., additional discount when purchasing via mobile app), and others. In order not to get confused and not to lose anything, have one place where you will write all the logic, in our case it is the backend. That way, every time you change the cart, we pull the backend and recalculate it.

It is necessary to pay a lot of attention to login at checkout. Imagine you were choosing something, decided to buy, entered your phone number, logged in with your account, and started entering some data. And most often the products are displayed somewhere on the left, not in the center of the screen. And you have not even noticed that the carts have merged, the number of items has increased, and the order amount has increased.

We addressed this case in the following way. When a person wanted to log in at checkout, we would take them to the login page, then bring them back to the cart to see how everything had been combined, and only then let them check out. To be completely sure the client noticed the difference, we would send a notification.

All the situations described answer the question of why we make a single logic for the entire ecosystem on the backend. Otherwise we could have lost some data 10 times already. Another advantage is to know what goods users have in the cart when they have not placed an order for a long time, and we can do some kind of reactivation, for example by offering personal discounts.

The point of this case is that there are often situations when you need to buy something, and several people will be choosing it. For example, you are going on a picnic out of town with your friends, and everyone wants something different. You share a cart, and different people from different devices add everything they need. Or let’s take the case of renovation, when there are requests from different construction teams, and you have to buy everything on your own.

Often the logic for calculating the final price can be very complicated: for example, you have a promo code as you check out through the app, get an additional discount, and buy an item from a store that is on sale right now. As the result you receive a complicated logic that is not always worth explaining. Add some cues, and instead focus the user’s attention on how much you love them, that you are giving them the opportunity to save a lot of money.

For a long time there was a trend of login with cell phone number: after entering the number you would get a confirmation code. It seems simple and nice, especially on the user side, there was no need to bother with logins and passwords.

But the time has come for marketing to think why they need this number in the first place. Sending text messages is no longer appropriate. It is much easier and better to log in using a social network, Apple ID, Google account. After all, today it is not difficult to meet a person who does not have a physical number, especially in the case of frequent relocations. And in fact, there have long been tariffs without cell phone service, only with the Internet. Where will marketers send their text messages in that case? And who sends them now anyway? It is much more convenient to use pushes, remarketing, email — you can think about it.

In short, sending SMS is unprofitable (costs money) and unsafe. There are more and more cases of interception of codes:

• when a phone is stolen
• when a SIM card is re-issued using forged documents
• twin card creation by collusion with the operator’s staff
• SMS hijacking via exploitation of vulnerabilities in the SIM card or the phone

The second and third methods are the most widespread. Therefore, e-commerce projects should seriously reconsider their approach to login.

The browsing history, taking into account color and size, is stored on the server for potential use in the future, displaying a block at the bottom of the menu and on the product page.

In cases when the user, having logged in, added something to their history and then performed some actions, having logged out, we merge the data at the time of the next login.

The browsing history and favorites at the moment of login are merged as is for the newly logged in user with saving the date of addition and sorting by this parameter.