I vote for "canceled" or even more descriptive "canceled by customer"

I don't think that's a good idea, as merchant are used that inavlid no matter how akward that status sounds, usually means it requires their reaction of some sort, where as canceled shouldn't.

I am not sure I would want to ship this until we get more feedback from people, I still don't see why being able to cancel a payment screen should be a feature.

@pavlenex The scenario is this... Imagine a store, is using the Keypad only view of the POS app. The store enters the price on the tablet they are using to run the app.

They present the QR payment screen to the customer. For whatever reason, the customer does not scan the QR (they pay cash, they leave, Satoshi walks by..).

The store now has to wait 15 minutes before they can get back to the keypad to enter another price for another customer.

@haxwell You can either go back or reload the POS app and you will be taken to the keypad to enter another price for another customer.

Most devices mobile and desktop have a native way of going back.

Perhaps there is value in having an indicator/button to return to the POS keypad screen if an invoice was generated from the POS keypad, but no need to mark the invoice canceled since AFAIK there isn't any downside to having several unpaid invoices as long as they don't form a chain of unpaid invoices larger than the address gap.

@jacobburrell Didn't mean to offend you.. You are right. Still, I don't think it is a good idea to allow/expect the user, especially the customer, to go back, and move forward, etc. It is cleaner if the application handles that, and ideally does not allow (or at minimum, not need) the native methods. We could educate business owners to "reload the app" etc., but that is not the best user experience.

A cancel button, which an average user would expect to see, on the payment screen is cleanest, I'd say.

Perhaps there is value in having an indicator/button to return to the POS keypad screen if an invoice was generated from the POS keypad

That is all I am asking.

As far as the state the invoice should be in when you press the Cancel button, I don't know. I am studying the code, but right now I have zero knowledge there.

We could use the expired status. Just allow the user to set it via a cancel button, which takes you back to a CancelUrl. It should only appear on the checkout page if the invoice was created with a CancelUrl in metadata. How does that sound?

Going back is still shitty as most eCom software use an intermediate page that auto-redirects you to the checkout. Going back takes you back there. The destination should be a special URL that can do things like update the order and restore the contents of your cart, in the process potentially unblocking reserved stock qty etc...

Your thoughts @ndeet ?

the redirect URL should be used IMO, and we could maybe add a query string parameter something like "src=user-cancelled"

Maybe it is not needed to mess with the invoice status at all, currently when a user uses back button and nothing changed then I pick up the existing invoice and redirect him again there. You just need to make sure to track the latest invoice id on the order to avoid getting the order expired by the webhook even if there is a new invoice already.

The concept of a "cancelUrl" is very common in payment flows, for the above mentioned reasons. A user might want to abort and use a different payment option. We currently only have the redirectUrl which is supposed to be called on successful payment, other providers like stripe call it "successUrl", see here they have both https://stripe.com/docs/js/deprecated/redirect_to_checkout#stripe_checkout_redirect_to_checkout-options-cancelUrl

It depends on the ecom system but in WooCommerce, Opencart, they have a destinction between an payment success and cancelled status. On WooCommerce for example I override the content of the "order-received" page and show the payment status and tell the customer that something went wrong but the order is finished at this state, cart gets emptied even if still unpaid. So I can't redirect the customer back to the checkout so he tries again. The order is finished with cancelled (expired) status, customer can try pay in their order history or create a new order which is not ideal. With an optional cancelUrl I could handle that case and redirect back to checkout like when the customer uses the browsers back button.

An additonal parameter could solve that problem on some systems but not for WC and OpenCart for above reasons. A separate cancelUrl would make it more flexible overall.

Edit: also Shopify has a cancel_url for offsite payment in case customers decide to abort payment https://shopify.dev/docs/apps/payments/implementation/process-a-payment/offsite#payment_method-data-hash