We have a site that compares flight fares and books tickets via API calls to the aggregators who provide us with flight inventory and fares. Payment for tickets happen via API calls to paymentgateways from our site. We have similar capability for hotel booking. Hotel booking and flight booking are implemented as separate services using Lumen. Since hotel booking also uses the same payment gateways as flight, we end up duplicating that code under Hotel Services. May be it is a better idea to convert payment into a separate microservice. The question is, what is the right granularity for a micro service?
The answer is, it depends. One way to answer your question is to look at how your teams are organized. Do you have teams organized around Flight Aggregation, Payment, Hotel Booking and Flight booking? If you have, then maybe it makes sense mimic this organization structure in your microservice architecture. After all, Conway's law state that this is eventually how your services would become organized any way.
Having said that, another two ways that I know of are:
Decomposing by business capabilities Decompose by business capability Context
Decomposing by business subdomain. Decompose by subdomain Context