Design Installment-Loan Payment Processing

Design a payment-processing system for an existing user's active installment loan. A payment may be initiated manually through an app or website, or automatically by a schedule. The system debits the user's bank through a synchronous API that is available during only one fixed one-hour window each day. After each attempt, notify the user of success or failure by SMS or email.

Cover APIs, state, scheduling, bank interaction, retries, accounting, and notifications.

Constraints & Assumptions

• User and loan services already exist and may be represented by stubbed APIs.
• The bank debit API gives a synchronous result while its daily window is open and is unavailable outside it.
• Clients, schedulers, workers, and notification providers may retry requests.
• A payment must never be debited twice because of a retry.
• Payment state and the loan's applied repayment must remain reconcilable.

Clarifying Questions to Ask

• Is a bank timeout known to mean failure, or can its outcome be unknown?
• Does the bank accept an idempotency key or expose a transaction-status lookup?
• Which timezone and holiday calendar define the one-hour window?
• May users cancel or edit a queued payment before the window opens?
• Are partial, early, late, or overpayments allowed?
• Which result should be communicated when an attempt is still pending reconciliation?