Don't make me set up refund token every time I enroll an app in the Marketplace

RESOLVED WONTFIX

Status

Marketplace
Payments/Refunds
P4
normal
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: krupa, Unassigned)

Tracking

Points:
---

Details

(Whiteboard: [ye-olde-paypal])

(Reporter)

Description

6 years ago
Developers have to set up refund token every time they enroll an add-on into Marketplace.

Since the token is associated with the developer's PayPal account, please look into the feasibility of making the developer set it up only once.

Comment 1

6 years ago
The Paypal account is assigned per add-on and not per developer. You have type in your paypal id for every add-on. It's a bit of a pain, but not an onerous one for developers. I don't think it's high priority.
Target Milestone: 6.2.8 → 4.x (triaged)

Updated

6 years ago
Blocks: 690899
Priority: -- → P4
Assignee: nobody → ashort
Target Milestone: 4.x (triaged) → 6.3.3
Target Milestone: 6.3.3 → 6.3.4
Target Milestone: 6.3.4 → 6.3.5
Target Milestone: 6.3.5 → 6.3.6
Blocks: 710074
No longer blocks: 690899
Target Milestone: 6.3.6 → 6.3.7
My idea for this:

Add a PaymentDetails model as an attribute of UserProfile, containing a paypal ID and refund permissions token. When a premium addon/app gets created, the wizard checks to see if the user has these values set, and populates the form with them if so. When the form's submitted, update the user if it doesn't have paypal id/token already set.

Alternately, we could just scan for existing paid addons from the same user  when populating the form, and pull in paypal id/token from the first one found, if any. This would be simpler but wouldn't provide the same opportunity for exposing the paypal ID as part of the editable user information.

Thoughts?

Comment 3

6 years ago
I prefer the first, it will allow developers to set defaults and then override them on a per add-on basis. 

The second will get confusing with multiple developers for apps.
Target Milestone: 6.3.7 → 6.3.8
Depends on: 717419
Target Milestone: 6.3.8 → ---
Blocks: 752013
No longer blocks: 687980, 710074
(Reporter)

Comment 4

6 years ago
This is true for apps as well
Assignee: ashort → nobody
Component: Developer Pages → Payments/Refunds
Product: addons.mozilla.org → Marketplace
QA Contact: developers → payments-refunds
Summary: Don't make me set up refund token every time I enroll an add-on into Marketplace → Don't make me set up refund token every time I enroll an app inMarketplace
Whiteboard: [marketplace][t:muffin]
Version: unspecified → 1.0
Summary: Don't make me set up refund token every time I enroll an app inMarketplace → Don't make me set up refund token every time I enroll an app in the Marketplace
we should be careful not to tie payment details to developers, they are tied to addons. An addon can have multiple developers associated with it and I think this will become more common when a team of developers work on an app and invite someone from their sales dept to fill in the financial details. I still think ashort's model proposal works, I just wanted to mention this use case.

Comment 6

6 years ago
As things like the API and the possibility of multiple payment sources expands, I think there needs to be more tie to the developer. Payment sources and the payment source specific stuff (paypal id, paypal tokens) should be tied to the developer. When they set up an addon, they select the payment source they want to use and enter the addon specific stuff (price tier, in-app config and the like).

I think there would be permissions around which developers payment sources can be used and who can change those payment sources.

Which means I think ashorts original proposal will to be expanded to provide a payment source table and multiple links to it, removing the single paypal_id column sitting on the addon table. The scenario where an app can bought with paypal or a carrier depending upon the situation is probably going to arrive pretty soon.

@gkoberger is working on this in some new mocks for payment sources for the marketplace.
I'll post something this weekend. The more I worked on it, the more complicated I realized it was. 

The only issue with developer-tied payments is apps (and addons) with multiple owners. That being said, I'm with Andy. Developer-tied is definitely the right way to go, especially with the API coming.
No longer blocks: 752013
Whiteboard: [ye-olde-paypal]
eh, PayPal
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.