Activity Diagram – Payment Processor 

An Activity Diagram represents the flow of activities and the sequence in which operations are carried out in the system. For a Payment Processor System, it visualizes how a payment moves from initiation to completion, including validations, fraud checks, and communication with banks.

Step-by-Step Description of Activities

1. Start of Process

• The process begins when a Customer initiates a payment request using a card, digital wallet, or bank account.

• The payment details and transaction amount are submitted to the Payment Processor System.

2. Validate Payment Input

• The system checks if all required fields (amount, card number, expiry, etc.) are valid and in the correct format.

• If validation fails, the transaction is rejected and the process ends with an error message sent back to the customer.

3. Fraud Detection Check

If the inputs are valid, the request is passed to the Fraud Detection Module.

The system uses rules or machine learning models to analyze the transaction.

• If the transaction is flagged as suspicious, it may be held for manual review or rejected immediately.
• If no fraud is detected, the flow continues.

4. Authorize Payment

The system now interacts with the Payment Gateway, which routes the payment request to the Issuing Bank (the customer’s bank).

The Issuing Bank checks:

• Account availability
• Sufficient balance
• Card/account status
• OTP (if applicable)

5. Receive Bank Response

The bank either authorizes or declines the payment.

• If authorized, the process continues to settlement.
• If declined, the transaction fails, and a decline reason is sent to the customer and merchant.

6. Process Settlement

If the bank authorizes the payment:

• The Acquiring Bank (merchant’s bank) is informed to credit the merchant’s account.
• A Transaction Record is created with a success status.
• A confirmation receipt is generated for both customer and merchant.

7. End of Process

The flow ends by sending the final status (success or failure) to all relevant parties:

• Customer
• Merchant
• System logs and analytics modules

Optional Paths

• If a refund is requested, a similar flow is triggered in reverse.
• If fraud is detected, the transaction may be escalated for manual intervention.

Swimlanes (if visualized)

If shown with swimlanes, actors like Customer, System, Fraud Module, Gateway, Banks, and Merchant can each represent a column to clearly show responsibility for each action.