SD Payment Feature for Customer Onboarding

Author(s)

• Bishwanath Jana

Last Updated Date

2024-10-03

---

SRS References

---

Version History

Version	Date	Changes	Author
1.0	2024-09-17	Initial draft	Bishwanath Jana
1.1	2024-10-03	Updated order ID to application number	Bishwanath Jana

---

Feature Overview

Objective:
The feature is designed to streamline the Security Deposit (SD) payment process for customers during onboarding, ensuring payments can be linked to specific application numbers, building codes, and property codes.

Scope:
The feature covers APIs to handle fetching unlinked application numbers, building codes, and property details for a customer. It also integrates SD payments with various combinations of application numbers, building codes, and property codes during the onboarding process, ensuring flexibility if payments are not linked to any entity.

Dependencies:

• Customer Onboarding System
• Booking Details Database
• Payment Gateway API

---

Requirements

Design Specifications

• Workflow:
  1. During the onboarding process, customers can view and link SD payments to an application number, building code, or property code.
  2. If an SD payment is linked to an application number, the SD data is saved in the booking details.
  3. If no application number is linked, the system checks for existing unlinked SD payments related to the building and property, allowing the customer to select and link the payment.
  4. The isActive field indicates any pending onboarding steps, helping to streamline the onboarding process.

---

Here’s an updated task list including the new API for SD amount calculation. I’ve also adjusted the task numbers and estimates accordingly.

Development Tasks & Estimates

No	Task Name	Estimate (Hours)	Dependencies	Notes
1	Create an API to fetch unlinked application numbers	1 hour
2	Create an API to fetch building code and property code with an optional payload for application ID	3 hours
3	Update existing payment API to include buildingCode, propertyCode, and optional applicationID	2 hours
4	Create an API to link SD payment for unlinked payment flow	3 hours
5	Create an API to return unlinked SD payments	2 hours
6	Create a new API for SD amount calculation	2 hours		Additional logic needed for calculating SD amounts based on inputs
7	Total	13 hours

Testing & Quality Assurance

• Unit Tests:
  Unit tests will be written to cover each API endpoint and validate response statuses based on different scenarios.

• Testing Tools:
  Postman for API testing

---

Risks & Mitigations

Risk	Impact	Likelihood	Mitigation Strategy
Linking incorrect SD payments	High	Medium	Implement strict validation for linking SD payments
Missing applicationID, buildingCode, or propertyCode	Medium	High	Add validation and default handling for these optional fields
System performance issues	Medium	Low	Optimize API calls and database queries

---

Review & Approval

• Reviewer:
  Ayon Das

• Approval Date:
  2024-10-07

---