Don't start with tables. Start with the attributes/fields you need to support the use case - what do you need to about what? For example, contact info, billing info, shipping info are pretty vague. You could just store them as chunks of text, and I guess then you're done, but in actual use people usually want to query things by city or country or area, or produce lists of telephone numbers. Breaking the information up into pieces for which the possible values are clearly defined makes it much easier to work with later.
When you know what you need to know, look at how the attributes are related. What depends on what? This will guide you in choosing which tables to build.
The "shopping cart" table isn't done, but I'm not sure how I should do it and be able to show quanities. The only thing I can think of would be adding another table named "sku" with all the info. Is that alright or would you do it differently?
Primary key is accountNumber for the "account" table, orderID for the "order table, not sure about the "shopping cart" table yet. Foreign key is "orderID".
That looks better, though some normalization could be applied. An sku table could work for product information, but this one case where normalization isn't desired. Product description and pricing, though it has to come from somewhere like an sku table, should not be updated as the current list changes. Perhaps also add a field for the ordered quantity.