956359 - Document server-less in-app payments

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect, P2)

Description

[Kumar McMillan [:kumar]]

We need succinct but detailed docs on how developers can do server-less in-app payments. This should probably go on MDN but might overlap with the custom JS library (bug 956358).

Comment 1

[Kumar McMillan [:kumar]]

Richard Bloor has been working on this

Comment 2

[rbloor]

A couple of questions:
1) The current instructions state "Your manifest must declare an origin for receipt validation." (which given that this is required for all privileged apps anyway seems slightly redundant - but that's not the question). This origin "should be a domain that you control" - doesn't that mean that developers will be only a step or two away from having the features/services they need to implement in-app payments with mozPay (and gaining the advantage of restartable/transferable in-app purchases)?
* Presumably the 'In-app products' page on Marketplace (.../developers/app/fxpay/in-app-products/) will be usable for any app with an origin - e.g. any privileged app - or is it restricted in any other way? If not, is there a danger that developers using mozPay will so will start using it (mistakenly) to create in-app products too?

Comment 3

[Kumar McMillan [:kumar]]

(In reply to rbloor from comment #2)
> A couple of questions:
> 1) The current instructions state "Your manifest must declare an origin for
> receipt validation." (which given that this is required for all privileged
> apps anyway seems slightly redundant - but that's not the question). 

Where is it required? Is that a Marketplace thing? The origin property is only supported in Firefox OS 1.1 so I didn't think it was required. https://developer.mozilla.org/en-US/Apps/Build/Manifest#origin Without it, the platform assigns a randomly generated origin.

> This
> origin "should be a domain that you control" - doesn't that mean that
> developers will be only a step or two away from having the features/services
> they need to implement in-app payments with mozPay (and gaining the
> advantage of restartable/transferable in-app purchases)?

I wouldn't say they are a step or two away. Let's say they have access to some custom domain on a server. They have to:
- run a signing library to check JWT signatures. This usually requires non-trivial compilation of cryptography libraries.
- implement a catalog of products, say, in a database or something.
- write custom code to handle postbacks and transaction status checks.
- invent some way to check the validity of purchases. This would either require tracking user identity or re-using platform receipts.

This is not trivial although we do offer some developer libraries that make the above steps easier. Our fxpay JS library implements all those things. Validating purchases is especially tricky and our solution does not track user identity which is interesting.

I am not entirely sure why Marketplace forces the origin to be a real domain. I should ask some people why that is.

One realistic scenario I'm imagining is an open source app hosted on GitHub pages at a URL like http://appname.github.io/ . This would technically be a domain under the developer's control but not one they could run custom JWT signature checking code from. Also, it would be a completely free domain.

> * Presumably the 'In-app products' page on Marketplace
> (.../developers/app/fxpay/in-app-products/) will be usable for any app with
> an origin - e.g. any privileged app - or is it restricted in any other way?
> If not, is there a danger that developers using mozPay will so will start
> using it (mistakenly) to create in-app products too?

Can you restate the question? Not sure what you mean. Are you asking how do we prevent one app from selling another app's products?

Comment 4

[rbloor]

(In reply to Kumar McMillan [:kumar] (needinfo for quickness) from comment #3)
> (In reply to rbloor from comment #2)
> > A couple of questions:
> > 1) The current instructions state "Your manifest must declare an origin for
> > receipt validation." (which given that this is required for all privileged
> > apps anyway seems slightly redundant - but that's not the question). 
> 
> Where is it required? Is that a Marketplace thing? The origin property is
> only supported in Firefox OS 1.1 so I didn't think it was required.
> https://developer.mozilla.org/en-US/Apps/Build/Manifest#origin Without it,
> the platform assigns a randomly generated origin.
> 

The GitHub readme states "Requirements

To use fxpay to accept in-app payments, the following requirements must be met:

    ...

    Your manifest must declare an origin for receipt validation."

So this isn't correct and can be dropped - or at least restated as "for Firefox 1.1 only"?

> > This
> > origin "should be a domain that you control" - doesn't that mean that
> > developers will be only a step or two away from having the features/services
> > they need to implement in-app payments with mozPay (and gaining the
> > advantage of restartable/transferable in-app purchases)?
> 
> I wouldn't say they are a step or two away. Let's say they have access to
> some custom domain on a server. They have to:
> - run a signing library to check JWT signatures. This usually requires
> non-trivial compilation of cryptography libraries.
> - implement a catalog of products, say, in a database or something.
> - write custom code to handle postbacks and transaction status checks.
> - invent some way to check the validity of purchases. This would either
> require tracking user identity or re-using platform receipts.
> 
> This is not trivial although we do offer some developer libraries that make
> the above steps easier. Our fxpay JS library implements all those things.
> Validating purchases is especially tricky and our solution does not track
> user identity which is interesting.
> 
> I am not entirely sure why Marketplace forces the origin to be a real
> domain. I should ask some people why that is.
> 
> One realistic scenario I'm imagining is an open source app hosted on GitHub
> pages at a URL like http://appname.github.io/ . This would technically be a
> domain under the developer's control but not one they could run custom JWT
> signature checking code from. Also, it would be a completely free domain.
> 
> > * Presumably the 'In-app products' page on Marketplace
> > (.../developers/app/fxpay/in-app-products/) will be usable for any app with
> > an origin - e.g. any privileged app - or is it restricted in any other way?
> > If not, is there a danger that developers using mozPay will so will start
> > using it (mistakenly) to create in-app products too?
> 
> Can you restate the question? Not sure what you mean. Are you asking how do
> we prevent one app from selling another app's products?

Developer is building in app payments into an app with mozPay, developer goes to Marketplace to get app keys, developer sees 'in app products' options, developer starts entering in app product details here, developer wonder why they cannot use the entered products in their mozPay implementation?

e.g. will the in-app products section display only to developers creating apps with fxpay?

Comment 5

[Kumar McMillan [:kumar]]

(In reply to rbloor from comment #4)
> 
> The GitHub readme states "Requirements
> 
> To use fxpay to accept in-app payments, the following requirements must be
> met:
> 
>     ...
> 
>     Your manifest must declare an origin for receipt validation."
> 
> So this isn't correct and can be dropped - or at least restated as "for
> Firefox 1.1 only"?


No, an origin is always required. You cannot use fxpay on Firefox OS prior to 1.1. App developers should see an error like PAY_PLATFORM_UNAVAILABLE https://github.com/mozilla/fxpay#errors

> 
> Developer is building in app payments into an app with mozPay, developer
> goes to Marketplace to get app keys, developer sees 'in app products'
> options, developer starts entering in app product details here, developer
> wonder why they cannot use the entered products in their mozPay
> implementation?
> 
> e.g. will the in-app products section display only to developers creating
> apps with fxpay?

the in-app products section is only useful to a developer who is using fxpay, correct.

Comment 6

[Adam Muntner [:adamm] (use NEEDINFO)]

Is this documentation currently living somewhere publicly visible/where I can see it?

Thanks!

Comment 7

[rbloor]

The original documentation is here: https://github.com/mozilla/fxpay. I'm moving and updating here: https://developer.mozilla.org/en-US/Marketplace/Monetization/In-app_payments_section/fxPay_iap but have been stalled by other priorities - I expect to make progress over the next few days.

Comment 8

[Andy McKay]

Documentation on this is excellent, its done.