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.

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.

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?

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.

This is true for apps as well

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.

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.

eh, PayPal