Closed joshheald closed 1 month ago
Thanks for reporting! 👍
Blocked while awaiting designs especially for errors
@joshheald is it ok for me to take this task as we discussed regarding the UI changes?
@bozidarsevo Of course 😊
@malinajirka is going to set up a new project for the UI work anyway, so this is in a new sub-project now.
I suppose we can close this one since we pretty much separated parts of this into different issues?
@bozidarsevo, I think so. @joshheald, can we close this?
Yes, the remaining checkboxes should all be picked up in #13481.
Now that payment messages will be shown inline, we should implement that UI instead of a modal alert.
These will generally be simple views, but in the case of errors, they do need to show buttons. We don't yet have final designs for these error states, but can use our best judgement for now.
Please note – most of these already have Views and all have ViewModels for the new POS – see:
Classes\POS\Presentation\Card Reader Connection\UI States\Reader Messages
for Views (this hierarchy is wrong, feel free to move them to the folder below)Classes\POS\Presentation\Card Present Payments\Reader Messages
for ViewModelsStates
[x]
preparingForPayment
– uses a spinner in the existing modal implementation, has a cancel button, but probably doesn't need it in the new implementation.* Design WIP: TfaZ4LUkEwEGrxfnEFzvJj/WooCommerce-POS?node-id=1439-73824&t=Tk717tGAuZcHIbiT-4[x]
tapSwipeOrInsertCard
– should show the relevant payment types, which are provided by the service.* Design: TfaZ4LUkEwEGrxfnEFzvJj/WooCommerce-POS?node-id=1439-73824&t=Tk717tGAuZcHIbiT-0[x]
processing
[x]
displayReaderMessage
– should show the message provided, which will be localized by Stripe.[x]
success
– not really inline, this should move us to the payment complete screen. We should consider splitting this out.[ ]
error
– should show error details, with a retry button*[ ] `nonRetryableError – should show error details*
[ ]
cancelledOnReader
– not possible with M2 readers, only WisePad/TTP, so can be minimally handled for now.*: These messages have cancel buttons when shown modally in the existing app implementation. Does cancelling the payment make sense with the inl-ine presentation, especially with no option to pay by cash?
What should happen to the order after they cancel the payment? @joe-keenan, your thoughts here would be appreciated... but happy to chat about it sync if that would help.
Perhaps, to allow people to cancel a payment and use a different card (especially from errors) we should show the cancel button. Once cancellation is done, we can prepare the reader to take payment again, as we do when we first show the Totals/Checkout screen