Synchronous vs Asynchronous Processing: The Payment Service does most steps synchronously to provide a result in the API response. We choose sync for the primary flow because merchants (and customers) expect an immediate answer to a payment attempt. 

Since the Transaction DB update is being done by Payment service as part of handling the request itself, doesn't this bring in a lot of failure scenario? For example, what if the Payment Service instance crashes right after calling "Acquirer Connector". The way, the external processor will process the payment, but the Transaction DB would not have any record. Additionally, it means that the client will have to keep a long lasting connection and will be susceptible to connection drop.

Isn't the following alternative present a more durable approach, with the trade off of having an asynchronous flow and slight increase in complexity. The latency impact is negligible (in the order of milliseconds). Even though, all the logic will be encapsulated through client side (or SDK side) code and not visible to the end user.

Alternative Approach:

Upon receiving the request, Payment Service does idempotency check. Idempotency can be handled by (atomically) checking for existence and inserting the idempotency key in a cache. Then it will create transaction record in DB and return the generated TransactionId. From the DB, we will use CDC to asynchronously trigger Payment Validation and the process handled by "Acquirer Connector". In parallel, the client (or SDK) would initiate a long poll / SSE with the transactionId, which would get updates from the transaction DB as the transaction moves through various steps in the workflow.