Marketplace/PaymentServer

Motivation

Marketplace and AMO has an integrated payments system. This does the interaction with our payments system in the same process as the rest of the Marketplace and stores the data in the same database for several reasons this is undesirable.

This server will act as an independent server that will have it's own code base, servers and so on. Initially this will support Paypal, but if we support multiple sources, it will do that. If we ever move to PCI compliance, hopefully this will be the only piece that will need to be PCI compliant, sheltering the rest of Marketplace.

Update October 2012: Paypal support is still there in solitude, but not in the marketplace. Bango support is now being added. We'll use the word payment provider to refer to the provider, Paypal or Bango.

Update Feb 2013: Solitude is going into production. The code is here: https://github.com/mozilla/solitude, the docs are here: https://solitude.readthedocs.org/en/latest/, the beer is here: http://breweryvivant.com/index.php/the-beer/packaged-beer/solitude/

Overview

The app will be a playdoh Django app. It won't have any admin interface, it will just have an API, possibly using django-tastypie. This will allow us to rapidly move over data and code over from the existing marketplace.

The payment server code is called solitude: https://github.com/mozilla/solitude

Netops

The server should only be accessible from the webheads. The server should be able to make requests out to payment providers and receive responses.

IPNs

Paypal (only) sends a response to every transaction called an IPN. We need to handle the IPN and process that in both the marketplace and the payment server. For example on a refund, we need to process that in the payment server and if its all correct, process the refund and make sure that the receipt is invalidated (for example).

Marketplace

Marketplace will talk to the Payment Server using a REST HTTPS interface. Requests will be signed using JWT to validate it came from a trusted source. A common secret for signing will be put on the webheads/payment server.

Logging

We'll log to the CEF log and to syslog in a similar fashion to the marketplace, however they'll be separate logs. All logging should obfuscate or truncate sensitive values so that we don't leak any confidential data into our logs.

We will need to log specific IDs for support questions. For Paypal, that is the correlation ID.

statsd, nagios etc

Yeah let's do that so we can see how the server is running.

APIs

I'll spec out the first example and we'll fill out the rest as we go along. There will probably be more API's than this.

Paypal example: get Paykey

Gets the paykey from paypal:

 POST /paypal/pay

JSON body will contain:

 {'user_id': 123, 'app_id': '456', 'amount': 1.00, 'currency': 'USD', 'use_preapproval': true}

This will do lookups of the user and the app. If the user doesn't exist, it will create all the data. For an app to be sold, the paypal_id of the app must be registered with the server already

If use_preapproval is true, we'll try to use the preapproval token for that user if present.

Example with pre-approval that worked:

  {'user_id': 123, 'app_id': 456, 'amount': 1.00, 'currency': 'USD', 'use_preapproval': true,
   'status': 'completed'}

Example without pre-approval that worked, generating a paykey:

  {'user_id': 123, 'app_id': 456, 'amount': 1.00, 'currency': 'USD', 'use_preapproval': false,
   'status': 'created', 'paykey': 'xxxx'}

We are passing back the one time use paykey so that the front end can fire off the Paypal process so the user can approve the process.

The fact that we are using paypal is implied by the URL namespace.

Paypal example: Preapproval

This will be where a user creates or removes pre-approval from their account. There is a multi stage step to this process.

• Marketplace calls the Payment server to get the pre-approval URL. The Payment server will store the temporary pre-approval key created by the Payment server.

• Marketplace bounces the user to Paypal and waits for the reply.

• When the reply is positive the Marketplace pings the payment server and the pre-approval key is moved to the permanent storage.

Paypal example: Check purchase

This will check that a purchase has gone through. The pre-approval will do this automatically but there are stages in the marketplace where we need to do this manually.

Paypal example: Refund

Refunds the payment.

Paypal example: Gets personal data

This has multiple steps. First we get the Paypal URL to bounce the user too and return that to the marketplace. Once the permissions are in place we'll call the Paypal API's and store them in the Payment server.

Paypal example: Check Paypal id

Used to check that a Paypal id is valid.

Paypal example: App paypal data

Stores or gets the paypal data for an app. This will likely just be the paypal id. This will allow the devhub pages to get and set this value. It will probably be acceptable for the marketplace to cache this temporarily in memcache for the developer pages, but should never be persisted for longer than is needed.

Paypal example: Check app

For an app, run the checks that check the app is valid to be sold on the marketplace.

Data

Data will be divided in the following ways.

For a list of Bango data see: https://wiki.mozilla.org/Marketplace/BangoData

Marketplace

The marketplace will know:

• what an app costs or what recommended donations
• what app a user has installed
• what app a user has purchased and how much it cost
• what refunds have been processed for which user and app
• what inapp payments have been made for user and app
• the notifications that the marketplace has made with an app supporting in-app payments

The marketplace will not know how to communicate with the payment provider at all. It will know how to communicate with the payment server, so each web head will have the appropriate keys, stored on the file system, to access the payment server.

Payment Server

The payment server will know:

• the specific payment provider data of sellers
• any personal payment provider specific data of sellers or buyers
• the permissions tokens of sellers (for paypal)
• the pre-approval keys of buyers (for paypal)
• the detailed payment provider transaction log of each purchase or each inapp purchase
• a buyer provided PIN required for purchasing apps

The payment server will know how to communicate with the payment provider. It won't send any messages to the marketplace at all, it will be marketplaces responsibility to query the server and find out what's going on.

Retention

We need to see how long we can retain data for.