I did a multi-platform content player a couple of years ago. It wasn't JUCE based but I don't think that would matter.
We setup a basic web commerce site. Pretty basic stuff. Then showed it in a browser window owned by the app on every platform. For each item offered we generated the equivelent of a JUCE UUID. This was then put in as an asset reference in iTunes Connect and the Google store.
Apple doesn't permit direct web commerce, so we tweaked the store pages so that the "Buy" button was an app specific protocol link: ourapp://url.of.next.page?action=buy&code=uuid. On every platform the app intercepted the link before loading (I think that the Juce WebBrowserComponent has something similar). On Linux and Windows the URL was patched back to go through the existing store. On Android and iOS, the link meant to leave the store and do the platform specific purchase.
In both those cases the app has a receipt asset, so we made a php page to post a purchase to the commerce site database and a php page to validate a recipt object and give you the asset.
On platforms without an in-app mechanism, the user went through a normal web store and was emailed a link. The links used a URI that the apps registered, so when you clicked the app opened and loaded the asset. This was pretty trival on OS-X (and would work on iOS but we didn't use it), as well as Windows. It is, or at least was, a major pain on Linux.