Self Serve Refunds¶

Overview¶

This self serve refund feature is introduced for flowing thru refunds which auto-approved and need approval from contact centre. This solution will provide contact centre team to review self server refund and approve if that fits in their rule. it contains 2 lambda functions to process all the requested data from the osp api and it gives us the data related different refund orders and 2 ecs service which help to maintain the proper flow of the functionality

Refund Pending request¶

Overview¶

This is the first lambda function which get the response from API in every 15 minutes and processed the refund request id with dynamodb and check if the given value is in their or not , if the request id is present in the dynamodb then it will check the next reqeust id if the request id is not there then it will be transfer to the sns with required format and once the message id is get by the sns , then that request id is insert in the same dynamodb table , this are the main component of this lambda function 1. Get API of order refund request 2. checking the given id with dynamodb 3. sending the refund_request_id to SNS 4. inserting refund_request_id in dynamodb

Refund SalesForce Adapter¶

Overview¶

This lambda function is depend on the Refund Pending Request lambda function , it process the request id got from SQS and and check it with fulfillment api and product-proposition and then prepare request body for salesforce api to send the collected data in the formatted structure this are main component of this lambda function 1. Get API of order fulfillment 2. Post API of product-proposition 3. Post service order refund case creation 4. delete the message from the queue

Refund Handler Task¶

Overview¶

This ECS task is triggered by a PutObject event into the S3 bucket. The ECS task will read the contents of the file and iterate over them. It will check if refundRequestorId is null and proceed to call the GET refunds API based on orderId. Incase the refundRequestorId is not null it will skip the record as it is not auto-approved. Once received a response from GET refunds API then call order-refund-requests API to get refundRequestorId details. In the response from order-refund-requests API check if the request is COMPLETED and retailerAgentId is null. If it is, then it is an auto-approved request. Send the details send to SNS topic for further processing and write processed message into Kafka topic for audit purpose.

Account Needed¶

AWS accounts will be required for DEV/SIT/PROD.

References¶

Python Service with infrastructure as code.
Unit tests & code coverage at about 90%+
Configuration for multiple environments, DEV/SIT/PRD

Document	Ref
Architecture Document	Solution Architecture.
Jira Story	Technical Elaboration - SPDP-6936.
Bitbucket repository	osp self serve refund.

Testing Approach¶

We will be using a BDD approach where the behaviour will be tested first the code will be developed to match the tested behaviour.

Deployment strategy¶

The deployment is handled by a jenkins multibranch pipeline,sk-feature. The commit in the develop branch will automatically deploy the application to the aws environments. The release is done by standard process of tagging the release branch, and by building and deploying from the tags. The tag format is sit-v*-<commit> for nonprod and prd-v*-<commit> for the production release. These tags are manually built on jenkins after the change request has been approved. The release branch is merged to the stable master branch after the successful production deployment.

Components¶

Components

Diagrams¶

Self Serve Refund work flow diagram

Refund_request

Refund_salesforce_Adaptor

Refund Handler Task