UML Domain Model of Web Shop

So I'm working on an assignment for school, where I am to model (using a domain model) a web shop that delivers complete grocery bags to people's homes. (http://www.linasmatkasse.se). I wish I could be more specific here, but this is all I have unfortunately.

I haven't received any use case, but the scenario would be something like, add bag to cart, create account/add info, pay.

This is what I have so far : https://i.sstatic.net/3EOIL.png

1. Are there any redundancies? (I only have to depict the model of the site, unsure how much to include).
2. Could/Should I add composition between for instance Customer and Account, Cart and OrderLineItem, Order and Cart?
3. Pretty uncertain about attributes & multiplicites in general. Any feedback or support here is appreciated.
4. Payment class? Is it needed? Should it have payment methods included?
5. Should I model human elements like support?
6. Should I model more of the delivery
7. Is association between customer and order needed?

Thanks a bunch! Again...

• It should be a class diagram. So, such verbs as "has", "contains", should be shown as aggregation, "supplies", "describes", "makes" should appear on associations arrows only if these names are the names of the attribute in the source(for arrow) class. "owns" should be shown as a dot on the end of association. Also put attribute names really on ends of the associations. You can name the whole associations, but that implies, that the association itself, without the instances of the classes, somehow exists. If you want to write comments, they are to be placed on the notes. But normally that words as "supplies", "describes", "makes", "has", "contains", "owns", appear on the Use case diagram. Make it apart from the class diagram, if you want to think on this logic or discuss it with a client or a sales manager you work with.
• Composition
  • That one between Account and Cart you have made very nicely. Thus you cay, that Cart doesn't exist out of its Account and any account has only one cart. So, the composition with multiplicity 1 to 1 is sensible and bears a lot of important info.
  • The customer as you made it, is useless. You need only Account.
  • Till now I don't understand the use of OrderLineItem and ItemList. If the use of some classes is not obvious, it is bad - at least put comments there or think, if you really need them.
• Payment - yes, it is necessary. As for payment methods, put them in the specific Enumeration class block, name them there as items and connect Payment to PaymentMethods.
• No human elements here! You are deep into the IT model, on the border of coding. You really want to do a use case diagram, don't you?

• Delivery? Maybe more enumerations for way of delivery and supplier, ClientAddress that is seen from Account, Order. It is for you to decide if you want to cover this or that scope.

• ItemDescription should be connected to Item only

• All you associations are navigable in both ways. It is senseless. Choose the navigability.

• If a class attribute is an instance of another class, put a dot on that another end of association (end owned by classifier).

• Supplier connected to Order? Do you want to cover the theme of trade with suppliers, too? Then there should be more classes on that theme. And it could be another component and another class diagram. Or is there a graphic error?