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.

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.

Netops

The server should only be accessible from the webheads. The server should be able to make requests out to Paypal, but not receive responses.

IPNs

Paypal 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 two legged OAuth similar to the external API. A token and secret is generated on the payment server and then is propagated out to the webheads.

Logging

We'll log to the CEF log and to syslog in a similar fashion to the marketplace, however they'll be seperate 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 the correlation ID. This is the key that Paypal needs to know in case of support questions.

statsd, nagios etc

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

Paypal and more

We'll be having integration with more than Paypal real soon now. We don't need this yet, but its worth noting that all the paypal API's will be just one way of doing payments.

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.

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.

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.

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.

Refund

Refunds the payment.

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.

Check Paypal id

Used to check that a Paypal id is valid.

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.

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.

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 Paypal 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 paypal_ids of sellers
• any personal PayPal specific data of sellers or buyers
• the permissions tokens of sellers
• the pre-approval keys of buyers
• the detailed PayPal transaction log of each purchase or each inapp purchase

The payment server will know how to communicate with Paypal. 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.

Migration

1. Stand up the service as a stand alone service.
2. TODO: figure out the remaining steps.