proposal for in-app payment development

[Kumar McMillan]

Hey all, I wanted to get some feedback on a proposal for how developers could work with our fxpay library for easier in-app payments.

The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=981102
fxpay lib: https://github.com/mozilla/fxpay

Problem to solve: Before a developer submits their app to the Marketplace, they need a way to write code using the fxpay library. This allows them to get everything hooked up and ready for app submission.

Proposal: We add a new parameter to fxpay.getProducts({fake: true}) that lets them work with fake products.

The developer flow would look like this:

- Start building some packaged app locally
- Include the fxpay library
- Push the app to a Firefox OS Simulator or device using App Manager
- Write some code using fxpay.getProducts({fake: true}) *or* fxpay.getProducts({fake: [{name: ‘My Test’, pricePoint: 10, ...}]}).
- With fake:true, the library will return 2-3 fake products with hard-coded names, prices, etc.
- With an explicit array of fake products, those products will be created/fetched internally and returned.
- Write more code that puts a buy button in their app, calling fxpay.purchase(productId, callback) with the results of fxpay.getProducts().
- When they tap a buy button, they’ll see a *simulation* screen in our payment provider. This will allow them to simulate a successful purchase or a failure.
- Write more app code to process the fulfillment of purchases, using their callback in fxpay.purchase().
- On app startup, fxpay.init() will process test receipts for each purchase; they will validate like regular receipts. This would allow the developer to implement their onrestore() callback using the fake products.

When everything is working how they like, the submission flow is:

- Change their code to call fxpay.getProducts() without the fake argument
- Submit the app to the Marketplace
- Set up payments which includes entering bank details
- Go to the in-app products tab
- Enter in real product names, descriptions, prices
- Wait for approval.

As a public app, the call to fxpay.getProducts() without arguments will now retrieve the *newly created* products rather than the fake ones. Purchasing the products would trigger a *real* purchase, not a simulation. This part is already implemented.

Here are some notes:

- we’ll have to create fake products on the fly using a custom API endpoint
- we can use type=simulate for the fake products (this already exists)
- the inapp JWT API will look for type=simulate and will create a simulation-only JWT at purchase time.
- the payment postback will look for type=simulate and generate test receipts rather than real receipts.
- since the API is public, we may need to rate-limit the creation of unique fake products to prevent flooding.
- we may also want to delete fake products after a couple days

Pros? Cons? Anything I missed? Thanks for reading this far!


-Kumar

[Harald Kirschner]

This looks great. I’d love to see it working within an app. Do we have that or shall I make one to give the whole flow a test ride?

/Harald

Partner Engineer & Web Craftsman | har...@mozilla.com 

[Kumar McMillan]

On Jul 24, 2014, at 4:05 PM, Harald Kirschner <hkirs...@mozilla.com> wrote:

> This looks great. I’d love to see it working within an app. Do we have that or shall I make one to give the whole flow a test ride?

If you could make an app using fxpay, that would be fantastic! I was planning to make a call to anyone interested in doing this. What we’d be looking for are devs to try using fxpay with fresh eyes then see what works or what feels awkward then iterate on the API.

Until we have the features I proposed (below) you’d have to submit an app to one of our test servers to try it out. I can follow up with instructions on that.

[Nick Desaulniers]

This looks nice and simple. I think it looks great! Great job
designing such an implementation flow for
developers.

Thanks,
~Nick Desaulniers
Open Source Zealot
Mozilla Corporation

On 7/24/14 2:02 PM, Kumar McMillan wrote:
> Hey all, I wanted to get some feedback on a proposal for how developers could work with our fxpay library for easier in-app payments.
>
> The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=981102
> fxpay lib: https://github.com/mozilla/fxpay
>
> Problem to solve: Before a developer submits their app to the Marketplace, they need a way to write code using the fxpay library. This allows them to get everything hooked up and ready for app submission.
>
> Proposal: We add a new parameter to fxpay.getProducts({fake: true}) that lets them work with fake products.
>
> The developer flow would look like this:
>
> - Start building some packaged app locally
> - Include the fxpay library
> - Push the app to a Firefox OS Simulator or device using App Manager

> - Write some code using fxpay.getProducts({fake: true}) *or* fxpay.getProducts({fake: [{name: �My Test�, pricePoint: 10, ...}]}).

> - With fake:true, the library will return 2-3 fake products with hard-coded names, prices, etc.
> - With an explicit array of fake products, those products will be created/fetched internally and returned.
> - Write more code that puts a buy button in their app, calling fxpay.purchase(productId, callback) with the results of fxpay.getProducts().

> - When they tap a buy button, they�ll see a *simulation* screen in our payment provider. This will allow them to simulate a successful purchase or a failure.

> - Write more app code to process the fulfillment of purchases, using their callback in fxpay.purchase().
> - On app startup, fxpay.init() will process test receipts for each purchase; they will validate like regular receipts. This would allow the developer to implement their onrestore() callback using the fake products.
>
> When everything is working how they like, the submission flow is:
>
> - Change their code to call fxpay.getProducts() without the fake argument
> - Submit the app to the Marketplace
> - Set up payments which includes entering bank details
> - Go to the in-app products tab
> - Enter in real product names, descriptions, prices
> - Wait for approval.
>
> As a public app, the call to fxpay.getProducts() without arguments will now retrieve the *newly created* products rather than the fake ones. Purchasing the products would trigger a *real* purchase, not a simulation. This part is already implemented.
>
> Here are some notes:
>

> - we�ll have to create fake products on the fly using a custom API endpoint

[Mark Striemer]

Since the products aren’t being created on the fly normally I’d
suggest where the developer specifies that they are simulating
be moved to `fxpay.configure`.

// Setup in one place.
fxpay.configure({fake: [{/* product data */}]});

// This code that may be scattered throughout remains unchanged.
fxpay.getProducts(function (err, products) {
});

Mark

On Jul 24, 2014, at 4:20 PM, Kumar McMillan <kmcm...@mozilla.com> wrote:

>
> On Jul 24, 2014, at 4:05 PM, Harald Kirschner <hkirs...@mozilla.com> wrote:
>
>> This looks great. I’d love to see it working within an app. Do we have that or shall I make one to give the whole flow a test ride?
>
> If you could make an app using fxpay, that would be fantastic! I was planning to make a call to anyone interested in doing this. What we’d be looking for are devs to try using fxpay with fresh eyes then see what works or what feels awkward then iterate on the API.
>
> Until we have the features I proposed (below) you’d have to submit an app to one of our test servers to try it out. I can follow up with instructions on that.
>
>>
>> /Harald
>>
>> Partner Engineer & Web Craftsman | har...@mozilla.com
>>
>> From: Kumar McMillan <kmcm...@mozilla.com>
>> Reply: Kumar McMillan <kmcm...@mozilla.com>>
>> Date: July 24, 2014 at 2:03:08 PM
>> To: Marketplace Development <dev-mar...@lists.mozilla.org>>
>> Cc: Mark Striemer <mstr...@mozilla.com>>, Jared Kerim <jke...@mozilla.com>>, Harald Kirschner <hkirs...@mozilla.com>>, Nick Desaulniers <ni...@mozilla.com>>, rbl...@mozilla.com <rbl...@mozilla.com>>
>> Subject: proposal for in-app payment development
>>

>>> Hey all, I wanted to get some feedback on a proposal for how developers could work with our fxpay library for easier in-app payments.
>>>
>>> The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=981102
>>> fxpay lib: https://github.com/mozilla/fxpay
>>>
>>> Problem to solve: Before a developer submits their app to the Marketplace, they need a way to write code using the fxpay library. This allows them to get everything hooked up and ready for app submission.
>>>
>>> Proposal: We add a new parameter to fxpay.getProducts({fake: true}) that lets them work with fake products.
>>>
>>> The developer flow would look like this:
>>>
>>> - Start building some packaged app locally
>>> - Include the fxpay library
>>> - Push the app to a Firefox OS Simulator or device using App Manager

>>> - Write some code using fxpay.getProducts({fake: true}) *or* fxpay.getProducts({fake: [{name: ‘My Test’, pricePoint: 10, ...}]}).

>>> - With fake:true, the library will return 2-3 fake products with hard-coded names, prices, etc.
>>> - With an explicit array of fake products, those products will be created/fetched internally and returned.
>>> - Write more code that puts a buy button in their app, calling fxpay.purchase(productId, callback) with the results of fxpay.getProducts().

>>> - When they tap a buy button, they’ll see a *simulation* screen in our payment provider. This will allow them to simulate a successful purchase or a failure.

>>> - Write more app code to process the fulfillment of purchases, using their callback in fxpay.purchase().
>>> - On app startup, fxpay.init() will process test receipts for each purchase; they will validate like regular receipts. This would allow the developer to implement their onrestore() callback using the fake products.
>>>
>>> When everything is working how they like, the submission flow is:
>>>
>>> - Change their code to call fxpay.getProducts() without the fake argument
>>> - Submit the app to the Marketplace
>>> - Set up payments which includes entering bank details
>>> - Go to the in-app products tab
>>> - Enter in real product names, descriptions, prices
>>> - Wait for approval.
>>>
>>> As a public app, the call to fxpay.getProducts() without arguments will now retrieve the *newly created* products rather than the fake ones. Purchasing the products would trigger a *real* purchase, not a simulation. This part is already implemented.
>>>
>>> Here are some notes:
>>>

>>> - we’ll have to create fake products on the fly using a custom API endpoint

[Mark Striemer]

I like the idea of using simulated payments but I’d rather see the products created in the devhub. Kumar pointed out that it would be nice to stay in the code if you’re already there but I think there are advantages to this too.

1. The developer goes to a “Simulated in-app products” page in their devhub account [1].
2. They enter all of their products as usual but also include their app’s origin [2].
3. They put fxpay into simulation mode with `fxpay.configure({simulate: true})`.
4. Development continues as usual.
5. When the developer is ready to submit their app they create a package that does not put the app in simulation mode.
6. The developer presses a “Send to app” button on their simulated payments page and converts [3] their products to “real” products on their app rather than being “simulation” products.
7. Payments now work in production.

[1] This means the developer would need a devhub account to try out in-app payments which isn’t great. Perhaps we could have some default products for testing that don’t require an account under another origin like app://payments-sandbox.allizom.org (maybe the dev can specify `fxpay.configure({environment: ’sandbox'})` to get this mode? That means `fxpay.configure({environment: ’simulate’})` for the other mode).

[2] We might want to limit the origins the dev can use (can’t already be used by an app).

[3] However this works the developer will still want simulation mode to work so they can update their app. Perhaps an app’s author can use the simulation mode on real in-app products.

[Nick Desaulniers]

This makes it more difficult when Mozilla does porting work.
Admittedly, this may be a smaller case, but I'd
just like to point out a particular use case. With porting a large C++
code base via emscripten for a particular
partner (not to be named to public mailing lists until the app is
released), they have been very hands off. They
still have not created a marketplace account, which makes it difficult
to implement links to their app in
marketplace and to get test IAP keys. We've been trying to do as much
work as possible, then have them
submit & maintain from there.

Similarly, in partner engineering, we frequently recommend third party
HTML5 development shops to developers
who lack HTML5 skills or simply don't have the headcount to work on such
a port. The latest such case is Aviary,
which is now being preloaded on FxOS in certain markets. The third
party dev shop did the work, then handed
off the assets to Aviary, who submitted at the end.

Not requiring simulated products to be created from a marketplace
listing allows porting work to continue
without delay of having to wait for the final submitter of the app to
create a marketplace account and submit
and incomplete version of the app.

Either way works for me, just food for thought.

Thanks,
~Nick Desaulniers
Open Source Zealot
Mozilla Corporation

On 7/25/14 8:09 AM, Mark Striemer wrote:
> I like the idea of using simulated payments but I�d rather see the products created in the devhub. Kumar pointed out that it would be nice to stay in the code if you�re already there but I think there are advantages to this too.
>
> 1. The developer goes to a �Simulated in-app products� page in their devhub account [1].
> 2. They enter all of their products as usual but also include their app�s origin [2].

> 3. They put fxpay into simulation mode with `fxpay.configure({simulate: true})`.
> 4. Development continues as usual.
> 5. When the developer is ready to submit their app they create a package that does not put the app in simulation mode.

> 6. The developer presses a �Send to app� button on their simulated payments page and converts [3] their products to �real� products on their app rather than being �simulation� products.

> 7. Payments now work in production.
>

> [1] This means the developer would need a devhub account to try out in-app payments which isn�t great. Perhaps we could have some default products for testing that don�t require an account under another origin like app://payments-sandbox.allizom.org (maybe the dev can specify `fxpay.configure({environment: �sandbox'})` to get this mode? That means `fxpay.configure({environment: �simulate�})` for the other mode).
>
> [2] We might want to limit the origins the dev can use (can�t already be used by an app).
>
> [3] However this works the developer will still want simulation mode to work so they can update their app. Perhaps an app�s author can use the simulation mode on real in-app products.

>
> Mark
>
> On Jul 24, 2014, at 4:20 PM, Kumar McMillan <kmcm...@mozilla.com> wrote:
>
>> On Jul 24, 2014, at 4:05 PM, Harald Kirschner <hkirs...@mozilla.com> wrote:
>>

>>> This looks great. I�d love to see it working within an app. Do we have that or shall I make one to give the whole flow a test ride?
>> If you could make an app using fxpay, that would be fantastic! I was planning to make a call to anyone interested in doing this. What we�d be looking for are devs to try using fxpay with fresh eyes then see what works or what feels awkward then iterate on the API.
>>
>> Until we have the features I proposed (below) you�d have to submit an app to one of our test servers to try it out. I can follow up with instructions on that.

>>
>>> /Harald
>>>
>>> Partner Engineer & Web Craftsman | har...@mozilla.com
>>>
>>> From: Kumar McMillan <kmcm...@mozilla.com>
>>> Reply: Kumar McMillan <kmcm...@mozilla.com>>
>>> Date: July 24, 2014 at 2:03:08 PM
>>> To: Marketplace Development <dev-mar...@lists.mozilla.org>>
>>> Cc: Mark Striemer <mstr...@mozilla.com>>, Jared Kerim <jke...@mozilla.com>>, Harald Kirschner <hkirs...@mozilla.com>>, Nick Desaulniers <ni...@mozilla.com>>, rbl...@mozilla.com <rbl...@mozilla.com>>
>>> Subject: proposal for in-app payment development
>>>
>>>> Hey all, I wanted to get some feedback on a proposal for how developers could work with our fxpay library for easier in-app payments.
>>>>
>>>> The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=981102
>>>> fxpay lib: https://github.com/mozilla/fxpay
>>>>
>>>> Problem to solve: Before a developer submits their app to the Marketplace, they need a way to write code using the fxpay library. This allows them to get everything hooked up and ready for app submission.
>>>>
>>>> Proposal: We add a new parameter to fxpay.getProducts({fake: true}) that lets them work with fake products.
>>>>
>>>> The developer flow would look like this:
>>>>
>>>> - Start building some packaged app locally
>>>> - Include the fxpay library
>>>> - Push the app to a Firefox OS Simulator or device using App Manager

>>>> - Write some code using fxpay.getProducts({fake: true}) *or* fxpay.getProducts({fake: [{name: �My Test�, pricePoint: 10, ...}]}).

>>>> - With fake:true, the library will return 2-3 fake products with hard-coded names, prices, etc.
>>>> - With an explicit array of fake products, those products will be created/fetched internally and returned.
>>>> - Write more code that puts a buy button in their app, calling fxpay.purchase(productId, callback) with the results of fxpay.getProducts().

>>>> - When they tap a buy button, they�ll see a *simulation* screen in our payment provider. This will allow them to simulate a successful purchase or a failure.

>>>> - Write more app code to process the fulfillment of purchases, using their callback in fxpay.purchase().
>>>> - On app startup, fxpay.init() will process test receipts for each purchase; they will validate like regular receipts. This would allow the developer to implement their onrestore() callback using the fake products.
>>>>
>>>> When everything is working how they like, the submission flow is:
>>>>
>>>> - Change their code to call fxpay.getProducts() without the fake argument
>>>> - Submit the app to the Marketplace
>>>> - Set up payments which includes entering bank details
>>>> - Go to the in-app products tab
>>>> - Enter in real product names, descriptions, prices
>>>> - Wait for approval.
>>>>
>>>> As a public app, the call to fxpay.getProducts() without arguments will now retrieve the *newly created* products rather than the fake ones. Purchasing the products would trigger a *real* purchase, not a simulation. This part is already implemented.
>>>>
>>>> Here are some notes:
>>>>

>>>> - we�ll have to create fake products on the fly using a custom API endpoint

[Kumar McMillan]

On Jul 25, 2014, at 10:09 AM, Mark Striemer <mstr...@mozilla.com> wrote:

> Since the products aren’t being created on the fly normally I’d
> suggest where the developer specifies that they are simulating
> be moved to `fxpay.configure`.

Good idea!

> I like the idea of using simulated payments but I’d rather see the products created in the devhub.

I think the requirement to create a DevHub account might add unnecessary fiction. It seems like before you’ve ever submitted an app (or even encountered the Marketplace) you should be able to develop the app somehow.

Maybe we could present both of these approaches to developers and see which one is the easiest to use?

I like the idea of transitioning fake products into real products. Another way to do that is to upload the JSON code you used to configure fake products into the in-app product page. Maybe a text area that you can copy/paste into.

> Kumar pointed out that it would be nice to stay in the code if you’re already there but I think there are advantages to this too.
>
> 1. The developer goes to a “Simulated in-app products” page in their devhub account [1].
> 2. They enter all of their products as usual but also include their app’s origin [2].

> 3. They put fxpay into simulation mode with `fxpay.configure({simulate: true})`.
> 4. Development continues as usual.
> 5. When the developer is ready to submit their app they create a package that does not put the app in simulation mode.

> 6. The developer presses a “Send to app” button on their simulated payments page and converts [3] their products to “real” products on their app rather than being “simulation” products.

> 7. Payments now work in production.
>

> [1] This means the developer would need a devhub account to try out in-app payments which isn’t great. Perhaps we could have some default products for testing that don’t require an account under another origin like app://payments-sandbox.allizom.org (maybe the dev can specify `fxpay.configure({environment: ’sandbox'})` to get this mode? That means `fxpay.configure({environment: ’simulate’})` for the other mode).
>
> [2] We might want to limit the origins the dev can use (can’t already be used by an app).
>
> [3] However this works the developer will still want simulation mode to work so they can update their app. Perhaps an app’s author can use the simulation mode on real in-app products.

This is a good point. Even after the app’s first release, the developer may want to develop new features in simulation mode. Perhaps they will always be allowed to run their app with {simulation: true} even with real products. If so, we may need editors to check for this so that a production app isn’t submitted accidentally in simulation mode. Or we could have an “allow simulation” checkbox that they could flip on while developing new features.

Thanks to everyone for the feedback so far.

-Kumar