Make it clearer that payment details aren't per-app

[Anthony Lenton]

The MyApps portal have had several submissions of apps by users that assume that the payment details can be provided on a per-app basies.

There is a sign up that clearly states that the payment details are shared between all applications, but still this isn't intuitive it seems. If a company submits several apps it expects to be able to direct the earnings to different paypal accounts.

So, Application should include payment details, and default to the developer profile's payment details if the application doesn't specify any.

Update: No need to touch the model at all, check comment #5.

[Michael Nelson (michael.nelson)]

Preimplementation chat outcome:

Migrate to a separate PaymentOptions model.
On the Application payment options screen, users can either select from an existing payment option, or create a new one.
On the account details for a user, all payment options are displayed and can be edited (clearly showing which apps they are being used for), and deleted (for those payment options that are not in use by any apps, although probably a soft-delete flag for the record?).

Details: https://pastebin.canonical.com/54322/

[Michael Nelson (michael.nelson)]

Just a question regarding separation of contact details (street, country etc.) and payment info (currently just paypal_info): achuni confirmed that we want both to be per-app, but do we want contact details to be independent of payment details?

ie. Case 1) All together: simpler UI (initially), but as soon as a single dev wants multiple payment accounts, all with the same address, you've got redundant data (which becomes a pain when the dev does in fact change address, needs to update all records)

Case 2) Separate objects: dev selects a payment option and contact address for each app (when there are multiple) and can change them independently.

After chatting with achuni, I'll go down the (1) route, but we can incrementally improve to (2) if we hear back.

[John Pugh (jpugh)]

Contact details should be separate from billing/payment details. There will be cases where an app is submitted from the same person but they want different payment details as noted - for the payment details we still need name address, etc for invoicing purposes.

Case 2 seems to be a better option.

I don't want to make it more difficult for the submitter, yet we'd like to make it more flexible overall.

[Michael Nelson (michael.nelson)]

On Wed, Oct 19, 2011 at 5:57 PM, John Pugh <email address hidden> wrote:
> Contact details should be separate from billing/payment details. There
> will be cases where an app is submitted from the same person but they
> want different payment details as noted - for the payment details we
> still need name address, etc for invoicing purposes.
>
> Case 2 seems to be a better option.
>
> I don't want to make it more difficult for the submitter, yet we'd like
> to make it more flexible overall.

Thanks John. We thought so too, but wanted confirmation that it was
what you wanted before investing the extra time required.

[Anthony Lenton (elachuni)]

Discussed with jpugh, the site doesn't really need per-app payment details, as it would mean extra dev work, a more complex model and more work for finance. The issue is that the user expects per-app payment details due to the way things are communicated in the site.

One way to make things clearer to the user would be to remove the "Getting paid" step from the app submit workflow, so the developer will only see payment details on the "My Account" page, which should make it crystal clear.

Ideally, the developer shouldn't be allowed to submit the app if no payment details have been provided for the account, could the pre-submit checks send the developer to the account page to provide payment details if needed?