Marketplace/BokuPayments
.png){kind=small}
Boku was never fully implemented on the Marketplace and never went live. This page exists for historical information.
Boku: http://boku.com/
Contents
UX
- Proposed flow (only accessible to Mozilla Corporation employees)
Bugs
- See the tracking bug: 987661
Docs
On Mana, please note that Boku do not want those docs to be in a public wiki.
The Boku portal is here, there are some sample accounts.
Marketplace changes
This is a list of the changes that we'd need to make to the Marketplace. This is a non-exhaustive brain dump that was quite exhausting to do, but serves as a jumping off point for bugs, still to be filed.
Some of these points are broken into two parts. The minimum we need to do and what we'd like to do.
Developer sign up
In solitude:
- Add in an API to check the status of user given a Boku account number.
- Store the Boku merchant number in solitude, related to the developer account.
- Add in APIs to lookup Boku account details for a developer from zamboni and webpay.
In the developer hub:
- Change the Django models to allow assignment of multiple payment accounts to an app bug 969041
- Alter settings to allow multiple payment providers.
- When creating a payment account, allow developers to choose between providers.
- Alter the API to speak to solitude APIs when creating accounts.
- Alter the price tier screen to show carrier or payment provider.
In Boku:
- Add in templated provisioning of a Mozilla developers account so that developers does not need to configure callbacks, service points or price tiers.
- Ensure correct terms and conditions for developers.
- Ensure correct and easy setup of appropriate Boku information.
Extra points
- Implement full developer payment choice in the hub, as specced in podio and mocked out by Bram, tracking bug 963203
Payment choice
In solitude:
- Add in (or ensure there is an API) for checking what payment providers are available for an app.
In webpay:
- Add in an intersitial page at the beginning of the flow that: bug 987824
- doesn't automatically start the payment flow
- grabs the JWT in the request, adds in the MNC and MCC from JS
- passes that webpay
- If we can't figure it out, fall back to Bango.
- Look up request in solitude to see what choices are available.
- Calls the appropriate payment provider.
Extra points
- Get single page app done (spartacus) as specced in podio and partially mocked by Bram, tracked by bug 837289.
- When we start a payment with Bango, ensure we pass through just "carrier billing" or "credit card" or both and ensure Bango use that, bug 882321.
- If we can't figure out what to do with the payment, show a payment choice page.
Payment
In solitude:
- Add in Boku layer through the solitude proxy, that adds in:
| merchant-id | is this one for all mozilla calls? |
| password | one for all mozilla calls? |
- Add in API to call Boku to start a payment, passing through app, consumer id and price.
- Call https://api2.boku.com/billing/request, fields:
| service-id | is this the developer id? |
| currency | - |
| price-inc-salestax | - |
| consumer-id | hashed persona id/firefox accounts id |
| callback-url | is the front end or back end one? |
Note: I think server side calls are set in the merchant account setup.
- Add in APIs to token check to ensure Boku responses are valid.
| merchant-id | is this one for all mozilla calls? |
| password | one for all mozilla calls? |
| trx-id | this is pay-uuid (to check this is populated correctly) |
- Add in the end point for Boku server to server responses and update solitude and zamboni transaction records appropriately.
- Merchant callback URL, see page 40 of PDF
In webpay:
- Cope with the redirects from Boku and ensure they are handled correctly. There might be little to do here.
At Boku:
- Implement the carrier billing payment screens from Zippy, do the authentication and all the hard work.
Fulfillment
There should be no change here.
Refunds
We are assuming that as a carrier payment option there will be no refunds.
- On the lookup page show which payment provider was used.
- If it was Boku, don't show a refund option.
Receipts
There should be no change here.
Stats
Boku have a page that will return stats in CSV format from and SFTP server. However I haven't found where that is, or seen the docs on that, so we'll have to follow up on that.
- Provide a link in the devhub to access the portal.
Extra sauce
- Slurp the stats from solitude and add into monolith. Provide a front end in the devhub that displays them back. This work hasn't been scoped and is subject to some privacy concerns.
