MYSQL food ordering portal database design
First: don't code, draw.  It's much easier to make mistakes in diagrams than it is to try and visualize relations, keys, etc. in code.  At this point in design column types are irrelevant.  Focus on keys and relations.
This may be a good starting point*:

Here we have customers who can place orders for restaurants.  Those orders cannot contain items not offered by that restaurant.  Those orders can include the same item at different prices (buy 1, get 1 50% off, etc).  Those orders can include fees, including delivery fees which can be looked up from a schedule.
Questions not answered by this diagram:

How do we determine if a OrderLine is a menu item or a charge and enforce that?
How is the status of an Order defined?
What exactly encompasses OrderLineCharge?
Should the order request a menu item/quantity which is then becomes an OrderLine?
When an MenuItem is requested but can't be fulfilled, what happens?
How are price changes stored?
Should we track types of cuisine or categories of menu items?
How is delivery tracked?
How are payments tracked?
How do we track quantity discounts ($2 each, 3 for $5, etc)?
Should it be 'OrderId' or 'OrderNumber'

That is a lot of questions we won't solve with lines of code or table definitions, at least not yet.
The next steps I'd recommend are:

Familiarize yourself with ERDs, specifically IDEF1X which are easily read and understood
Start thinking about business rules and how they might shape your data model - what problems can you solve through constraints/relations?  Which problems will require the transactions to contain rules?

*I'm leaving a lot out because this isn't something that can be answered in one step - I don't know if this is a homework assignment, hobby project, or actual work.