794695 - Allow developer to set up payments for Bango

Status: RESOLVED FIXED

(Marketplace Graveyard :: Developer Pages, defect, P1)

Description

[Kumar McMillan [:kumar]]

The payment processor we're using for Basecamp will disperse money to developers via PayPal. In order to activate them for billing all we have to do is collect their PayPal ID.

Comment 1

[Kumar McMillan [:kumar]]

Be careful with flipping existing flags here. We have a flag that disables PayPal and that hides PayPal from the frontend. We need to continue hiding PayPal like that because we are not using PayPal on the frontend for payments

Comment 2

[Christopher Van Wiemeersch [:cvan]]

lol

Comment 3

[Wil Clouser [:clouserw]]

from cvan:

> 	we should add back the Payments step to submission
> - payment type (free w/ in-app, paid up front, paid w/ in-app, my own payment system)
> - price tier (and list the tier for each region as listed in mkt/constants/regions.py)
> - ask for PayPal ID for bango
> ask bram if you have questions about UX
> after this you'll probably want to look at Bango implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=795103

Comment 4

[Andy McKay]

> 	we should add back the Payments step to submission

I disagree with that.

Assigning to bram for mocks.

Comment 5

[Kumar McMillan [:kumar]]

+1, let's let the UX mocks drive this

Comment 6

[Bram Pitoyo [:bram]]

Writing down my thoughts for things I am going to do tomorrow:

First, revamp the done page of the app submission flow so that it reflects the choice use had made. If user selected “paid”, then we say “now you can set up your payment”. If user selected “free”, then we say “sit back and relax!”

The edit page sidebar should have the menu item that reads as follows:
- Listing (under this, there will be a preview button to view listing)
- Devices and payments
- Authors (can we integrate this option into another page?)
- Disable and delete (a better name for this?)

The devices and payment page should have a free and paid tab, just like the app submission flow. We should add the option to select price tier, payment processor and in-app payment down below the device selection. Design is incoming.

Comment 7

[Bram Pitoyo [:bram]]

Attachment: app submission flow: done

The “Done” step is redesigned so that it’s more informative and encourage developers to set their payment and author informations early on, rather than waiting for the review process to finish first.

The design of the page might change further to incorporate more clickable buttons and readable list items. The items listed here are just starting list, formatted in a basic way.

Comment 8

[Bram Pitoyo [:bram]]

Attachment: edit app: devices and payment

This is the “Devices and Payment” section of the Edit App interface.

Notable things:

* The page hierarchy is made consistent. The section is called “Edit App”, and the subsection, which is highlighted in the sidebar, is called “Devices and Payment”

* Sidebar items have also been labeled more consistently, so it’s easier when read side by side

* Device compatibility is listed by default, along with the “Free” and “Paid” tab, to reflect user’s selection on the app submission flow

* User will be able to switch device compatibility and Free/Paid status around, but doing that will put the app back into the review process – so there’s a warning note about it

* Price tier selection has been dramatically simplified. Rather than the Free / Premium / Free with in-app / Premium with in-app / My own payment provider radio buttons, we have one big drop-down menu that handles all prices

* In-app payment can be enabled and disabled by clicking a checkbox – the mental model of an in-app payment here is a sort of “add-on” that you put on top and take out of an app

* Payment account is selected the same way as you would if you’d select device compatibility
** Click the PayPal box
** The box is highlighted yellow, the other box is grayed out
** Enter an email address
** Click the authorize button


How to set a free app with in-app payment:
* Click the Tier drop-down menu
* Select the option labeled “Free” (calling it “Tier 0” is jargony)
* The price is free, but the paid option is selected above. Obviously, the app will still have payment of some form
* So, the system will automatically check the “In-app payment” checkbox when user selects the “Free” label on the tier drop-down menu

Comment 9

[Andy McKay]

Thanks bram, a few questions:

- in app is next to price tier, which might imply that the two are related. That's not the case. In app payments will have to conform to carrier payment price tiers, but we don't really care what price tiers they use. The only reason we wanted to track an app using in app payments was so we can keep track of who is using in app payments and maybe show that to users.

- payment account is the information we'll send to Bango, I'm not sure yet how we do that, if it's an API or an iframe. What if a paypal account already exists?

- my own payment provider would be removed, not sure if that's relevant.

It feels like there's a lot of stuff going on this page, will probably have more feedback when I've had time for it percolate in my brain.

Comment 10

[Kumar McMillan [:kumar]]

Hi Bram. I like the simplification and new layout. Here are some minor points:

- For in-app payments I don't think we need to collect the provider name if they decide to use their own provider. It's more like: dev_is_using_custom_provider: yes/no

- As of a call with Bango today some details around paypal might change. It's possible that we will collect bank account info (or redirect to a Bango hosted page where that is collected. Ugh). Just a heads up, no decision yet. Assume paypal for now.

Comment 11

[Wil Clouser [:clouserw]]

(In reply to Andy McKay [:andym] from comment #9)
> - in app is next to price tier, which might imply that the two are related.
> That's not the case. In app payments will have to conform to carrier payment
> price tiers, but we don't really care what price tiers they use. The only
> reason we wanted to track an app using in app payments was so we can keep
> track of who is using in app payments and maybe show that to users.

That was also my first thought

Comment 12

[Jason Smith [:jsmith]]

Not on-device - removing nom.

Comment 13

[Bram Pitoyo [:bram]]

> - in app is next to price tier, which might imply that the two are related.
> That's not the case. In app payments will have to conform to carrier payment
> price tiers, but we don't really care what price tiers they use. The only
> reason we wanted to track an app using in app payments was so we can keep
> track of who is using in app payments and maybe show that to users.

I had thought previously that in-app payment and price tier are related. They feel intuitively related, like one is supposed to think of them in order: first you decide whether your app is free or paid, then you decide if you want in-app or not. But maybe they are not related in the backend?


> - For in-app payments I don't think we need to collect the provider name if
> they decide to use their own provider. It's more like:
> dev_is_using_custom_provider: yes/no
> 
> - As of a call with Bango today some details around paypal might change.
> It's possible that we will collect bank account info (or redirect to a Bango
> hosted page where that is collected. Ugh). Just a heads up, no decision yet.
> Assume paypal for now.


Do we have a list of fields that Bango and PayPal would require, so I can prototype an interface that will suit it?

I assumed that user would be able to connect with PayPal by simply entering his email address. The process looks a little something like this:
* User enters his PayPal email address
* A PayPal-hosted popup window will appear and authenticate that user with PayPal
* User enters his PayPal password
* User clicks a button that would authorize PayPal to receive money from Bango
* The popup window closes
* The manage payment page refreshes, the email field is filled in and blocked, indicating that the account is hooked up

Comment 14

[Wil Clouser [:clouserw]]

(In reply to Bram Pitoyo [:bram] from comment #13)
> > - in app is next to price tier, which might imply that the two are related.
> > That's not the case. In app payments will have to conform to carrier payment
> > price tiers, but we don't really care what price tiers they use. The only
> > reason we wanted to track an app using in app payments was so we can keep
> > track of who is using in app payments and maybe show that to users.
> 
> I had thought previously that in-app payment and price tier are related.
> They feel intuitively related, like one is supposed to think of them in
> order: first you decide whether your app is free or paid, then you decide if
> you want in-app or not. But maybe they are not related in the backend?

price tiers are for buying your app.  So:  first you decide if it's free or paid, if it's paid, what price tier do you sell it at?  In-app payments are different

Comment 15

[Bram Pitoyo [:bram]]

Attachment: edit app: devices and payment - design variations

Design variations on the devices and payment step.

When evaluating the layouts, consider:
* Do we want to link to articles about price tiers, in-app payments, etc.?
* Do we want to inform users that support for other payment providers is coming?
* Will big text size aid comprehension or just clutter up space?
* Can we expect that user is going to know what he wants to do at this point, so we don’t have to be very verbose and hand-holding?

Comment 16

[Andy McKay]

I'm not a fan of lots of different font sizes myself. Other opinions may vary.

It might worth noting that other actions may cause the app to go back into the rereview queue, for example altering from free to paid, or vice versa.

Perhaps the form should see if the changes would trigger a rereview and show a confirmation dialog at that point?

Comment 17

[Christopher Van Wiemeersch [:cvan]]

The varying font sizes are disorienting for me too. But this looks good.

And are we removing upsell?

Comment 18

[Maria Sandberg [:mushi]]

Bram, thanks for showing off the iterations. I'll email you some thoughts and leave it to you to make the final decision.

Comment 19

[Bram Pitoyo [:bram]]

Attachment: edit app: devices and payment

I choose to go with this option, where:
* Text sizes don’t vary a lot
* They have hierarchy, so you know the order of information to look for
* Emphasis is marked bold
* Captions and help links are set smaller than the rest of the text


(In reply to Andy McKay [:andym] from comment #16)
> Perhaps the form should see if the changes would trigger a rereview and show
> a confirmation dialog at that point?

There’s a red button up there that will alter device compatibility and payment type. It will mirror the tab we use in the submission flow (where we have “free” and “paid” with a list of devices underneath).

Clicking on this red button will allow developer to change his paid app back into free. Free here means “totally free”, because “free with in-app payment” is still considered “paid”. There’s a caption to the left of that red button that says that the app will go back into the review queue if developer clicks it. So I feel like this covers that situation.

However, you may be thinking of the case where developers alter the price for promotion. For example, an app will start out free for the first one week, and then the price will move up to $0.99. In this case, would the app need to go to a re-review? Or, because the app status is already marked as “paid”, it doesn’t need to be reviewed again?


(In reply to Chris Van Wiemeersch [:cvan] from comment #17)
> And are we removing upsell?

Could you clarify what you mean by upsell? I might’ve missed it on the old interface.

Comment 20

[Maria Sandberg [:mushi]]

FYI, we just had a meeting with the payment provider about what the sign up process will be like. We will likely need to extend this UI, I'll let you know when we have more info.

Comment 21

[Kumar McMillan [:kumar]]

(In reply to Bram Pitoyo [:bram] from comment #13)
> Do we have a list of fields that Bango and PayPal would require, so I can
> prototype an interface that will suit it?

So far, this is what Bango needs us to collect in addition to PayPal email:

- administrative email
- support email (we already have this)
- financial email -- where finance related communication goes
- vendor name
- company name
- address: line 1, line 2, city, state, post code, country
- phone
- fax (optional)
- VAT number (optional)
- preferred payout currency. Options: USD, EUR, GBP

I just got wind of this as I checked out the API calls. Some of these we probably already collect. If we think we don't need some of these we could ask Bango about them.

Also note that we may require bank account details instead of (or in addition to) paypal. There is still a lot of details to work out about that. We should assume PayPal for now, at least to get started.

Comment 22

[Christopher Van Wiemeersch [:cvan]]

Per bug 807871 - which I'm making now part of this bug - please remove the "Device Types" checkboxes from "Edit Listing" since they're already covered on this "Devices and Payments" page.

Comment 23

[Bram Pitoyo [:bram]]

(In reply to Kumar McMillan [:kumar] from comment #21)
> So far, this is what Bango needs us to collect in addition to PayPal email:

There are a lot of fields here. Maybe we should adapt the design of the Edit Details step to use in this page?

I also wonder if Bango will be able to get some of the information from PayPal? For example, I know that PayPal does address verification, and note user’s phone number. That way, user will only need to fill in currency, VAT number, fax, vendor and company names, and the various email addresses.

The other thing that will be nice to have here is an example of how other vendors have implemented Bango’s payment system. For example, both Google Play Store and Facebook are powered by Bango. Can we see an example or screenshots of what the developer payment setup flow looks like in these environments?

Comment 24

[Kumar McMillan [:kumar]]

I think for now, we'll have to collect all the fields I listed above. Otherwise, we'll have to wait for custom dev from Bango to adjust their API

Comment 25

[Bram Pitoyo [:bram]]

Thanks for confirming, Kumar. This is what I need to start designing.

Comment 26

[Bram Pitoyo [:bram]]

Attachment: payment form UX

Attached is a low fidelity mockup of how the payment forms are structured and should behave.

Notable things:

* Form elements are revealed progressively, not all at once, in this order:
1. Price tier menu and in-app payment checkbox
2. PayPal email
3. Currency
4. The rest of the forms

PS. Different countries/state and VAT are auto selected depending on the currency

* After PayPal email authentication, the “Authenticate” button is replaced with an “Edit” button, with a warning text besides it

* After form completion and submission, the “Submit” button is replaced with an “Edit” button, with a warning text besides it

* When editing, a “Cancel” button appears to the right of the “Edit” button so user can call off the change that he is making

Comment 27

[Kumar McMillan [:kumar]]

Hey Bram, this looks great! Thanks. I was initially confused by vendor vs. company so I asked for clarification from Bango. This is what they said:

The company name – is the registered legal entity of the business
Vendor name – is the trading name for the business.
 
So for Bango it would be:
 
Company name = Bango.Net Ltd
Vendor name = Bango

Comment 28

[Kumar McMillan [:kumar]]

Bram, we can actually skip the PayPal email authorization step. It can simply be a text box with an email. What will happen is we will submit the data on the backend using the Bango API and their API server will verify the PayPal email. If it's incorrect we'll receive an API error just like any other error such as an invalid VAT code.

Comment 29

[Andy McKay]

Do these payment flows rely on people setting up payments again for every app? If I've already set it up once for an app, do I have to do it again every time for each app?

Although its for Paypal, I think the arguments here stand bug 694699.

Having to do it every time for every app sucks.

In some earlier mocks we had the ability to chose an existing payments profile I've made. I'm unsure if this choice will exist with Bango, but if it does, I think we should use it as it would make life much, much easier. The QA team and the developers of the API would love you too.

Comment 30

[Bram Pitoyo [:bram]]

(In reply to Andy McKay [:andym] from comment #29)
> In some earlier mocks we had the ability to chose an existing payments
> profile I've made. I'm unsure if this choice will exist with Bango, but if
> it does, I think we should use it as it would make life much, much easier.
> The QA team and the developers of the API would love you too.

Can we confirm whether the ability to set up payment information once and use it multiple times rests with Bango, or with us?

I was not aware that user can choose payment profiles in earlier mocks. They must’ve been implemented before I came into the project?

Payment profile is a great feature to implement! But I wish that I would’ve seen the earlier mockups, so I could start from that rather than mocking something up from scratch. Is there a a page on the dev server that you could point me to?

Structure-wise, I think that payment profile should not be placed inside the app management page, but maybe inside profile (keep in mind that user profile ≠ developer profile, so this could create confusion, and we must tread carefully).

Comment 31

[Bram Pitoyo [:bram]]

Attachment: payment form UX - 02

The payment form UX has been updated with:
* More consistent button placement: always on the left side of the form
* Caption on the side of every button that will trigger app re-review
* Button that will trigger app re-review is marked with a different color

This update does not cover:
* Payment profile setup page/flow
* The fact that we don’t need a separate “Authenticate” button for PayPal email

Is there a Bango-powered flow in another website that I can look at as an example? My flow seems tedious to go through. Having reusable payment profile will help, but I think that the real solution is reducing the number of form text boxes. If there’s another site with a form implementation that we can learn from, it’ll help me.

Comment 32

[Bram Pitoyo [:bram]]

Attachment: payment form UX - 03 - separate editing

Based on Andy’s comment 29 and my discussion with Cvan yesterday, the payment form UX has been updated with these features:

* Interface for adding and managing payment accounts
* Editing price tier is separated from editing payment accounts. Meaning, both has its own “Submit” button

This mockup is 1 out of 2 design variations.

Comment 33

[Bram Pitoyo [:bram]]

Attachment: payment form UX - 03 - integrated editing

This mockup is number 2 out of 2 design variations, where everything is the same as the last design variation (attachment 684309 [details]), except for this feature:

Editing price tier is NOT separated from editing payment accounts. Meaning, both fields share the same button.

Comment 34

[Bram Pitoyo [:bram]]

Attachment: payment form UX - 03 - review states

When the user’s edit is under review:
* The edit button is disabled
* The button title becomes “[button_title] saved” and rests in a disabled state
* The caption to the side of the button becomes “Under review”
* User can’t edit until that specific bit has been reviewed

Comment 35

[Andy McKay]

This is a big improvement thank you.

A couple of notes:
* In a meeting with Bango it sounds like viewing and editing bank details is not an option. From what I gather people will just have to enter them again.
* If people are giving bank details, then the paypal email address isn't used or needed at all. Using it as the key to the payment details won't work. Perhaps account nickname or something is needed (especially since people can't see the settings for that account)
* It has price tier and in-app payment next to each other. I'm not sure it's clear what the price tier is for from that. Perhaps something that says "sell your app on the marketplace" header is needed. Since it's directly next to in-app payment users might guess its for that.
* If the app is wanting in-app payments or to be sold on the marketplace we shouldn't let the form complete until they've added a payment source.
* It looks like you can remove payment sources, which is cool. Just so you know, I don't think we can (and should) ever delete that data for legal and transactional issues. We can stop it from ever showing up on the form for a user. Not sure if that's worth noting in the UX, probably not.

Comment 36

[Bram Pitoyo [:bram]]

Attachment: payment form UX - 04

The payment form UX has been updated with these notable things:
* Added help links to cover inbetween use cases, below the “Free” tab
* Payment account setup and edit form is redesigned
* It’s now possible to set up both PayPal and bank payment accounts
* The order of fields now goes from smallest (address) to biggest (country)
* Added help links for currency, company/vendor names, and financial/administrative emails


Optional reading: more details can be found below.

(In reply to Andy McKay [:andym] from comment #35)
> * In a meeting with Bango it sounds like viewing and editing bank details is
> not an option. From what I gather people will just have to enter them again.

The ability to view and edit bank details has been removed.


> * If people are giving bank details, then the paypal email address isn't
> used or needed at all. Using it as the key to the payment details won't
> work. Perhaps account nickname or something is needed (especially since
> people can't see the settings for that account)

I propose using a combination of account holder name + account number to identify bank account.

So it would look something like:
John Smith (12-XXXX-XXX345-00)

To identify PayPal accounts, we can use email, as usual.


> * It has price tier and in-app payment next to each other. I'm not sure it's
> clear what the price tier is for from that. Perhaps something that says
> "sell your app on the marketplace" header is needed. Since it's directly
> next to in-app payment users might guess its for that.

The header might be a good idea. I put it on the mockup. Keep in mind that the “Paid” tab is already selected at the top of this page. The tab was also selected at the start of the app submission process.

But I understand that the whole thing is a bit confusing.

The root cause of this problem is the fact that not every platform can have paid apps. On one hand, we have this disparity of feature. But on the other, we still want to let users know that one app can work on any device—as long as it’s free.

So we needed to clarify what devices support free apps, and what devices support paid. The “Free” and “Paid” tabs were designed to help organize this.

The confusing bit comes in the inbetween situations. For example:
* When a free app has in-app payment. It belongs under the “Paid” tab because it is only available for Firefox OS, but then the price is “free”
* When an app starts out with a promotional price of free, but is going to be made into a paid app at some point. It belongs under the “Paid” tab, because it’s going to be paid and the developer is going to accept payment eventually, but the actual price at the moment is free.

To help clarify and avoid confusion, let’s put two links that will answer these two use cases on the “Free” tab, right underneath device compatibility.


> * If the app is wanting in-app payments or to be sold on the marketplace we
> shouldn't let the form complete until they've added a payment source.

Agreed. Whenever in-app payment box is checked, the form shouldn’t complete until a payment source has been selected.

Comment 37

[Bram Pitoyo [:bram]]

I would love to get a feedback on this bug: whether the UI—which has grown more complex since v1’s mockup—have satisfied the feature requirement.

The next step on this is visual design, which I can help start, too.

Comment 38

[Kumar McMillan [:kumar]]

Hi Bram.
We are ready to implement your UI in the devhub! Matt Basta is working on it this week and can ping you if he has questions. One thing to note: We will not be supporting PayPal, only bank accounts. The change here is that we will not need the radio button for PayPal, it will just default to bank account. If you'd like to update the mocks for then go ahead but I think that should be a straight forward change for Matt to make.

Comment 39

[Kumar McMillan [:kumar]]

Matt, the docs for the Solitude API to register developers with is still in progress -- https://solitude.readthedocs.org/en/latest/topics/bango.html -- so ping Andy or me or check out the code in the resources module: https://github.com/mozilla/solitude/tree/master/lib/bango/resources The package and billing endpoints are the ones to use. Hopefully by the time you've started on the UI part we'll have some more docs for you.

Comment 40

[Andy McKay]

https://github.com/mozilla/solitude/blob/master/samples/bango-basic.py is the best docs :)

Comment 41

[Matt Basta [:basta]]

A few questions that don't require immediate answers:

- Bram: there's no phone number field for the payment account setup. Should I add one?
- The "Country" field is a dropdown. Do we have a list of countries which we can populate it with? Or should I just make it a textbox?

Comment 42

[Kumar McMillan [:kumar]]

(In reply to Matt Basta [:basta] from comment #41)
> - Bram: there's no phone number field for the payment account setup. Should
> I add one?

Phone number does seem to be required for registration. In the API docs it is marked as optional but in our tests it is actually required.

> - The "Country" field is a dropdown. Do we have a list of countries which we
> can populate it with? Or should I just make it a textbox?

Matt, in the appendix of the Mozilla Exporter API docs [1] you'll find a list of supported country codes.

[1] https://wiki.mozilla.org/Apps/ID_and_Payments#Mozilla_Exporter_API

Comment 43

[Matt Basta [:basta]]

Another issue: upsell isn't in the mockups. To respond to your request for clarification of what upsell is:

http://cl.ly/image/2R2P3K1f2n1i

Basically, it links your app with another app and marks your app as the "premium" version:

http://cl.ly/image/2L2b1U460d2Z

Comment 44

[Matt Basta [:basta]]

Can someone also please confirm my "personal glossary"?
- package == developer
- bankdetails == payment account
- bango number == app


Questions for andym/kumar since everyone seems to be offline:

- I'm ready to pass the account details to solitude. I'm assuming they go to /bango/bank. That endpoint takes a 'seller_bango' field. Is this already generated or is this something that I'm going to have to generate when the user flips their app to Paid?
- The mocks call for a list of bank accounts (both for managing the account list as well as choosing the account to tie to the app). I could be mistaken, but there doesn't seem to be an endpoint for this in Solitude.
- There seems to be some discontinuity surrounding the fields for the bank account. The bank details API requires some more information (bank name/address/zip/country).
- The package API requires a paypal and support email, as well.

As far as the extra required fields goes, I can just add those in no problem. OTOH, how do you want me to deal with fields that are split across the package (developer) and bank details (payment account)? Should I register one package per payment account (this seems dirty)?

Comment 45

[Andy McKay]

(In reply to Matt Basta [:basta] from comment #44)
> Can someone also please confirm my "personal glossary"?
> - package == developer
> - bankdetails == payment account
> - bango number == app

Yup. At this time, we figure if you want a different package, you can set up another account. That's sub optimal, but works for the moment.
 
> Questions for andym/kumar since everyone seems to be offline:
> 
> - I'm ready to pass the account details to solitude. I'm assuming they go to
> /bango/bank. That endpoint takes a 'seller_bango' field. Is this already
> generated or is this something that I'm going to have to generate when the
> user flips their app to Paid?

There won't be any information in solitude. So you are going to have check that the information exists or not in solitude and populate if not. It looks like the data in that form is a combination of data of multiple calls, bank, package and product. 

> - The mocks call for a list of bank accounts (both for managing the account
> list as well as choosing the account to tie to the app). I could be
> mistaken, but there doesn't seem to be an endpoint for this in Solitude.

Right. So we are assuming that a user will only have one set of Bango details at this point. When we add in more payment providers however you might be able to choose between Bango and Paypal. When I've added in a second paid app, being able to select your Bango account will avoid you having to set it up again.

> - There seems to be some discontinuity surrounding the fields for the bank
> account. The bank details API requires some more information (bank
> name/address/zip/country).

Bango is definitive.

> - The package API requires a paypal and support email, as well.

Yeah. We not sure what to do about PayPal. We should file bugs on these.

> As far as the extra required fields goes, I can just add those in no
> problem. OTOH, how do you want me to deal with fields that are split across
> the package (developer) and bank details (payment account)? Should I
> register one package per payment account (this seems dirty)?

Yep you got it.

Kumar will correct my inaccuracies ;)

Comment 46

[Bram Pitoyo [:bram]]

(In reply to Matt Basta [:basta] from comment #43)
> Another issue: upsell isn't in the mockups.
> Basically, it links your app with another app and marks your app as the
> "premium" version

The solution you linked to seems to work well for upselling apps. I think that we should put it to the side or below the “In-app payment” checkbox.

I am trying to determine if the relationship between free and premium app is one-to-one.

For example, can one free app have multiple premiums? Can one premium be linked to from many free apps? Or is it exclusively one free app per one premium app?

I am also trying to determine if the upsell happens both ways.

For example, when user views the free app, the page will say “Premium version available”. So when user views the paid app, will we say “Free version available”?

Comment 47

[Kumar McMillan [:kumar]]

(In reply to Andy McKay [:andym] from comment #45)
> (In reply to Matt Basta [:basta] from comment #44)
> > - The package API requires a paypal and support email, as well.

Just assume we're not using paypal right now. If you get API errors then that's a bug in the API. You could put [e-mail] or whatever while we're waiting for them to fix it.

As for support, we already have that in Marketplace (collected from the app submission page)

Comment 48

[Bram Pitoyo [:bram]]

Attachment: devices and payment page - visual design

Attached is the visual design for the page where the payment form (and the device compatibility) is located, as well as the edit mode for each.

Comment 49

[Matt Basta [:basta]]

This is what we've got right now:

http://cl.ly/image/1T0j2v3z3L00

The upsell form is a little cut off, though.

Comment 50

[Bram Pitoyo [:bram]]

Attachment: add new payment account (popup window) - visual design

This is the visual design for what would happen if user clicks on the “Add or manage payment accounts” link on attachment 691654 [details].

Comment 51

[Bram Pitoyo [:bram]]

(In reply to Matt Basta [:basta] from comment #49)
> This is what we've got right now:
> 
> http://cl.ly/image/1T0j2v3z3L00
> 
> The upsell form is a little cut off, though.

What we got right now looks fine to me! I just thought that I needed to make the edit interaction the same with the rest of the pages. But the big issue is to get the feature working rather than refining the UX. Thanks, Matt!

Comment 52

[Kumar McMillan [:kumar]]

https://github.com/mozilla/zamboni/commit/7ed7ea869a6d3bf8028c1456446fdb32b5a9ed45 (dev reg)
https://github.com/mozilla/zamboni/commit/fd3e5698deedc2b3e4172058aa8236715b9a90c0 (removes old code)

Thanks Basta! There are some loose ends to tie up, more bugs on the way for that.

Comment 53

[Kumar McMillan [:kumar]]

There's a problem here in how bango products are created. The package ID is not passed to Solitude (which may also require a tweak to the zamboni model). I'll take it.

Comment 54

[Kumar McMillan [:kumar]]

The model has been fixed and it's working on dev now. https://github.com/mozilla/zamboni/commit/0111a1c93345dc52d9b3c02d2e837ca6c4226c12

Comment 55

[Kumar McMillan [:kumar]]

This still isn't working with the Bango API right. I have fixes here but I'll land them after the holiday. Happy Xmas all!

https://github.com/kumar303/zamboni/compare/seller-uuid

Comment 56

[Kumar McMillan [:kumar]]

Fixed.
https://github.com/mozilla/zamboni/commit/d5fcfd99811724530b8bf9e6f385dfd3d0ea14a8
https://github.com/mozilla/zamboni/commit/2c150cdbcc13d8fb84740e3acd5ad1592472509e