Design architecture for integrating with a 3rd party payment provider

My team is trying to design an event-driven microservice architecture that allow an end-user to select a subscription type (e.g: Pro, Enterprise) from our website and buy max 5 licenses for that subscription. The payments and checkout administration will be handled by a 3rd party provider. Which can send API events via webhooks. The system needs to integrate with our existing backend systems. Scalability and security have high priorities.

This is how our existing Company and User models look like

public class Company
{
    public string? CompanyId { get; set; }
    public string ContactPersonName { get; set; }
    public string? Email { get; set; }
    public DateTime LicenseExpirationDate { get; set; }
    public string? SelectedPackage { get; set; }
    public int? NumberOfLicenses { get; set; }
}

public class User
{
    public string? UserId { get; set; }
    public string? UserName { get; set; }
    public string? Email { get; set; }
    public string? DeviceIdentifier { get; set; } // unique PK
    public string CompanyId { get; set; }
}

We would like to save licenses to Azure blob storage as well. Whenever a license is about to expire, the system should notify the customer.

Our plan is to add Azure API management along with Azure load balancer to improve scalability and security (although I am not sure if this is the best practice).

What kind of services I need to create for these system (e.g.: SubscriptionService, PaymentService, UserService, LicenseService) or is it better to design each services as Azure functions?

What would be the best approach or design practice for these services to communicate with each other?(e.g,: Azure Event Grid or Azure service bus)

How can we make the system more secure and scalable?

Azure Functions are a valid choice here and with bindings support for most Azure Services, development is heavily simplified for you. But if you prefer, you can always use your own framework/language and deploy each service using Azure Container Apps as well.

Using Azure API Management would definitely be recommended to both hide your microservices and implement common API requirements like authentication, caching, rate limiting, etc.

As for communication between the services, Azure Service Bus would likely be the best fit but Azure Event Hubs are an option too especially when you need to quickly accept events (millions) from end-users.

All of these Azure services support scaling and depending on your scenario, you will have to choose the right tier.

For security, ensure all services are secured inside a VNET and communication is primarily via APIM. Also, leverage Managed Identity to completely eliminte handling of secure strings where possible.