Order payment reservation
In this step order payment functionality is added to the customer service. Customer entity has a property which defines how many spendable credits the customer has available. In this step we add a simple endpoint with which customer can top up their credits.
The order payment is done by Customer service listening to the Order created event, which is broadcasted by the Order service once the order is created.
To listen to the event, a Customer queue controller is created. The RabbitMQ service works in a way so that Subscription decorators have to be defined in a service separate from the Rest controllers. In case both are defined in the same service, Rest controllers will no longer work. You can see the queue controller implementation in the link bellow
Once the order created event is received, the customer service will either
Decrement customers available credits balance, create reserved credits entity tied to the order id and broadcast Order payment reserved event
Broadcast Order payment failed event, in case the customer doesn't have high enough balance.
With these events broadcasted, Order service can now listen to these events and update the order status accordingly
Testing order payment reservation
To test the new updates, we should first update both customer and order service in the local cluster.
To test the new payment reservation functionality lets create new order
Once the order is created, the get details endpoint should return that the order has failed. This happened because customer had no credits.
For the next step, lets add some credits to customer account
After this is done, we should create a new order. This time, the order details endpoint should return status order reserved.
With the order payments done, its time to handle the shipping
Last updated
