Refund Process Documentation

Refunds are processed as transactions associated with payments. Each refund request is reviewed, and based on approval or denial, the refund moves through different states. This document explains the refund states, the refund processing flow, and the mechanisms for updating refund statuses.

Refund Process Overview

Requesting a Refund

• A refund can be initiated by the user, either directly through the application or via customer support staff.
• Once the refund is requested, it is created in the system with a status of Created and is stored in the database.

Review and Approval

• Staff are notified to review the refund request.
• After review, the refund can be either approved or denied:
  • Approved: If approved, the refund is sent for processing and its status is updated to Pending.
  • Denied: If denied, the refund status is set to Rejected, and a notification is sent back to the user.

Processing the Refund

• Approved refunds are processed by the payment system, with the system managing the transaction and interacting with third-party partners if required.
• The payment system can support asynchronous processing for refunds, where the refund may not be instantly completed but instead undergoes further processing.

Notification and Completion

• Once the refund is processed, its status is updated to Completed, and the user is notified.
• For denied refunds, the user is notified of the rejection, and the refund remains in the Rejected state.

Refund Types and States

Refunds can either be processed instantly or asynchronously. Most refunds, particularly those involving bank transfers, QR code payments, cards, or direct debits, are asynchronous. These refunds are processed through partners, where the system routes to available partners based on criteria such as cost and availability.

Refund States

The following states are available for refunds:

• Created: Initial state when the refund is requested.
• Pending: After approval, the refund enters this state as it awaits processing.
• Completed: The refund has been processed successfully and completed.
• Rejected: The refund request was denied and will not proceed further.

Sequence Diagram

The following sequence diagram illustrates the flow of a refund from initiation to completion:

Sequence Explanation

1. User Requests Refund: The user or support staff initiates a refund request.
2. Notify Staff for Review: Staff receive a notification to review the refund.
3. Review Refund Request:
   • Staff review and decide whether to approve or deny.
   • If approved, the refund moves to Pending status and is sent for processing.
   • If denied, it is marked as Rejected.
4. Process Refund (if Approved):
   • The refund is processed by the system, involving partner coordination as necessary.
   • Once processed successfully, the refund status is updated to Completed.
5. Notify User:
   • After completion or rejection, the user is notified of the refund status.

Key Points on Asynchronous Processing

• Routing and Partner Selection: Refund processing involves routing through various partners based on criteria such as cost, availability, and priority, managed in the PartnerPaymentMethod table.
• Webhook for Status Updates: For asynchronous refunds, status updates are managed through webhooks from partners. A webhook is sent to the system to confirm the completion of the refund, and logic is included to prevent duplicate updates.

State Update Mechanism

• Webhook: Partners send updates to the system to notify of status changes.
• Manual Polling (Not yet implemented): Polling could be used as an alternative method to check refund statuses periodically.

API Endpoints for Refunds

Initiate Refund

• Endpoint: [Initiate Refund API Endpoint]
• Description: This endpoint is used to create a refund and put it in the Created state.

Update Refund Status

• Endpoint: [Update Refund Status API Endpoint]
• Description: This endpoint is called by webhooks from partners to update the refund status based on completion or failure.