The point of use cases is to start thinking in more detail about the actual steps that go into achieving the user's goal. You haven't really done that work yet.
Each of the things you list might be the name of a use case, but you need to describe the process involved.
You need to think about the question: what does the user need to do in order to make a hotel reservation?
There are a number of things a user might need to do (depending on your software).
- Search for a hotel that meets certain criteria.
- View hotel information.
- View availability.
- Request a reservation.
These are the sorts of things that might appear in a diagram. The level of detail can vary according to your needs and preference, but if you aren't breaking a task down into steps, you aren't really using use cases.
Things like log in and payment might be quite relevant to the design and operation of the site, so I wouldn't omit them prematurely. Questions may come up such as:
- Does the user need to log in or is there a path where they can make a reservation as a guest?
- If the user does need to log in, at what point in the process is required?
- Do you have to pre-pay for all reservations, or are there different options?
- What is the process if payment fails?