# 2. Transaction Management — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: transaction_management.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature,
  expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 2.1 View All Transactions and Payment History | Transaction view: the view (the transactions, the filters, the period) | TC-SA-15-02-001 |
| 2.1 View All Transactions and Payment History | Transaction detail: the detail (the payment, the user, the amount, the date, the status) | TC-SA-15-02-002 |
| 2.1 View All Transactions and Payment History | Payment history: the history (the history of the payments, the period) | TC-SA-15-02-003 |
| 2.1 View All Transactions and Payment History | Transaction filter: the filter (the filter by the user, the amount, the date, the status) | TC-SA-15-02-004 |
| 2.1 View All Transactions and Payment History | Transaction search: the search (the search by the transaction ID, the user) | TC-SA-15-02-005 |
| 2.1 View All Transactions and Payment History | Transaction export: the export (the transactions, the format, the period) | TC-SA-15-02-006 |
| 2.1 View All Transactions and Payment History | Audit logging of the transaction viewing | TC-SA-15-02-007 |
| 2.1 View All Transactions and Payment History | Rule: the transaction view is the visibility (the transactions, the filters, the period); the view is the access | TC-SA-15-02-001 |
| 2.1 View All Transactions and Payment History | Rule: the transaction detail is the record (the payment, the user, the amount, the date, the status); the detail is the proof | TC-SA-15-02-002 |
| 2.1 View All Transactions and Payment History | Rule: the payment history is the timeline (the history of the payments, the period); the history is the context | TC-SA-15-02-003 |
| 2.1 View All Transactions and Payment History | Rule: the transaction filter is the scope (the filter by the user, the amount, the date, the status); the filter is the control | TC-SA-15-02-004 |
| 2.1 View All Transactions and Payment History | Rule: the transactions are visible (the transactions, the filters, the period); the viewing is managed | TC-SA-15-02-001 |
| 2.1 View All Transactions and Payment History | Rule: transaction viewing is audit-logged with the transaction, filter, and timestamp | TC-SA-15-02-007 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Payment status: the status (the pending, the successful, the failed) | TC-SA-15-02-008 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Pending payment: the pending (the payment that is in progress, e.g., the gateway is processing) | TC-SA-15-02-009 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Successful payment: the successful (the payment that is completed, e.g., the amount is received) | TC-SA-15-02-010 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Failed payment: the failed (the payment that is failed, e.g., the card is declined) | TC-SA-15-02-011 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Status record: the record (the payment, the status, the date) | TC-SA-15-02-012 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Status view: the view (the payments, the statuses, the period) | TC-SA-15-02-013 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Audit logging of the payment status tracking | TC-SA-15-02-014 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Rule: the payment status is the state (the pending, the successful, the failed); the status is the control | TC-SA-15-02-008 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Rule: the pending payment is the in-progress (the payment that is in progress, e.g., the gateway is processing); the pending is the state | TC-SA-15-02-009 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Rule: the successful payment is the done (the payment that is completed, e.g., the amount is received); the successful is the state | TC-SA-15-02-010 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Rule: the failed payment is the error (the payment that is failed, e.g., the card is declined); the failed is the state | TC-SA-15-02-011 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Rule: the statuses are visible (the payments, the statuses, the period); the tracking is managed | TC-SA-15-02-013 |
| 2.2 Track Payment Status (Pending, Successful, Failed) | Rule: payment status tracking is audit-logged with the payment, status, and timestamp | TC-SA-15-02-014 |
| 2.3 Failed Payment Retry Logic | Retry configuration: the configuration (the retry count, the interval, the notification) | TC-SA-15-02-015 |
| 2.3 Failed Payment Retry Logic | Retry attempt: the attempt (the retry of the failed payment, the attempt number) | TC-SA-15-02-016 |
| 2.3 Failed Payment Retry Logic | Retry interval: the interval (the interval between the retries, e.g., the daily) | TC-SA-15-02-017 |
| 2.3 Failed Payment Retry Logic | Retry notification: the notification (the notification to the user, the retry) | TC-SA-15-02-018 |
| 2.3 Failed Payment Retry Logic | Retry record: the record (the payment, the retry, the attempt, the date) | TC-SA-15-02-019 |
| 2.3 Failed Payment Retry Logic | Retry view: the view (the retries, the period) | TC-SA-15-02-020 |
| 2.3 Failed Payment Retry Logic | Audit logging of the retry configuration and the attempts | TC-SA-15-02-021 |
| 2.3 Failed Payment Retry Logic | Rule: the retry configuration is the control (the retry count, the interval, the notification); the configuration is the logic | TC-SA-15-02-015 |
| 2.3 Failed Payment Retry Logic | Rule: the retry attempt is the recovery (the retry of the failed payment, the attempt number); the attempt is the action | TC-SA-15-02-016 |
| 2.3 Failed Payment Retry Logic | Rule: the retry interval is the timing (the interval between the retries, e.g., the daily); the interval is the schedule | TC-SA-15-02-017 |
| 2.3 Failed Payment Retry Logic | Rule: a logic change (the count, the interval, the notification updated) is recorded (the new count, the new interval, the new notification, the time); it is auditable | TC-SA-15-02-021 |
| 2.3 Failed Payment Retry Logic | Rule: the retries are visible (the retries, the period); the logic is managed | TC-SA-15-02-020 |
| 2.3 Failed Payment Retry Logic | Rule: retry configuration and attempts are audit-logged with the payment, retry, and timestamp | TC-SA-15-02-021 |

## 2.1 View All Transactions and Payment History

### TC-SA-15-02-001 — Transaction view: the view (the transactions, the filters, the period); the view is the access
**Type:** Positive
**Covers:** 2.1 → Transaction view: the view (the transactions, the filters, the period); Rule: the transaction view is the visibility (the transactions, the filters, the period); the view is the access; Rule: the transactions are visible (the transactions, the filters, the period); the viewing is managed
**Preconditions:** Transactions exist across multiple users and periods.
**Steps:**
1. View the transactions: the transactions (the payment, the user, the amount, the date, the status), the filters (the user, the amount, the date, the status), and the period (the period of the transactions).
2. Verify the view is explicit and the transactions are visible.
**Expected Result:** The transaction view works — the transactions, the filters, and the period are visible.
**Priority:** Critical

### TC-SA-15-02-002 — Transaction detail: the detail (the payment, the user, the amount, the date, the status); the detail is the proof
**Type:** Positive
**Covers:** 2.1 → Transaction detail: the detail (the payment, the user, the amount, the date, the status); Rule: the transaction detail is the record (the payment, the user, the amount, the date, the status); the detail is the proof
**Preconditions:** A transaction exists.
**Steps:**
1. Open the transaction detail.
2. Verify it shows the payment, the user, the amount, the date, and the status.
**Expected Result:** The transaction detail is shown — the payment, the user, the amount, the date, and the status are visible.
**Priority:** High

### TC-SA-15-02-003 — Payment history: the history (the history of the payments, the period); the history is the context
**Type:** Positive
**Covers:** 2.1 → Payment history: the history (the history of the payments, the period); Rule: the payment history is the timeline (the history of the payments, the period); the history is the context
**Preconditions:** Payments exist across multiple periods.
**Steps:**
1. View the payment history: the history (the history of the payments, the period).
2. Verify the history is the timeline and is complete for the period.
**Expected Result:** The payment history is shown — the history of the payments for the period is visible.
**Priority:** High

### TC-SA-15-02-004 — Transaction filter: the filter (the filter by the user, the amount, the date, the status); the filter is the control
**Type:** Negative
**Covers:** 2.1 → Transaction filter: the filter (the filter by the user, the amount, the date, the status); Rule: the transaction filter is the scope (the filter by the user, the amount, the date, the status); the filter is the control
**Preconditions:** Transactions exist for multiple users, amounts, dates, and statuses.
**Steps:**
1. Set the transaction filter: the filter (the filter by the user, the amount, the date, the status).
2. Verify only the matching transactions are shown.
3. Apply a filter combination that matches no transactions — verify an empty result is shown (no error).
**Expected Result:** The transaction filter works — only the matching transactions are shown; an empty result is handled.
**Priority:** High

### TC-SA-15-02-005 — Transaction search: the search (the search by the transaction ID, the user); the search is the lookup
**Type:** Edge
**Covers:** 2.1 → Transaction search: the search (the search by the transaction ID, the user)
**Preconditions:** Transactions exist.
**Steps:**
1. Search a transaction by the transaction ID — verify the exact transaction is found.
2. Search by the user — verify all the user's transactions are found.
3. Search by a non-existent transaction ID — verify no results are shown (no error).
**Expected Result:** The transaction search works — the transaction is found by the transaction ID or the user; a non-existent ID returns no results.
**Priority:** High

### TC-SA-15-02-006 — Transaction export: the export (the transactions, the format, the period); the export is the record
**Type:** Positive
**Covers:** 2.1 → Transaction export: the export (the transactions, the format, the period)
**Preconditions:** Transactions exist for a period.
**Steps:**
1. Export the transactions: the export (the transactions, the format, the period).
2. Verify the export is generated in the selected format.
3. Verify the exported data matches the transaction view.
**Expected Result:** The transactions are exported — the transactions in the selected format for the period are generated.
**Priority:** Medium

### TC-SA-15-02-007 — Transaction viewing is audit-logged with the transaction, filter, and timestamp
**Type:** Positive
**Covers:** 2.1 → Audit logging of the transaction viewing; Rule: transaction viewing is audit-logged with the transaction, filter, and timestamp
**Preconditions:** Transaction viewing has occurred with filters.
**Steps:**
1. Open the audit trail and filter by "transaction viewing".
2. Verify entries show the transaction, the filter, and the timestamp.
**Expected Result:** The transaction viewing is audit-logged with the transaction, filter, and timestamp.
**Priority:** Critical

## 2.2 Track Payment Status (Pending, Successful, Failed)

### TC-SA-15-02-008 — Payment status: the status (the pending, the successful, the failed); the status is the control
**Type:** Positive
**Covers:** 2.2 → Payment status: the status (the pending, the successful, the failed); Rule: the payment status is the state (the pending, the successful, the failed); the status is the control
**Preconditions:** Payments exist in all three statuses.
**Steps:**
1. View the payment status tracking: the payments (the payment, the user, the amount), the statuses (the pending, the successful, the failed), and the dates (the date of the payment).
2. Verify the status is the state for each payment.
**Expected Result:** The payment status is shown — the pending, the successful, or the failed state is visible for each payment.
**Priority:** Critical

### TC-SA-15-02-009 — Pending payment: the pending (the payment that is in progress, e.g., the gateway is processing); the pending is the state
**Type:** Positive
**Covers:** 2.2 → Pending payment: the pending (the payment that is in progress, e.g., the gateway is processing); Rule: the pending payment is the in-progress (the payment that is in progress, e.g., the gateway is processing); the pending is the state
**Preconditions:** A payment is in progress (the gateway is processing).
**Steps:**
1. View the pending payments: the pending (the payment that is in progress, e.g., the gateway is processing).
2. Verify the pending payment is shown with its status and date.
**Expected Result:** The pending payment is shown — the payment that is in progress is visible.
**Priority:** High

### TC-SA-15-02-010 — Successful payment: the successful (the payment that is completed, e.g., the amount is received); the successful is the state
**Type:** Positive
**Covers:** 2.2 → Successful payment: the successful (the payment that is completed, e.g., the amount is received); Rule: the successful payment is the done (the payment that is completed, e.g., the amount is received); the successful is the state
**Preconditions:** A payment has been completed (the amount is received).
**Steps:**
1. View the successful payments: the successful (the payment that is completed, e.g., the amount is received).
2. Verify the successful payment is shown with its status and date.
**Expected Result:** The successful payment is shown — the payment that is completed is visible.
**Priority:** High

### TC-SA-15-02-011 — Failed payment: the failed (the payment that is failed, e.g., the card is declined); the failed is the state
**Type:** Negative
**Covers:** 2.2 → Failed payment: the failed (the payment that is failed, e.g., the card is declined); Rule: the failed payment is the error (the payment that is failed, e.g., the card is declined); the failed is the state
**Preconditions:** A payment has failed (the card is declined).
**Steps:**
1. View the failed payments: the failed (the payment that is failed, e.g., the card is declined).
2. Verify the failed payment is shown with its status, date, and the failure reason.
**Expected Result:** The failed payment is shown — the payment that is failed is visible with the failure reason.
**Priority:** High

### TC-SA-15-02-012 — Status record: the record (the payment, the status, the date); the record is the proof
**Type:** Positive
**Covers:** 2.2 → Status record: the record (the payment, the status, the date)
**Preconditions:** A payment status has been tracked.
**Steps:**
1. Open the status record.
2. Verify it shows the payment, the status, and the date.
**Expected Result:** The status is recorded — the payment, the status, and the date are shown.
**Priority:** High

### TC-SA-15-02-013 — Status view: the view (the payments, the statuses, the period); the tracking is managed
**Type:** Positive
**Covers:** 2.2 → Status view: the view (the payments, the statuses, the period); Rule: the statuses are visible (the payments, the statuses, the period); the tracking is managed
**Preconditions:** Payments exist in all three statuses across a period.
**Steps:**
1. View the statuses: the payments, the statuses, the period — verify the tracking is complete.
2. For a specific payment, view the payment's status (the status, the date, the reason) — verify the detail is shown.
3. Export the statuses (the status report, the period) — verify the export is generated.
**Expected Result:** The status view works — the payments, the statuses, and the period are visible and the export is generated.
**Priority:** High

### TC-SA-15-02-014 — Payment status tracking is audit-logged with the payment, status, and timestamp
**Type:** Positive
**Covers:** 2.2 → Audit logging of the payment status tracking; Rule: payment status tracking is audit-logged with the payment, status, and timestamp
**Preconditions:** Payment status tracking events have occurred.
**Steps:**
1. Open the audit trail and filter by "payment status".
2. Verify entries show the payment, the status, and the timestamp.
**Expected Result:** The payment status tracking is audit-logged with the payment, status, and timestamp.
**Priority:** Critical

## 2.3 Failed Payment Retry Logic

### TC-SA-15-02-015 — Retry configuration: the configuration (the retry count, the interval, the notification); the configuration is the logic
**Type:** Positive
**Covers:** 2.3 → Retry configuration: the configuration (the retry count, the interval, the notification); Rule: the retry configuration is the control (the retry count, the interval, the notification); the configuration is the logic
**Preconditions:** Super Admin is logged in.
**Steps:**
1. Configure the retry logic: the retry count (the number of retries, e.g., 3), the interval (the interval between the retries, e.g., the daily), and the notification (the notification to the user, the retry).
2. Save; verify the retry logic is live and the failed payments are retried.
**Expected Result:** The retry configuration is saved — the retry count, the interval, and the notification are configured and live.
**Priority:** Critical

### TC-SA-15-02-016 — Retry attempt: the attempt (the retry of the failed payment, the attempt number); the attempt is the action
**Type:** Edge
**Covers:** 2.3 → Retry attempt: the attempt (the retry of the failed payment, the attempt number); Rule: the retry attempt is the recovery (the retry of the failed payment, the attempt number); the attempt is the action
**Preconditions:** The retry logic is configured with a retry count of 3; a payment has failed.
**Steps:**
1. A payment fails; verify the retry is attempted (the retry is made, the attempt is recorded, the user is notified).
2. Verify the attempt number is incremented for each retry (1, 2, 3).
3. Verify no retry is made after the retry count is exhausted (no 4th attempt).
**Expected Result:** The retry attempt works — the failed payment is retried up to the configured count, each attempt is recorded, and no retry is made after the count is exhausted.
**Priority:** Critical

### TC-SA-15-02-017 — Retry interval: the interval (the interval between the retries, e.g., the daily); the interval is the schedule
**Type:** Positive
**Covers:** 2.3 → Retry interval: the interval (the interval between the retries, e.g., the daily); Rule: the retry interval is the timing (the interval between the retries, e.g., the daily); the interval is the schedule
**Preconditions:** The retry logic is configured with a daily interval; a payment has failed.
**Steps:**
1. Verify the first retry is made after the interval (e.g., the next day).
2. Verify the second retry is made after the next interval.
3. Verify the interval is the schedule for the retries.
**Expected Result:** The retry interval is enforced — the retries are made at the configured interval (e.g., the daily).
**Priority:** High

### TC-SA-15-02-018 — Retry notification: the notification (the notification to the user, the retry); the notification is the communication
**Type:** Positive
**Covers:** 2.3 → Retry notification: the notification (the notification to the user, the retry)
**Preconditions:** The retry logic is configured with the notification enabled; a payment has failed.
**Steps:**
1. A payment fails and the retry is attempted — verify the user is notified of the retry.
2. Verify the notification shows the retry details (the payment, the attempt).
**Expected Result:** The retry notification is sent — the user is notified of the retry.
**Priority:** High

### TC-SA-15-02-019 — Retry record: the record (the payment, the retry, the attempt, the date); the record is the proof
**Type:** Positive
**Covers:** 2.3 → Retry record: the record (the payment, the retry, the attempt, the date)
**Preconditions:** Retries have been attempted.
**Steps:**
1. Open the retry record.
2. Verify it shows the payment, the retry, the attempt, and the date.
**Expected Result:** The retry is recorded — the payment, the retry, the attempt, and the date are shown.
**Priority:** High

### TC-SA-15-02-020 — Retry view: the view (the retries, the period); the logic is managed
**Type:** Positive
**Covers:** 2.3 → Retry view: the view (the retries, the period); Rule: the retries are visible (the retries, the period); the logic is managed
**Preconditions:** Retries have been attempted across a period.
**Steps:**
1. View the retries: the retries, the period — verify the retries are visible.
2. Verify the view is complete for the period.
**Expected Result:** The retry view works — the retries for the period are visible.
**Priority:** High

### TC-SA-15-02-021 — Retry configuration and attempts are audit-logged with the payment, retry, and timestamp
**Type:** Positive
**Covers:** 2.3 → Audit logging of the retry configuration and the attempts; Rule: a logic change (the count, the interval, the notification updated) is recorded (the new count, the new interval, the new notification, the time); it is auditable; Rule: retry configuration and attempts are audit-logged with the payment, retry, and timestamp
**Preconditions:** The retry logic has been configured, changed, and retries have been attempted.
**Steps:**
1. Open the audit trail and filter by "payment retry".
2. Verify entries show the payment, the retry, and the timestamp for the attempts.
3. Verify the logic change (the new count, the new interval, the new notification, the time) is recorded and auditable.
**Expected Result:** The retry configuration and the attempts are audit-logged with the payment, retry, and timestamp.
**Priority:** Critical