[Database Schema] https://i.stack.imgur.com/QaRry.png
I will use this database to build a website using Laravel Framework.
As others mentioned this is too broad to answer.
But I can give you some pointers to remember.
Normalization
This is the primary purpose of relationships. Basically this is not duplicating data, so you wouldn't put a state in every address you would have a state table and put it's id in the address.
You have some of this, but you can over normalize too. Like the payment status. Likely these wont change much over time so you could use an ENUM field which is basically a text field with a list of acceptable values in it.
Pretty much if you have a One to One relationship, you don't really need another table for it. The only reason I can think of was back when InnoDB didn't have full text support, then you could make a MyIsam table and a InnoDB table to kind of use both their benefits. Otherwise it just makes things harder because you have an extra join, and you have to make user that you tables dont become a Many to One relationship.
An example in yours is Orders and Delivery Addresses, this would probably be a one to one, it's not like you can deliver the same item to more then one address. Your probably thinking, I can reuse those addresses for different orders, but if you read below you might see why that is not always a good idea. Which is not saying you cant use them again, you just probably shouldn't allow edits to them and that can cause a whole cascade of issues.
Consistancy
When dealing with things like orders, you should bake as much data into the table as you can. This is de-normalization. But the reason is that, products can be deleted addresses can change etc. You don't want these things affecting your orders later. So by baking that data in you don't have to worry about not being able to change those things. Obviously you still want some links like to the User but you may want to bake in the email they used for that order, that way latter if they say I didn't get the email, you can know what email was used not the one they currently have, maybe they changed it.
Hierarchies
This is specifically for the category table, you may want to look at some of the hierarchy models like nested set, or adjacency list. This will eliminate tables and allow more nesting levels. It's quite a bit harder to setup, but it's way more flexible.
Another choice is to use something like a tag system, where you have a list of tags and associate those with the products through a many to many relationship. I think we all know what tags are but if your not sure, than look at the tags on Stack Overflow. These can help improve search results and help tie related products together even if they are in different categories. For example you could have
veggies > potatoes
utensils > potato peelers
They are related, but you probably won't put them in the same category.
You could even use both!
from my experience, when you are developing an online store, the information about orders should be stored separately, not with relations let me give you an example:
i order product A, my order is being processed, meanwhile, you delete product A from your database (different reasons), if you have the product_id in my order, what will happen?.
Also, you should make an intersection table for users and payment details, they may have more credit cards. An intersection table for users and delivery addresses would also be easier to manage than a text colum