View Single Post
Old 08-19-2023, 06:01 AM   #3
Jim Chapman
Addict
Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.Jim Chapman ought to be getting tired of karma fortunes by now.
 
Posts: 309
Karma: 2025434
Join Date: Oct 2009
Device: Lumia 950 Phone
Quote:
Originally Posted by Quoth View Post
You can setup a PayPal button on a website easily. You'd of course need each download APK to have a unique ID and then the payment acknowledgement a key. Or have the program email and the licence key related to the email address of Paypal etc. I've used several schemes in the past.

Licence servers are horrible, though if it's a one time check, not too bad.
See Plays for Sure and expiring ACSM.
I spent a while puzzling about various ways to accept, collect and validate PayPal payments, in a way that would let me reliably tie the PayPal acquisition to a particular installation and user of the app - and there are certainly various ways to do it. A particular concern was how to deal with payments being reversed some time after they are initially captured. I chose this particular scheme because it is reasonably simple, and it means that most of the work is being done in an Azure Function rather than on the user device. It also supports the logic 'pay once and you can use the app on multiple devices' which I think is a useful feature to offer.

One clarification: I don't actually propose to store user email addresses in the licence server database; rather I will put the email address through a one-way hash function, and store the hashed value. From a privacy perspective I think that's helpful because it means that even if my database got disclosed and I was compelled to share the encryption key (thinking of law enforcement or insolvency proceedings here!) the actual user email addresses aren't there. Of course for my use case (check whether any entry in the database matches a certain user email address) it still works OK using the hashed addresses. If there is the occasional hash collision, its effect would just be that I grant a licence I really shouldn't have granted. I can live with that.

A challenge (maybe you can help here?) is that I couldn't come up with a privacy statement that explains this in words that a regular user would understand. I think if I start talking about 'one-way hashes' I will bewilder rather than enlighten!
Jim Chapman is offline   Reply With Quote