Test Cases: Payment & Transaction
| Module | CORE-08 | URD | Payment & Transaction URD |
|---|
1. Coverage Summary
| Area | URD reqs | Test cases | Covered |
|---|---|---|---|
Payment Lifecycle (PAY) | 6 | 6 | ⚠️ (PAY-006 Planned) |
Provider Credentials (PRV) | 3 | 3 | ✅ |
Accounts & Wallets (WAL) | 5 | 5 | ✅ |
Vouchers & Ledger (VCH) | 10 | 11 | ✅ |
Categories (CAT) | 3 | 3 | ✅ |
URD-PAY-006(provider refund) is a Won't / Planned requirement — intentionally uncovered until the feature is built. All Must requirements are covered.
2. Test Cases
TC-<AREA>-NNNlines up withURD-<AREA>-NNN. Priority = P1 (critical) / P2 (major) / P3 (minor).
2.1 Payment Lifecycle (PAY)
| TC ID | URD ref | Scenario | Steps | Expected | P |
|---|---|---|---|---|---|
| TC-PAY-001 | URD-PAY-001 | Provider reports success | 1. A pending payment exists. 2. Provider sends a success result. | Payment status becomes paid; the amount matches the order | P1 |
| TC-PAY-002 | URD-PAY-002 | Subscriber notified on success | 1. A subscriber is registered. 2. A payment succeeds. | Subscriber receives a payment-success notification | P1 |
| TC-PAY-003 | URD-PAY-003 | Live status to cashier | 1. Cashier is on the payment screen. 2. Provider reports paid / failed / expired. | Cashier sees the status change in real time | P1 |
| TC-PAY-004 | URD-PAY-004 | Duplicate result ignored | 1. A success result was already applied. 2. The same result is redelivered. | No duplicate effect; status unchanged; no second voucher | P1 |
| TC-PAY-005 | URD-PAY-005 | Webhook retry on failure | 1. A subscriber endpoint is temporarily down. 2. A payment event fires. | Delivery is retried with backoff; failure is logged; processing not blocked | P2 |
| TC-PAY-006 | URD-PAY-006 | Provider refund (Planned) | 1. A completed external payment. 2. Owner requests a refund. | Not yet implemented — placeholder for the planned refund feature | P3 |
2.2 Provider Credentials (PRV)
| TC ID | URD ref | Scenario | Steps | Expected | P |
|---|---|---|---|---|---|
| TC-PRV-001 | URD-PRV-001 | Connect a provider | 1. Owner opens provider settings. 2. Enters VNPAY QR MMS credentials. | Provider is connected for the merchant | P1 |
| TC-PRV-002 | URD-PRV-002 | Credentials masked | 1. A provider is connected. 2. Owner views the configuration. | Credentials are masked; full secret is never shown | P1 |
| TC-PRV-003 | URD-PRV-003 | Per-merchant scope | 1. Two merchants each connect a provider. 2. Merchant A views config. | Merchant A sees only its own credentials | P2 |
2.3 Accounts & Wallets (WAL)
| TC ID | URD ref | Scenario | Steps | Expected | P |
|---|---|---|---|---|---|
| TC-WAL-001 | URD-WAL-001 | Create a wallet | 1. Owner adds a CASH (or BANK / QR / mobile-POS) account. | Account is created with its type and currency | P1 |
| TC-WAL-002 | URD-WAL-002 | Control accounts exist | 1. A merchant is onboarded. | Internal control accounts (inventory, COGS) exist automatically | P1 |
| TC-WAL-003 | URD-WAL-003 | Opening + running balance | 1. Create an account with an opening balance. 2. Post a voucher against it. | Current balance starts at the opening value and updates after posting | P1 |
| TC-WAL-004 | URD-WAL-004 | Default account routing | 1. A default account is set. 2. A sale payment succeeds. | The auto income posts to the default account | P1 |
| TC-WAL-005 | URD-WAL-005 | Merchant-scoped visibility | 1. A non-owner with access to merchant A only. 2. They list accounts. | Only merchant A's accounts are returned | P2 |
2.4 Vouchers & Ledger (VCH)
| TC ID | URD ref | Scenario | Steps | Expected | P |
|---|---|---|---|---|---|
| TC-VCH-001 | URD-VCH-001 | Voucher is balanced | 1. Any voucher is posted. | Total DEBIT equals total CREDIT | P1 |
| TC-VCH-002 | URD-VCH-002 | Voucher types | 1. Create vouchers of each type. | RECEIPT / PAYMENT / TRANSFER / ADJUSTMENT are all accepted | P2 |
| TC-VCH-003 | URD-VCH-003 | Auto RECEIPT on payment | 1. A sale payment succeeds. | A balanced RECEIPT voucher posts to the default account | P1 |
| TC-VCH-004 | URD-VCH-004 | Auto PAYMENT on PO receipt | 1. A purchase order is received. | A balanced PAYMENT voucher posts | P1 |
| TC-VCH-005 | URD-VCH-005 | Auto voucher on stock movement | 1. Stock is issued for a sale or adjusted. | The matching ledger voucher posts | P1 |
| TC-VCH-006 | URD-VCH-006 | Idempotent posting | 1. A source event is processed. 2. The same event is redelivered. | Only one voucher exists for that source event | P1 |
| TC-VCH-007 | URD-VCH-007 | Voucher numbering | 1. Post several vouchers of the same type for a merchant. | Numbers increment per merchant and type | P2 |
| TC-VCH-008 | URD-VCH-008 | Manual voucher | 1. Owner creates a draft. 2. Owner issues it. | A balanced voucher appears in the ledger with a sequence number | P2 |
| TC-VCH-009 | URD-VCH-009 | Void by reversal | 1. An issued voucher. 2. Owner voids it. | A balanced reversal posts; the original is preserved | P2 |
| TC-VCH-010 | URD-VCH-010 | Transfer between accounts | 1. Owner transfers between two accounts. | A zero-sum TRANSFER voucher records both legs | P3 |
| TC-VCH-011 | URD-VCH-001, URD-VCH-006 | Precision + concurrency boundary | 1. A payment whose amount rounds at high precision. 2. Two results arrive at once. | Balances reconcile exactly; only one voucher is posted; no race corrupts the ledger | P1 |
2.5 Categories (CAT)
| TC ID | URD ref | Scenario | Steps | Expected | P |
|---|---|---|---|---|---|
| TC-CAT-001 | URD-CAT-001 | Seeded categories | 1. View categories for a new merchant. | 14 system categories are present | P1 |
| TC-CAT-002 | URD-CAT-001 | Seeded categories protected | 1. Attempt to remove a seeded category. | Removal is rejected | P1 |
| TC-CAT-003 | URD-CAT-002, URD-CAT-003 | Typed + custom categories | 1. Owner adds a custom INCOME and EXPENSE category, one nested under a parent. | Custom categories are created with the correct type and hierarchy | P2 |
3. Traceability
Every Must requirement maps to ≥1 test case.
URD-PAY-006is a Won't/Planned item, intentionally uncovered.
| URD requirement | Test case(s) | Status |
|---|---|---|
| URD-PAY-001 | TC-PAY-001 | ✅ Covered |
| URD-PAY-002 | TC-PAY-002 | ✅ Covered |
| URD-PAY-003 | TC-PAY-003 | ✅ Covered |
| URD-PAY-004 | TC-PAY-004, TC-VCH-011 | ✅ Covered |
| URD-PAY-005 | TC-PAY-005 | ✅ Covered |
| URD-PAY-006 | TC-PAY-006 | ⚠️ Planned (Won't — not yet built) |
| URD-PRV-001 | TC-PRV-001 | ✅ Covered |
| URD-PRV-002 | TC-PRV-002 | ✅ Covered |
| URD-PRV-003 | TC-PRV-003 | ✅ Covered |
| URD-WAL-001 | TC-WAL-001 | ✅ Covered |
| URD-WAL-002 | TC-WAL-002 | ✅ Covered |
| URD-WAL-003 | TC-WAL-003 | ✅ Covered |
| URD-WAL-004 | TC-WAL-004 | ✅ Covered |
| URD-WAL-005 | TC-WAL-005 | ✅ Covered |
| URD-VCH-001 | TC-VCH-001, TC-VCH-011 | ✅ Covered |
| URD-VCH-002 | TC-VCH-002 | ✅ Covered |
| URD-VCH-003 | TC-VCH-003 | ✅ Covered |
| URD-VCH-004 | TC-VCH-004 | ✅ Covered |
| URD-VCH-005 | TC-VCH-005 | ✅ Covered |
| URD-VCH-006 | TC-VCH-006, TC-VCH-011 | ✅ Covered |
| URD-VCH-007 | TC-VCH-007 | ✅ Covered |
| URD-VCH-008 | TC-VCH-008 | ✅ Covered |
| URD-VCH-009 | TC-VCH-009 | ✅ Covered |
| URD-VCH-010 | TC-VCH-010 | ✅ Covered |
| URD-CAT-001 | TC-CAT-001, TC-CAT-002 | ✅ Covered |
| URD-CAT-002 | TC-CAT-003 | ✅ Covered |
| URD-CAT-003 | TC-CAT-003 | ✅ Covered |
Summary: 27 URD requirements → 28 test cases · 26 covered · 1 intentionally uncovered (Planned).