Powering a leading payment platform with event-driven architecture

The digital payment platform is built using microservices and leverages event-driven patterns for real-time automation and insights into payment processing.

While the payment platform consists of more than 25 microservices in totality, this case study will focus on a subset of core services to highlight the value of event-driven processes that occur within the platform.

These include the:

• transaction service: which produces and consumes events to facilitate customer orders and accept various payments.
• reporting service: primarily used by merchants in a self-service portal, producing and consuming events for real-time display of transaction and payment information across a variety of channels.
• risk assessment service: which produces and consumes events while determining the potential risk associated with orders and payments.
• notification service: which produces and consumes events while automating communications to highlight the status, or changes in status, of orders and payments.

Whenever an order or payment is processed in the transaction service, it sends out a variety of events (which can be thought of as ‘triggers’ containing data for subsequent, automated processes) to the event backbone, Azure Event Hub. The event backbone, in turn, fires events to services which are configured to ‘listen’ to them. These listening services are configured to consume specific events related to their core business function; it’s a ‘pull’-style configuration, rather than the ‘pushing’ of data packets.

Learn more about ‘receiver-driven routing’ in events

For example, if the transaction service processes 50 payments from one personal account number (PAN) in 10 minutes, an event is produced to notify the risk assessment service to take action to prevent the fraud (see section 03. ‘Using events for real-time fraud detection’). The reporting service may ‘listen’ for the same event, and provide an update that a certain payment or account is potentially compromised.

Examples of event-driven processes include:

• All payment processes in the transaction service. This means the complex workflows associated with payment submission, authorization, transitioning payments into escrow accounts, merchant capture, and credit reversal callback are all seamlessly automated and tracked in an immutable log.
• Transactional emails, SMS messages and merchant notifications are fully event-driven, ensuring both customer and merchant have real-time updates into payment status and processing.
• Advanced risk rules are evaluated using events to detect and prevent potential fraud in real-time.
• Events trigger updates to card management systems for reversal of any voided transactions.
• Recurring and subscription payments are automatically triggered using events.
• On successful completion of payment, the transaction service generates a series of events for reporting purposes. This includes everything from creating an immutable trail of payments for merchant recordkeeping, to generating reports and adding to computed dashboard data.

Picture the scenario: you run an online retail store, selling high value homewares like televisions, watches and cosmetics

A customer visits your eCommerce store and orders a TV. By submitting their card details, a series of events are immediately triggered to start validating the payment.

On payment capture, a series of events are triggered to automate notifications to both you and your customer.

While the notifications are being prepared and sent—which only takes a couple of seconds—all of your reporting is updated in real-time with detailed information highlighting the nature of the payment. You receive a notification, and you can view the information in your self-service portal.

Critically, the varying steps in these payment validation processes can occur asynchronously in event-driven architectures.
Structuring the payment process as a series of decoupled, independent mircoservices creates two crucial benefits;

1. 1. Speed, and
   2. Reliability of processing.

Firstly, the various, complex steps involved in validating payments can occur in a non-linear way. This makes things faster overall, especially when compared with traditional sequential or synchronous processing.

By their nature, event-driven architectures are ‘fire and forget’. In other words, there’s no compulsory requirement for a microservice to wait for a response before initiating the next step in a sequence.

For example, the transaction service might receive a payment, fire an event to the reporting service to create a log of that payment being received, and begin the process of validating that payment. This process can occur entirely independent of the reporting service acknowledging to the transaction service that a log has been created and saved in the reporting database.

These efficiencies may seem small in isolation, but at scale—when large enterprises or national retailers are processing tens or hundreds of thousands of payments per hour—the impact for processing and customer experience can be huge.

For example, the transaction service might receive a payment, fire an event to the reporting service to create a log of that payment being received, and begin the process of validating that payment. This process can occur entirely independent of the reporting service acknowledging to the transaction service that a log has been created and saved in the reporting database.

In addition to speed, asynchronous processing and event driven architectures break the chains of interdependencies commonly seen in synchronous structures like REST or gRPC. This drastically reduces the risk of service degradation cascading across multiple microservices.

Synchronous processing: In synchronous or linear processing, responses times can grow as requests are pushed downstream through a chain of increasingly overwhelmed services.

Event-driven processing: In contrast, event-driven processing is ‘receiver-driven’. Each microservice pulls from the queue as it is capable of processing requests, meaning many services function together to make light work of high volume periods.

Events are also useful for version-control style functionality and sustained visibility of merchant-customer activity.

Whenever sensitive risk rules are modified by merchants using the self-service platform—for example, they decide to block certain countries or increase their online transaction limits—the configuration service creates an event which is consumed by the notification service. The notification service triggers an event to the fraud management team to ensure full, real time visibility of any changes to the risk rules, and a more detailed, to-the-minute profile of each customers’ unique context.

Merchants can access a self-service portal which offers:

• Full visibility of every transaction’s status across all channels; from initial authorisation to capture. An event-driven architecture ensures merchants can access and understand all payments in play, as they’re processed in real-time.
• Configurable gateway risk rules—from blocking certain countries to increasing online transaction limits—which use events to predict and protect against fraudulent transactions.
• Close-to-real time data visuals providing detailed reports, chargebacks, payments histories, and other information.