Project

General

Profile

Feature #9778 » multipay_validation_senarios.txt

Teja Sriram Sangani, 07/13/2026 11:28 AM

 
## POS multi-method split payment — validation scenarios

### Validation types: **12**

---

### **Type 1 — Checkout gate** (6 scenarios)
1. Customer must be selected before checkout
2. Product quantity must be greater than 0
3. Grand total must be greater than 0
4. Scale weight must be applied before checkout (if applicable)
5. Delivery address required for delivery orders
6. Shipping charges required for delivery orders

---

### **Type 2 — Method selection limits** (7 scenarios)
7. Cash — maximum **1** line
8. Card Manual — maximum **2** lines
9. Card Reader — maximum **2** lines
10. CPP — maximum **2** lines
11. Zelle — maximum **2** lines
12. Cannot add a method when allocation already equals grand total
13. Cannot add a method when that method type is at its limit

---

### **Type 3 — Allocation balance** (7 scenarios)
14. Under-allocated (remaining > $0) → **Process Payment** blocked
15. Over-allocated (remaining < $0) → **Process Payment** blocked
16. Exactly allocated → **Process Payment** allowed
17. **Add remaining to last payment** when under-allocated
18. **Remove extra from last payment** when over-allocated
19. No editable line available → adjustment warning shown
20. Partial excess removal when paid lines prevent full trim

---

### **Type 4 — Per-line amount rules** (7 scenarios)
21. Line amount cannot be negative
22. Line amount cannot exceed grand total
23. Card / CPP / Card Reader minimum **$0.50**
24. Paid non-cash line — cannot decrease below already-settled amount
25. Paid cash line — can decrease (difference returned as change)
26. Failed / cancelled line — editing re-arms to **pending**
27. Processing line — amount edit blocked

---

### **Type 5 — Cash received rules** (6 scenarios)
28. Cash received must be ≥ line amount when amount is still due
29. Cash shortage → **Process Payment** blocked with tooltip
30. Auto cash received = paid so far + rounded-up due
31. Staff can manually override cash received
32. Cash received locked while payment is processing
33. Cash received locked when line is fully paid with no due left

---

### **Type 6 — Method configuration** (4 scenarios)
34. Card Reader — reader must be selected
35. CPP — Credit / Debit type must be selected
36. Switch to Stripe terminal — requires available reader
37. Switch to CPP terminal — device must be available

---

### **Type 7 — Deletion rules** (7 scenarios)
38. Delete **pending** line — allowed
39. Delete **failed** line — allowed
40. Delete **cancelled** line — allowed
41. Delete **waiting** line — allowed
42. Delete **completed** line — not allowed
43. Delete **processing** line — not allowed
44. Payment slot labels renumber after deletion (e.g. card1, card2)

---

### **Type 8 — Edit / reassign after partial payment** (8 scenarios)
45. Increase paid **Cash** line → only delta charged
46. Increase paid **Zelle** line → Zelle re-confirm + delta charged
47. Increase paid **CPP** line → only delta charged on terminal
48. Increase paid **Card Manual** — add new card line for extra (cannot go below settled amount)
49. Decrease paid **Cash** → excess returned as change
50. Reassign under-allocated remainder to last editable line
51. Reassign over-allocated excess removed from last editable line(s)
52. Reassign may remove entire last line if needed to fix over-allocation

---

### **Type 9 — Zelle confirmation gate** (3 scenarios)
53. Unpaid Zelle line → confirm modal required before payment continues
54. Zelle top-up on already-paid line → re-confirm required
55. Fully settled Zelle line → not re-prompted

---

### **Type 10 — Process Payment submit checks** (7 scenarios)
56. At least one payment method required
57. Customer required
58. Full allocation required (total = grand total)
59. Sufficient cash received
60. Card Reader selected where required
61. CPP type selected where required
62. Card / CPP / Reader amount ≥ $0.50 on submit

---

### **Type 11 — During-payment flow (cancel / fail / resume)** (10 scenarios)
63. Payments run in sequential order
64. Later terminal lines show **“Waiting — complete previous payment”**
65. Declined card → **failed** state
66. Cancel card → **cancelled**, return to selection (no receipt)
67. Cancel mid-terminal → clean abort, no hang, no false receipt
68. **Process Payment** again after cancel → resumes from pending line
69. Two Card Manual lines with **same amount** → both confirm separately
70. Two CPP lines with **same amount** → both terminal confirm separately
71. Receipt only after **all** terminal lines are paid
72. Full split cancel → refund breakdown + pending intents cancelled

---

### **Type 12 — Backend split validations** (8 scenarios)
73. Payment methods total must equal grand total
74. Maximum **10** split payment lines
75. Each line amount must be greater than 0
76. Unsupported payment method rejected
77. Cash received cannot be less than allocated amount (server-side)
78. Card / CPP minimum $0.50 (server-side)
79. Resume charge cannot exceed backend remaining balance
80. Sale cannot finalize while terminal lines are still pending

---

## Summary calculation

| Item | Count |
|------|-------|
| **Validation types** | **12** |
| **Total validation scenarios** | **80** |

---

**One-line summary for documentation:**

> POS multi-method split payment has **12 validation types** covering **80 test scenarios**, including method limits, allocation balance, deletion, post-payment value reassignment, Zelle confirm, cancel/resume flow, and backend amount checks.
    (1-1/1)