Android Question Sharing a link via NFC, cross-platform

[nwhitfield]

I may well have missed exactly how to do this, and it feels like it should be easy, but I just can't make it happen...

I want to be able to generate a URL in an Android app, and share that via NFC with both Android and iPhone - the link will be to a payment gateway, so it would be great if people can just wave their phone at mine, and get the link.

However, some of the NFC examples aren't set up for B4XPages, and with the others, although I can see the tag has been written, and the other phone makes an NFC detected sort of noise, that's as far as I can get with

Sub nfc_CreateMessage As List
    Return Array (nfc.CreateUriRecord(PaymentLink))
End Sub

from the Android Beam tutorial. So, a) can this be done in a way that will launch the browser automatically on both Android and iOS, and b) what am I missing?

 

[Erel]

I don't think that it is possible. You can transfer data with Android beam but I don't see how it will work with iOS.

 

[drgottjr]

have them scan this.

 

[nwhitfield]

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.

 

[drgottjr]

saw your pos. at the risk of overstaying my welcome, i can't help but comment:
allow customers to take their items to your checkout where you add up the total cost and show them a qr code with the payment link and full amount. somebody has already figured out how to generate the appropriate qr codes for payment for a each item. forget that; just generate 1 qr code for the total at the end.

 

[nwhitfield]

Yes, that's what it does; we also have on POS material a QR code for each individual product, if people want to just buy, say, one tie clip.
But there will be some who want a whole bunch of things, so that little web page does the adding up and generates the QR for the total.

Using the pickers for each item in the way the script does means that our volunteers don't have to worry about maths, or mis-keying amounts. Plus it ensures that the receipt and order info includes all the details we need.

And, because most of these are very small, pocketable items, we prefer to keep them behind the counter - other than the display samples - until people have paid. As I say, it's designed for our very specific situation, but might be useful for others.

 

[nwhitfield]

So, I'm still trying to work on getting a URL beamed from one Android device to another; I'll not worry about iOS for now.

I call nfc.PreparePushMessage, but having added a log statement to the example above, the CreateMessage sub is never called, even though I hear the NFC tone when bringing devices together.

What am I missing here?

 

[drgottjr]

not to answer your question, but beam was discontined a few years ago and is deprecated as of android 10. in other words, whatever issues the api had, it will continue with the same issues until google pulls the plug. add to that incompatability with ios, and you're boxing yourself into a corner.

 

[nwhitfield]

Oh well; nice idea while it lasted. I'll just stick with the QR for now, and hope there are some improvements on the NFC side of things coming down the line.

 

[drgottjr]

to be clear, i'm not saying that you can't get it to work with beam; i'm saying that
no further development is being done on the api. so whatever problems android
discovered (and perhaps you discovered one of them) will not be addressed. beam
was not designed for the purpose you wanted to use it for. in google's eyes, its
intended purpose (file transfer) failed. for a number of reasons. google switched to
bluetooth or wifi, neither of which requires the proximity factor nfc requires.

for grabbing a url, qr code is the solution. i regret that i couldn't adequately show you
how it works equally as well at check out time as it does for purchasing 1 item.

look, if you are driven to use nfc, you could look into HCE. this allows your device to act
like an nfc ndef tag. i think there may be an implementation here somewhere. when someone
else's nfc-supported device touches yours, the other device sees your device as an nfc tag
and reads it.

 

[nwhitfield]

I'm fine with QR codes - I've built an app (and the tiny POS site) around that; I just thought that it would be handy to have NFC - if it could be made to work easily - or some other mechanism for people who are reluctant to use a QR code. I hope that, especially after two years of almost everything having a QR code slapped on it, people will mostly be ok.

But in the past we have found some people are very reluctant to try payment methods that don't look like exactly what they're used to (and for americans, that's often not a big range).

Anyway, this is how it's presented in the app I've been working on (which also uses the EscPos printer class to offer receipts on the spot, for those who want them)