On 2013-04-17, at 6:25 PM, Kumar McMillan <[email protected]> wrote:
> Is this what you're thinking? : When mozPay() completes, it passes a receipt
> to the JS callback. The app verifies the receipt either on its own server or
> using the receipt's own verification API. Like app purchases, it could
> whitelist verification domains to prevent hacks. If that were to work, the
> app could be purely client side and accept in-app payments similar to how a
> paid app can be purely client side.
Yes. Although that makes me wonder about the verification process. The
verification process requires the marketplace to maintain a list of all the
sales. I actually think that is a good thing since we are doing this anyway.
But at the moment I know we don't do that for in-app payments. Is it sensible
to think about a receipt that can't be verified against the marketplace?
You will know that the receipt is correctly signed using a trusted key. You
just wouldn't be able to verify it. Would that be enough?
> Another benefit of using receipts is that an app would not be forced to
> manage user identity and track purchase history on its own. If the receipt is
> on device then the item is purchased.
And there's nothing stopping an app developer pushing those receipts up to
their server if they wanted to track it, but the device is the source of truth,
not the server.
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
