CloudServices/Payments/FirefoxAccounts

This page is about attaching payments to the Firefox Accounts as a re-usable service with all Mozilla properties.

This is a rough outline of ideas, not a final plan. Please edit and update.

Overall plan

If we are going to start accepting Payments for Mozilla from diverse sources across Mozilla then we need to be in position to support those projects. Each project could do their own, but by grouping the support together, we'll get a few important wins.

• Security and legal concerns focused in one team and code base.

• No need to make multiple agreements with payment providers and gain financial benefits.

• Provide a great end to end service for our users.

• Provide a great set of services for Mozilla projects.

• Limit the amount of code Mozilla has to keep writing for each project to a minimum.

Compared to Marketplace Payments

This is quite different from Marketplace payments in a few key areas, namely:

• A Marketplace payment is from an end user to a developer, specifically not someone at Mozilla. This has very significant financial, legal and accounting requirements.

• The Marketplace integration with payment processors tends to require a lot of customization because Mozilla's technology enables a payment transaction between two external parties.

• In a Marketplace payment Mozilla gets a (really rather small) cut of the transaction at the end, which is sent from the payment provider.

• The Marketplace is designing a system for app and in-app payments that will need to be used and configured by many thousands of developers. The security of these apps is somewhat out of our control so our own threat model must account for malicious or compromised apps.

• The Marketplace payment service competes with every other web based payment system available.

• Marketplace payments are designed primarily for carrier billing on mobile.

• Just like the Marketplace service, Mozilla does not intend to ever directly process a payment (e.g. charge a credit card). That will be handed off to a payment provider like Stripe or Bango.

Requirements

We've chatted to a few teams who would like payments over the Portland work week. They have a few key requirements. The highest priority requirements are:

• Desktop
• Credit card
• North America and Europe
• Recurring billing
• One off payments
• One off payments without any login

Lower value requirements are:

• Android and Firefox OS
• Rest of the world

Didn't really care about:

• Carrier billing

Flows

A rough outline of some of the flows, maybe.

UX

Some initial mocks of the flow:

Purchase

• Click buy link
• Iframe opens to payment server
  • Check to see if login is required (e.g. for subscription purchases)
  • If yes: show Firefox Accounts login iframe, on login return.
  • Pay using existing card (if it exists) otherwise create credit card
  • Pass transaction off to the processor, record success on Mozilla Payment servers.rmation in
• Return to app
• App uses OAuth Firefox Accounts flow to ask for data about the transaction
• If its a recurring payment, then this OAuth Firefox Accounts request can be repeated

Payment History

• List all the payments that have occurred, amount etc.
• Generate a web based receipt for each payment (not a WebApplicationReceipt)
• Email receipt to the firefox account owner for each payment (not a WebApplicationReceipt)

Subscription Administration

• Add in credit cards
  • Note we won't store the card, it goes straight to the payment provider, but there is an API to retrieve a bit of information about the card. For example Stripe returns you the card type and the last four digits so you can show something nice to the use.
• Change credit cards
• Alter credit card assigned to subscription
• Cancel subscription (notification policies and the like will need to be figured out there)

Notifications

To the end user (via email or simple push):

• Payment charged
• Card added, card removed, card updated

To the end user (via email or simple push) and the implementing app (via Firefox Account notifications):

• Subscription started, subscription cancelled, subscription failed

Firefox Account

It should be possible to:

• Get from the Firefox Accounts page to the Payment Management page (better name needed)
• Ping Firefox Accounts asking for information about a subscription or purchase with an API (using scope)

Integration

Add in config for:

• Product to be sold (name, price, description, type, subscription recurrence)
• Subscription failure policy
• Emails to be generated, so they can be overridden if they need to be

Logical flow

An overview of flow from a security view. Very rough draft.

Components

• Payment provider: e.g.: Stripe or Bango or one of countless others.
• Firefox Accounts: Authentication mechanism, might need to have an API to ping the payments API for looking up users details.
• Payments UI: Communicates with the payment API to fill out all the pretty HTML screens.
• Payments API: Communicates with the backend. Brokers between: the payment front end, the payment provider and firefox accounts. Could be webpay (http://webpay.readthedocs.org/en/latest/).
• Payments storage backend: Somewhere to store tokens and configuration, payment history and the like. Makes only outbound connections to the payment provider. Could be solitude (http://solitude.readthedocs.org/en/latest/).
• Implementing App: The app (like MDN) that wants to implement this whole thing.

Miscellany

Do we need to use mozPay?

Nope. mozPay only exists on Firefox OS and Android. Further, mozPay puts users straight into the Marketplace flow because that's in the inclusion list.

Can this improve Marketplace Payments?

Theoretically yes. For example there's no reason we can't show all the payments a user has done in the account listing be they Marketplace or something else. But in the first milestones its probably best not to let that distract us too much.