When setting up a product for payment via Boku, we need a chooser to let the developer choose Boku. Something like this: https://docs.google.com/a/mozilla.com/presentation/d/1u9NDrvsllb5wTN0IWXCrqqoUqBKu6zLQpIDWoj6vFSY/edit#slide=id.g1d85b3ba3_0147

I'm not sure we ever need to edit a Boku account. The only fields that can be changed are merchant id and seller id. If any transactions have gone through on those it we'll have a scenario where transactions have occurred on a changed account. I don't have more than a gut feeling on this one, but I think a delete than re-create would be all thats needed, not a modify.

I made a prototype of a new design of "Payment Accounts" on dev hub so that users can add Bango and Boku accounts: http://2hu4ka.axshare.com/#p=home&c=1 • Show Bango and Boku as payment options and list the countries covered by those payment processors. For Mexico since they are covered by both show the carrier name in parentheses • For Bango, "Add Payment Account" button will open up overlay to enter account information for Bango. • Clicking "x" on the Bango overlay in the prototype will take you back to the Payment Accounts screen with new Bango account added. • For Boku, "Add Payment Account" opens overlay to enter Merchant ID and Service ID. • Clicking "Register Payment Account" in the Boku overlay will take you back to the Payment Accounts screen with new Boku account added. • Clicking "sign up on Boku's website" in the Boku overlay will open up a new tab with the Boku portal. • When the user comes back to the dev hub after being on the Boku site the Boku overlay should still be open.

I've done some work on this in bug 989946 and this is what I've got so far. Hopefully it is a good first step that we can finish off later. Similar to your design the account selection form breaks apart the two forms. https://www.dropbox.com/s/kfbb5ew0rcro6f0/Screenshot%202014-04-07%2012.05.36.png To keep the changes to the codebase down the management of accounts stays together in the popup with the link moving the the footer. https://www.dropbox.com/s/l8aoq2hn2f92v4q/Screenshot%202014-04-07%2012.05.48.png With more than 2 providers this wouldn't be reasonable but it seems like a good first step. Anything you think I should change now?

This looks ok for now. If we have extra time would love to implement the other design so we can avoid a proliferation of pop-ups. Question: "View Transactions" link is missing in the account management pop-up (https://www.dropbox.com/s/l8aoq2hn2f92v4q/Screenshot%202014-04-07%2012.05.48.png) Requests: • Capitalize "Bango" and "Boku" on the "Add a new Bango payment account" so it is easier to differentiate which provider you are signing up for (https://www.dropbox.com/s/l8aoq2hn2f92v4q/Screenshot%202014-04-07%2012.05.48.png) • Add more space between "Add, manage, view..." link and "Save changes" button (https://www.dropbox.com/s/kfbb5ew0rcro6f0/Screenshot%202014-04-07%2012.05.36.png) • Always list Bango first on the account selection list.

Created bug 996084, bug 996085 and bug 996090 to provide the remaining enhancements.

Mocked up the register Boku payment modal to include screenshot so people know where to find their Service id.

Like that, really helps. Should the red circle be around just the bit in brackets, to make it clear we only need that string, not the Test App [ ] bit?

Yes, it would be better if the red circle was just around the brackets. I was just lazy and took a screenshot of what you already had ;)

Andy McKay, David Bialer, Richard Bloor from MDN and I met last Thursday to discuss the complicated flow developers will have to go through to sign up for a Boku account. We decided that we need to direct developers to MDN to view documentation on Boku BEFORE they try to sign up for an account. I have revised the design on the "Add Boku Account" modal to address this. • Call-to-action is "Go to MDN" rather than register payment account. • Let user know that signing up for an account will take 24-48 hours. • Directions to enter service id appears after messaging about signing up for a Boku account. • Link to MDN (rather than screenshot) to help user find the service id on Boku portal. Flow for entering service id: 1. User enters service id and clicks "Submit" 2A. If the service id matches show green text "Approved" underneath the text entry box. 2B. If the service id is not found show red text "Service ID not found." underneath the text entry box. 3. User clicks "Close" at bottom of modal. 4. If service id was approved, show Boku in list of payment accounts.

I updated the dialog but didn't make it quite the same. Accounts have a name which is missing from the mockup and that makes including the button inline a bit weird. Since the service ID validation happens server side 2A and 3 don't happen in the happy path, submitting a valid form will close the dialog and jump to step 4. Any suggestions, Maureen?

• So we need to add back in the account name? I thought we only needed the service id. • What will happen if a user submits the form and the account name or service id doesn't match? Will the form need to close to show the error message? My tentative thought for changing the flow would be: 1. User enters account name and service id and clicks "Register Payment" 2. Modal closes dialog and a "Registering Payment Account" progress overlay appears in its place. 3A. If the account name and service id match close progress overlay, return to devhub page section with Payment Accounts section visible with "Boku" now listed as an account. 3B. If the account name and service id don't match close progress overlay, return to "Add Boku Account" overlay and show error message "Could not find account name" "Could not find service id", "Could not find account name or service id"

Account name is the name of the account and is only stored in zamboni, no where else. It isn't sent to Boku. This matches the Account Name field for the Bango forms (which likewise aren't sent to Bango).

I assume there is a way to validate account name / service id?

The account name is just for the user to differentiate between their accounts in the devhub so there's no need to validate it. Should we prefix the fields with where they're from/used?

Here is some helper text for the modal. Helper text for account name and service id should appear below the text fields following the pattern we use on the Bango modal. "MDN Boku page" should be a link to the Boku MDN page, specifically to the section where it shows a screenshot of where the service id appears on the Boku portal. "Have you signed up for a Boku account and had your account approved? Please create an account name and your Boku service id below." Account name: [ ] Create a name for this account Boku service id: [ ] Alpha-numeric id listed under Service Name on Boku website. Learn more on the MDN Boku page.

New screenshot with the inline help text.

Ok, looks great. I just have some really annoying nitpicks... • Is it possible to slightly increase the line spacing for the text? It looks pretty tight. • Can we add a few pixels in between the text field and the helper text below?

Bump up line-height and add padding to help text.