Micronaut payment microservice

This project is a payment microservice designed to work alongside with Stripe API in order to create and manage the payment facilitation by your clients. It includes several helpful endpoints for eaiser usage and management by developers. It also uses:

• Pragramatically generated swagger endpoint
• Several JUnit tests to ensure proper working of the endpoints
• Jacoco implementation with a overall coverage of 98%
• Secure session logins based on JWT

Initial Configuration

1. Create a mysql database named 'work' and create 2 tables named charge and refund whose structure is defined in a file named setup.sql.

2. Security implemented with JWT is initially disabled for this project. You can enable it by uncommenting the secure section in the application.yml file.

3. You also need to edit the 'secret.json' file that contains the following:

• Your Stripe key under 'StripeKey'
• Your mysql username and password under 'username' and 'password'
• Your JWT(Works only if you follow step 2) login id and password under 'loginuser' and 'loginpass'

4. Start the zookeeper and the server for using the POST method(submit button) that uses kafka.

Frontend

The server hosts a HTML file that is responsible for getting the data from the user, generating a token and sending the token and other data in the request body to the backend. The UI in this project is made using Stripe Elements.

Sensitive data is not sent to the backend and is rather processed by Stripe.js which then generates the token mentioned above. The token can then be used to create charges and if required, refunds.

Endpoints

You can access the following endpoints from class NewCustomerController and also access a testing controller from class TestController.

Following is the list of endpoints which are decribed in greater detail below.

Method	Endpoint
POST	/charges
PUT	/update
GET	/stripeuser/{id}
GET	/stripeall/{count}
DELETE	/delete/{id}
POST	/refund/{id}
GET	/refundget/{id}
GET	/test/charger

Interactions with table 'charge'

To create charges

POST method with an endpoint of '/charges'.

This is the endpoint that will be used to create charges. In order to trigger this endpoint successfully, you need to send the token that is generated by either generated with Stipe Elements or Stripe Checkout to the server-side via this endpoint such that the body of the method contains the token for the transaction.

To edit details of a charge

PUT method with endpoint of '/update'.

This endpoint can be used by the developer to securely(if JWT is enabled) send and edit the body of an already created charge. The body of the request should contain json encoded data with attributes:

• id
• amount
• balance_transaction
• invoice
• payment_method
• receipt_number
• currency

Of these attributes, id, amount, balance_transaction, payment_method and currency should not be null. If you want, you can change these settings within your database.

To get details of an already existing charge

GET method with endpoint '/stripeuser/{id}'.

Here {id} refers to the id of the charge you want to search for.

To get the last 'n' transaction details

GET method with endpoint '/stripeall/{count}'.

Here {count} refers to the number of transactions you want to display.

To delete a transaction from your database

DELETE method with endpoint '/delete/{id}'.

Here {id} refers to the id of the charge you want to delete from your database.

Interactions with table refund

To create a refund for a known charge

POST method with endpoint '/refund/{id}'.

Here {id} refers to the id of the charge you want to generate a refund for.

To get details of a refund

GET methid with endpoint '/refundget/{id}'.

Here {id} refers to the id of the charge you want to get the refund details for.

Testing your endpoints

You can test if your microservice is interaciong with the Stripe API correctly or not by running

$ gradlew.bat test

It will run a series of tests that are coded in the /test directory under the src directory.

Since the PUT method needs to be tested with existing records, you might need to change the id's provided for testing the method in the tests themselves.

Code coverage

Jacoco for generating a code coverage report.

Benchmaring with the JMeter tool

In order to test if our server can handle multiple requests from multiple clients, we use JMeter which can simulate just that. Since the clients will be accessing the POST method that creates the charges, we need to find a way to generate multiple tokens and sending them to an endpint that can process the charge. In order to do that, we have a method named 'tokencreator' in 'MethodImpl' that creates tokens using a testing card number whose transactions should not raise any flags. The token generated by the 'tokencreator' method is then sent to the 'poster' method in 'MethodImpl' that is used by our primary POST method to generate charges off of a token given by the front-end. However, for benchmarking, we are sending the token value directly to the 'poster' method. The charge details are then saved to our database and an HTTP response is sent signifying whether the transaction went through or not. JMeter collects and saves these responses in a csv file that can then be used to generate a HTML report from within the application.

Peak CPU and Memory usage

PC specs:

OS - Windows 10 Pro 64-bit (Build 17763)

CPU - Intel i5-7200U @2.5GHz - 3.1GHz

Memory - 8GB (2400MHz)

Disk - 5400rm HDD