I don’t think we need to standardize steps 1 - 3. Some standard flows exist already but ultimately this is channel specific.
Token
I agree that the token should be a payment pointer, or more generally I think it should be/or include a URL that is used by the merchant to redeem the token to get paid. So if it’s a JWT or some other thing, one of the properties should be a URL that is used to redeem it.
The problem with a Payment Pointer as the only option is that you may want a more sophisticated authentication of the merchant than simply a bearer token so some token that is bound somehow to a particular merchant might be useful. I think there ARE ways to do this with Payment Pointers and standard HTTP auth mechanisms but they do assume that the payer is able to go online to generate the token.
I’d be interested in hearing ideas for ways a token can be generated offline. E.g. Imagine I have a wallet system that I want to be able to serve pull payments for me but I want to be able to generate the token on my phone quickly without needing to request it from the wallet. Definitely possible but needs some work to standardize.
Payment
I like the idea of a simple protocol over the STREAM data channel to do things like requesting a payment once the connection is established. See my comment on the AnyPay question under Option 2.
I think you could use the same mechanism to query the details about the token however this does mean you need to establish a STREAM connection to perform the query.