Hi all.
I know many of haven't had a chance to test in-app payments yet because our
simulation mode is not fully live. However, you can read about how it works
here: https://developer.mozilla.org/en-US/docs/Apps/Publishing/In-app_payments
There is currently an awkward requirement: as a developer you must run server
code in order to process in-app payments. This means you can't host your app on
github pages and you can'd do payments from a packaged app (without a server).
The rationale for this is that JWTs must be signed with a secret key and this
is how we verify their authenticity. If anyone on the Internet could sign JWTs
then someone could edit the price to $0.00 and get free products. The secret
key must be secured on a server; it's not safe on the client.
Here is a proposal for how to do in-app payments without a server. Let me know
if this sounds sane as far as ease-of-use and security.
First, this proposal would not require any changes to the underlying
navigator.mozPay() API or the current JWT spec. No B2G client changes would be
needed. It would be built on top of these existing APIs.
I think we can introduce server-less in-app payments by hosting a Mozilla web
service on behalf of developers -- that is, a service that any developer can
use.
Instead of this on the app server:
signedJWT = jwt.encode({
request: {
name: 'Rainbow Unicorn',
description: 'A virtual unicorn for Adventure Game',
pricePoint: 1 // EUR 0.89
}
}, '<secret-key>')
and this on the client:
navigator.mozPay([signedJWT])
the developer could do something like this on the client only:
var unicornId = 1234;
payment.start(unicornId, function(jwt, transaction) {
var request = navigator.mozPay([jwt]);
request.onsuccess = function() {
transaction.whenDone(function(error) {
if (!error) {
alert('You bought a Rainbow Unicorn!');
}
});
};
});
How would it work? The Firefox Marketplace (or any server, really) could host a
product catalog that the merchant could manage through a management website.
The merchant would *pre-define* the price, description, etc, for products such
as the Rainbow Unicorn and whatever else. The concept of pre-defining the price
in the product catalog would give us the security needed (I think) to let
anyone on the Internet hit payment.start(unicornId, ...) and retrieve a signed
JWT without harm. An attacker can't edit the price. They can't receive any
funds. If they make a fake app that sells the same product, what is the
incentive? The customer might be confused but the original app owner would
receive the funds, not the attacker.
This theoretical payment JS lib would be a wrapper around the web service. We'd
get the JWT like this:
GET https://mkt/payments/jwt/<productId>
And the JWT would have custom postback URLs, like this:
{
request: {
name: 'Rainbow Unicorn',
...
postbackURL: 'https://mkt/payments/postback/<productId>',
chargebackURL: 'https://mkt/payments/chargeback/<productId>',
productData: 'transactionId=XYZ'
}
}
This would tell the payment provider to post to the service instead of to the
app, like:
POST https://mkt/payments/postback/<productId>
For the app to check that the product was paid for (i.e. postback was
received), it would need to poll something like:
GET /payment/status/<transactionId>
_
That's it. The pros:
- the app developer does not have to host a server
- Thus, more devs can experiment with in-app payments
- the developer does not need to sign JWTs or verify JWT signatures (which
might require compiling crypto libraries)
- the hosted service could double as collecting stats and produce useful
reports like product conversion rate
- we could maybe integrate persona and make payments a bit easier for users
since they'll have one login
The cons:
- if the hosted service goes down, no payments
- we'll need to have a privacy policy, obviously
- the developer will have to manage a catalog of products as opposed to setting
that info in a custom JWT
Are there any security issues with this? Anything I'm missing? The payment lib
code and server endpoints obviously could be cleaned up; I'm looking more for
feedback on security and the general concept.
Thanks for reading.
-Kumar
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
