Developers are currently required to host their own server to process payments. This introduces several road blocks: - it costs money to run a server - they must write custom backend code - they must create a catalog of products and figure out how to do reconciliation, inventory, etc This is a non-trivial effort for developers who simply want to create an app such as a game and begin to sell in-app products. Let's provide them a web service that they can use. Here is a proof of concept: https://github.com/kumar303/mozpay-catalog/

Kumar - we'll need some Ops support to get this done, correct? is the intention to run this like another "catalog" that the marketplace infrastructure handles? thinking we'll need - server ops - net ops (estimate / approve load?) - security review am i off base?

This would be running a service for developers on our infrastructure. Perhaps it could be included as marketplace services. But if this is the approach, we should look at this like other developer services like app crash reporting, app statistics and so on. I think there's some other stuff we should do before we approach ops.

(In reply to Caitlin Galimidi from comment #2) > thinking we'll need > - server ops > - net ops (estimate / approve load?) > - security review That sounds conceptually correct to me. We might choose to bake it into our existing developer API (http://firefox-marketplace-api.readthedocs.org/) which means ops would not have to provision anything new. We will definitely need a security review.

priority of this is unclear so I'm unassigning myself for now.

I think long term the way to go is the option of server less in-app payments via receipts. This requires bug 757226 though.

(In reply to Andy McKay [:andym] from comment #6) > I think long term the way to go is the option of server less in-app payments > via receipts. This requires bug 757226 though. Andy, I can see where you're going -- in that case, we need another bug that says something about rewriting in-app payment flows to use receipts, yes?

Hi Bill. Maybe we should have a discussion about it? I don't know if introducing receipts is mandatory for providing server-less payments. There are a couple ways to do it.

I think after chatting with Kumar today, in-app payments are going to get a bit of an overhaul one of them being possibly using receipts for tracking the in-app payment. We are going to stick up a wiki page about it. If you want to have a meeting about it, happy to do that too.

(In reply to Andy McKay [:andym] from comment #9) > I think after chatting with Kumar today, in-app payments are going to get a > bit of an overhaul one of them being possibly using receipts for tracking > the in-app payment. We are going to stick up a wiki page about it. If you > want to have a meeting about it, happy to do that too. I'll let you use what process makes sense to you; be sure to shout if you think the requirements around replaceReceipt() are going to change.

We are doing it!