Feature #9778
openimplement the multipayment methods harware (dejavoo,stripe) implementations and include all the remain methods to test and check all the senarios
Added by Teja Sriram Sangani 22 days ago. Updated 21 days ago.
Files
| multipay_validation_senarios.txt (5.78 KB) multipay_validation_senarios.txt | Teja Sriram Sangani, 07/13/2026 11:28 AM | Delete |
Subtasks
Related issues
Updated by Teja Sriram Sangani 22 days ago
- Status changed from New to In Progress
- % Done changed from 0 to 60
Fixed false receipt on resume — After cancelling or declining a payment (e.g. Card Manual 2), clicking Process Payment again no longer marks the sale fully paid or shows a receipt without collecting the remaining amount.
Fixed split resume routing — Resume now continues from the first pending terminal method (CPP / Card Manual / card reader) instead of skipping ahead or completing early.
Fixed equal-amount split bugs — Two CPP or two Card Manual lines with the same amount now each get their own terminal/card confirmation instead of stopping after the first one.
Fixed “Invalid Amount” error on resume — Stopped re-sending already-settled cash/Zelle lines on resume, which caused the total paid amount vs grand total mismatch and blocked the next payment from opening.
Added phased resume flow — Split resume runs in order: cash/Zelle top-ups → CPP top-ups → new terminal lines → sequential terminal collection.
Improved UI/backend sync — Cash, Zelle, and CPP lines reconcile by payment slot so paid, cancelled, and waiting states match what the server actually settled.
Fixed cancel during terminal payment — Cancelling mid-payment returns cleanly to the selection screen with no hang, no endless retry, and no false receipt.
Added top-up support on resume — Increasing an already-paid Cash/Zelle/CPP line charges only the delta, not the full amount again.
Backend safeguard — Split sale is not finalized while any terminal payment line is still pending.
Perform comprehensive negative testing for all multi-payment scenarios.
Continue testing once the payment simulator is available and operational.
Resolve any issues identified during negative testing.
Complete final end-to-end validation before marking the task as complete.
Updated by Teja Sriram Sangani 22 days ago
Updated by Teja Sriram Sangani 21 days ago
- Status changed from In Progress to Resolved
- % Done changed from 60 to 90
- Investigated and documented Dejavoo/CPP key injection (RKL) issues, identifying that Key injection is in progress and RKL Failure. Login Connection failed are terminal configuration issues rather than POS amount calculation issues. Updated POS/backend error handling to provide clearer guidance, with RKL completion required by Dejavoo support.
- Fixed Stripe card reader simulator issues by resolving the Reader Missing error during Confirm Payment. Improved reader resolution logic using refs/fallbacks and added clearer error messaging.
- Updated backend environment handling to allow Stripe Terminal simulator in test environments (`NODE_ENV2=test` or `STRIPE_TERMINAL_SIMULATOR=test`) while keeping simulation disabled in production (`NODE_ENV2=prod`).
- Resolved the double modal issue during Stripe split payments by hiding the Payment Status loading modal whenever the Card Reader Payment overlay is active, ensuring a cleaner payment flow.
- Restored CPP (Dejavoo) as the default Card Reader option in checkout while allowing users to switch to Stripe when using Stripe terminals or the simulator.
- Performed comprehensive negative testing across POS multiple payment methods (CPP, Stripe, split payments, card reader, and simulator scenarios) to validate edge cases, verify bug fixes, and ensure payment stability and reliability.
this are the changes i do to complete the multiple methods payment feature on pos screen.
Now need to work on sales screen to check the Sales screen to validate the formatting and segregation of multiple payment methods, ensuring each payment method's value is accurately reflected in the Tally Dashboard sales totals without any missing values.