Feature #9911
openSplit payment improvements — multi-line methods, card reader cancel/resume, Stripe↔CPP switch, and over-allocation bugs
Subtasks
Related issues
Updated by Teja Sriram Sangani 14 days ago
- Status changed from New to In Progress
- % Done changed from 0 to 60
*Enabled multi-line split payments — Staff can add the same method twice (Zelle, Manual Card, Card Reader/CPP); Cash remains limited to 1 line per sale.
*Added payment slot tracking — Each line gets a stable ID (`zelle1`, `card_reader1`, `cpp2`, etc.) and display labels (e.g. “Zelle Payment 1”, “Card Reader Payment 2”) for UI and backend sync.
*Implemented sequential terminal processing — Card Reader and CPP lines process one at a time; later lines show “Waiting — complete previous payment” during active processing.
*Fixed Stripe ↔ CPP switch mid-resume — Switching Card Reader 1 from Stripe to CPP no longer drops Card Reader 2; both lines are included in resume/allocation flow.
*Fixed `resume-split-payment` amount mismatch — Resolved error where only one card reader amount was sent (e.g. $22 vs $42 remaining).
*Fixed card reader cancel behavior — Cancelling the first reader during processing unlocks the second line for edit; if the first is already paid and the second is cancelled, only the second is cancelled.
*Fixed “Remove extra $20” / negative Remaining (-$42) — Stopped double-counting of already-paid Zelle/cash lines in the Payment Allocation panel.
*Fixed “Sale is not a pending split sale” error — Backend no longer marks a split sale as fully paid while pending card/terminal rows still exist.
*Added backend safeguards — Prevent duplicate cash/Zelle appends over grand total; heal incorrectly finalized sales; drop orphan pending rows when total is already collected.
*Improved frontend/backend reconciliation — Cash/Zelle/Card Reader lines sync by `paymentSlot`; resume sends only top-up deltas, not full paid amounts again.