Well, funny you should mention that; this idea came about because of a need to be easily able to accept payments at an event, and I've done a minimalist POS that lets you select products, then displays the QR code for a Stripe payment link. Past experience has proved that some people (especially Americans) don't like seeing their card details keyed into someone's mobile phone, so having them complete a purchase on their own device is likely to be more reassuring.
You can see the code for my tiny POS
on Github or try it out on our
dev site (charges won't actually be applied; it's in Stripe's test mode)
As I say, it's a really minimal POS, but it solves the problem I outlined in the readme. My thinking was that one way it could be made more useful, and more like the ways people already pay, was by sharing the URL using NFC, instead of the QR code, and for that I'd have to do an app version.
But if we can't easily trigger a payment link via NFC cross-platform, it's probably not worth spending ages on. I realise there's a library that will let you read a card via tapping, but I expect that's much the same as used in some other apps that allow you to bill via your phone - you still have to enter the CVV number manually. And though you can read the virtual card number that Google or Apple Pay provides, there's no way in their respective wallets to see those other details for virtual cards.
Ultimately - and the main reason for not busting a gut over this - a lot of this problem will go away, as Stripe (and at least one other processor) have announced they'll be rolling out the ability to accept payments in phone apps by tapping to use Apple/Google Pay, at which stage I expect it'll be incorporated into existing tools, and a fudge like this won't be needed.