Writing debit and credit as a service

 

Problem statement:  How should a reward points redeeming service be implemented given that the debit and credit are typically occurring on separate services? 

Solution: We assume the reward points balance is maintained accurately in the data layer. The service accumulating and redeeming from this balance update the same source of truth. Both the services recognize the same owner for the reward points because they use the same identity cloud. The redeeming service focuses on making one or more debits against the reward points balance. As long as the reward points store consistently handles the debit and the credit, the granularity of debits does not matter to the debits against the balance.  

This redeeming service simply creates, updates, and deletes a debit entry record in the ledger holding the reward points as long as the rewards added to the cart by the cart service can be honored. This is a simple online transaction processing system that brings the database guarantees to the ledger.   

The database should have change data capture and some form of audit trail. This is essential to the redeeming service because it prevents the detection of misuse. A debit should only be processed when all the security measures have passed.  

The redeeming service supports use-cases for reversal. In such cases, the entry may simply be removed from the ledger. The guarantees from the ledger are sufficient to ensure consistency. In the long run with expanded use cases, reward points may enable multiple stores and their carts to use the same service. In such a case, the microservice architecture for redeeming reward points will be helpful.   

The redeeming service can be simply written as a model-view-controller with the debit as the model. The controller has actions specific to list, create, update, delete, and get by id.  The list action will support ordered and paged entries as well as query parameters. The views are for administrative purposes.  

This session identifier is usually obtained as a hash of the session cookie. And is provided by the authentication and authorization server.  The session identifier can be requested as part of the login process or by a separate API Call to a session endpoint. An active session removes the need to re-authenticate. It provides a familiar end-user experience and functionality. The session can also be used with user-agent features or extensions to assist with authentication such as password-manager or 2-factor device reader.  

There are certain options other than build-your-own service. These options provide the ability to distribute a debit to multiple stores. For example, the Stripe Connect API allows the routing of reward points like payments between the owner and the recipients. Since the participating stores fulfill these orders independently, the reward points redeeming service concerns itself only with owners and their reward points.