A payment API using a MongoDB as storage and connects to a mock CKO Bank API acording to this spec: https://c.smartrecruiters.com/sr-company-attachments-prod-aws-dc5/63594668c67784587b6c5a3f/fe7584e2-e8df-46f0-ab14-446b6df44411?r=s3-eu-central-1
- Dotnet 7.0.306
- Docker
- Docker Compose
The app needs a MongoDB and Mock back instance to work. A docker compose has been provided to spool these up.
docker compose up
As a dotnet app running up just uses a CLI. Enviroment variables have been provided for you (Assuming you are running the Supporting infa)
souce .env
cd Payment.REST
dotnet run
It can run on docker with the Dockerfile`` provided although the
.env` file may not be suitable networking wise.
Fairly self explanatory. Make sure its set otherwise the API will crash on first request. .env
is there already for you
MONGO_CONNECTION="mongodb://admin:admin@localhost:27017/"
MONGO_DB="checkout"
CKO_BANK_URL="http://localhost:5251"
CKO_BANK_API_KEY="4321"
Swagger should be setup and running on http://localhost:5059/swagger/index.html
Auth is mocked for now and hard coded to use Authorisation: Bearer 1234
Its just stubbed as a Proper app would call a Auth Service and the token would of come from an inital validaiton within that auth service
Everything is tested with xunit and Moq. I found the MongoDB Mocking the hardest due to the extentions used (Moq can't handel them so you gotta go digging)
dotnet test
If you want to try out the app you can control the status the bank returns using the Referance
field
- NO MONEY -> INSUFFICENT FUNDS
- REJECT ME -> REJECTED
- Anything else -> Approved
- Mongo DB chosen because I've worked with it before and its nice and simple for this applicaiton. Probabbly doesn't scale well without Indexes and even then you could move to DynamoDB/Cassandra for better performance with current data)
- API to be REST - Could be GRPC for better contracts but decided for REST to have wider reach
- Dumb Auth Service to be mocked in REST package
- Validation is done by the MS API controller but it could live in Payment.logic if REST was to swich out for something else. (Still tested)
- Packages seperated to allow re-use in future (Swich out REST for GRPC or SOAP (if ya old school))
- Didn't bother implementing secondry banks but it would be more client and a swich based on identifying info
- Assume that in relaity there would be much more validation and ways of identifying banks and users (via auth)
- Potential case of MongoDB failing and payments being made and not saved. In this case I'd probabbly cache and either dump onto a external Queue servie to be dealth with and respond with the payment status (Assuming there isn't laws and cancel paymet methods already)
- Avoid storing card details so I only store the record of transation to minimise value of DB.
This would probabbly run on a K8s infra with the MongoDB probabbly being hosted on Atlas on in whatever infra we are using. Deployed and PR testing with Github Actions and infra deployed using Terraform.
- Propper HTTPS
- Mongo Encrypt at rest
- Metrics
- Probably a bunch of stuff I'll think of right after submission. Unfortunatly I'll forget it before being asked about it :P