Implement Proper Payment Voiding and Refund System

[andrewdwallo]

Description

We need to implement a proper payment processing system that handles voids and refunds according to industry standards.

Current State

• No distinction between voids (pre-settlement) and refunds (post-settlement)
• You can technically do a payment refund by creating a negative amount payment (which is a Withdrawal), but this is unclear. You can also technically do a void by deleting the payment - which is as if the payment transaction never existed
• Missing proper audit trail for payment reversals

Proposed Implementation

1. Add a status column to transactions table with values:

   • active - Normal valid transactions
   • voided - Pre-settlement cancellations
   • refund - Post-settlement refunds

2. Add a related_transaction_id foreign key to link:

   • Original payments to their refund transactions
   • Refund transactions back to their original payments

3. Implement two distinct user actions:

   • Void Payment: For pre-settlement cancellations

     • Marks transaction as "voided"
     • No new transaction created
     • Excluded from financial calculations and reports

   • Issue Refund: For post-settlement returns

     • Original transaction remains "active"
     • Creates new "refund" transaction with opposite amount
     • Both transactions included in financial calculations
     • Links transactions via related_transaction_id

Technical Details

• Create TransactionStatus enum
• Add migration for status and related_transaction_id columns
• Add helper methods for determining financial calculation inclusion
• Implement status-based color coding and badges in UI

Benefits

• Follows standard accounting principles
• Provides proper audit trail
• Prevents currency conversion issues
• Simplifies financial reporting

Notes

This may play into a Reconciliation feature implemented in the future