https://nimiq.github.io/tutorials/nimiq-checkout
The idea is to give a low-level, from-scratch introduction on how to embed Nimiq payments into a web-application. I want to keep it short and focussed on the absolute basics, but there could be follow-ups on other interesting Nimiq Hub API aspects.
Let me know, looking forward to hearing your feedback.
Brilliant, really appreciate these tutorials, thank you!
I also checked out Gie’s awesome Nimipay. His HollowMask is also very intriguing project…
I am interested in the info returned in the promise signedTransaction. Say the item sold was not an icecream but a virtual blaster for an in game robot, how to go about confirming I had already bought the blaster and it was available for use next time I play the game? (Assuming I could have saved the signedTransaction’s hash and human readable address of the sender in a players db).
Any pointers appreciated
Pete
A blaster for an in-game robot?? Sounds promising! 
I assume you have a database behind your game, so you could store some data saying “player X bought this blaster for Y NIM with the transaction hash Z”. The game can then verify that the transaction for the hash Z was indeed confirmed and that the value Y matches, If that holds, the blaster should become available. Wdyt?
Hi, thanks for input.
Indeed, but how to secure it… say Bob buys the blaster with his hard earned nim, what stops Alice eyeballing the dev wallet address transaction hash’s and amount then loading in Bob’s blaster.
I guess traditional player accounts with emails and logins would satisfy requirements, but then nim is just an extra payment option. It would be great to be fully nimiq centric, no email login, where by the initial nim purchase sets the player id (sender wallet address?) and for the player to load his robot next time they play must sign? their address to confirm ownership of player id. Super secure login of sorts.
I will take a look at the documentation further, does this sound logical?
ps. aware this may be wandering off your check out topic, happy to move it elsewhere
You can have Bob sign a message with the address that was used to buy the blaster to prove ownership of the account associated with that tx hash. How you specifically use it in your game depends on the specifics of the game, but it’s easy for Bob to prove he bought the blaster and impossible for Alice to forge proof.
I have some games in the works that do log in / purchasing with Nimiq accounts, lmk if you need more help with it.
Yes, thanks @Chugwig, I’d go the same direction here if you want to avoid the server side. I really like where this conversation is going! These are real use cases. I’m currently working on extending the checkout ideas, I’m trying IPFS with the help of @Richy as a decentralized storage… WIP
I was actually looking into IPFS for a new Nimiq project I’m working on but I think I might not use it. The tech doesn’t seem mature enough yet, especially since an IPFS node is needed and I don’t want to go through Infura. If you guys come across anything IPFS related that is relatively easy to implement please let me know as I’d be interested in looking into it.
If only there was a native browser implementation of IPFS where, like Nimiq, the ipfs node could be created in your browser 
[EDIT] after posting this I realized while I’ve looked into IPFS in the past, I never actually checked if there was a browser capable IPFS node. Seems someone is looking into it with js-ipfs but the project is still in Alpha which brings me back to “the tech doesn’t seem mature enough yet” ;(
@Chugwig, @svub thanks for the info guys. The message signing is great and the hub makes it easy. For serving the secure game asset (blaster), with a clientside signed success, would the signedMessage.signature be the best parameter to verify by comparing to the players previously stored purchase signature held in server player database.
I will have play and get back. I orginally built the game in Unity and C#, so remaking it with three js which though a learning curve is a very pleasurable one.
Good luck with the IPFS research!
Yep, @Chugwig, using the IPFS js implementation, but I share your impression that it’s all still very early stage.
If I’m following you correctly signedMessage.signature would indeed be what you wanted.
You wouldn’t compare it against any sort of previously stored signature though, at least I wouldn’t in this scenario. Instead, on your server you’d be keeping track of which addresses own which assets and the user would be sending you the message to prove they are the owner of that address (and therefore all the assets you have associated with that address).
That’s right, you’d use message signing to log the user in. FYI, we plan to roll out Nimiq-ID (Nimiq-based single sign-on) as a convenient solution before the end of this year.
From the moment your user has verified to own the address, you can verify all purchases on the blockchain.
Will that be a feature added to the hub or a separate thing? I’m very interested in seeing what Nimiq ID is planned to be, since from a frontend perspective I don’t see how it adds any convenience since it’ll just be signing a message (unless I’m missing something). Is the point just to have a different UI for the Nimiq ID login flow even though it uses signing under the hood.
And on the backend, such a login flow would require the developer to do something on their backend either way, so would that also be part of Nimiq ID (with both a frontend and backend version of the library) or would Nimiq ID would just be the frontend and the dev is still left baking their own backend (which I don’t mind, but is less convenient depending on which kind of devs Nimiq ID is targeted at).
Is the point just to have a different UI for the Nimiq ID login flow even though it uses signing under the hood.
I think yes, that’s it. @NimiqSoeren will know more details I’m sure.
It’s planned to be a special UI for NimiqID, but also a standardized object that is getting signed. We will look into oauth2, OpenID and others to determine a good set of properties to sign, together with anyone interested in shaping the NimiqID feature.
The server part is planned to also be part of the release, with a nodejs Middleware and PHP lib to start. A PHP utils package already exists that can be used to verify signatures: