Closed Bug 910270 Opened 11 years ago Closed 10 years ago

Create in-app payment server / service for developers

Categories

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

Avenir
x86
macOS
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 944480

People

(Reporter: kumar, Unassigned)

References

Details

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/
Assignee: nobody → kumar.mcmillan
Blocks: 908738
Priority: -- → P3
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.
Assignee: kumar.mcmillan → nobody
I think long term the way to go is the option of server less in-app payments via receipts. This requires bug 757226 though.
Depends on: 757226
(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!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.