For bug 562790 I need to know how the payment info is going to come in the API and whether we need to bump to some new version to ensure we get it (1.6?). For add-ons that are pay-for we basically need two things, the price (with currency symbol same as bug 610500) and the url to direct users to to actually proceed with the purchase. I guess maybe along the same lines as contribution_data it could go: <payment_data> <link>https://addons.mozilla.org/...</link> <amount>$217635.23</amount> </payment_data> Presumably we won't be including a url to the xpi in the install tag however removing the install tag presents a problem, we currently use that to get the OS that the add-on works on so we kind of need to leave that there, maybe instead it would be as easy to represent purchase info in the install tag like so: <install os="ALL" size="123456" price="$2652">https://addons.mozilla.org/...</install> Thoughts?

Adding fields to the API isn't a big deal. If we modify fields, we should increment to 1.6. For donations, we currently have: <contribution_data> <link>https://addons.mozilla.org/en-US/firefox/addon/:id/contribute/?source=api</link> <suggested_amount currency="USD">5.00</suggested_amount> <meet_developers>https://addons.mozilla.org/en-US/firefox/addon/4490/developers?src=api</meet_developers> </contribution_data> For payments, we won't have a way to buy directly off the API, so they can just go to the add-ons detail page and proceed from there. We should add the following snippet to the XML for add-ons that enable payments: <payment_data> <link>https://addons.mozilla.org/en-US/firefox/addon/:id/?source=api</link> <amount amount="5" currency="USD">$5.00</amount> </payment_data> Anything missing from that?

Looks good. In this case I guess there should just be an empty install tag for the supported operating systems?

Can you use <all_compatible_os> instead?

Oh hadn't seen that had appeared. We should be able to use that.

Looks like all_compatible_os is nominated for removal in https://bugzilla.mozilla.org/show_bug.cgi?id=582085. Would you rather have empty installs or all_compatible_os?

(In reply to comment #5) > Looks like all_compatible_os is nominated for removal in > https://bugzilla.mozilla.org/show_bug.cgi?id=582085. Would you rather have > empty installs or all_compatible_os? It makes more sense to keep all_compatible_os I think (also I've already written the patch to use it!), that bug was filed before we thought about the non-available-install case.

(In reply to comment #1) > <payment_data> > <link>https://addons.mozilla.org/en-US/firefox/addon/:id/?source=api</link> > <amount amount="5" currency="USD">$5.00</amount> > </payment_data> A point of clarification. The text in the tag should be the localised currency value, we'll just display it as-is, so f.e. my use "," as the decimal point in appropriate languages. The number in the amount attribute on the other hand should be a plain number as can be interpreted by JavaScript so would always use "." as the decimal point. This is important as we'll be using the amount for sorting purposes.

Sounds good. I'm happy to keep this around as the "Implement this" bug but kicking to Q2 for that stage.

Sounds good, updating the summary to match

I talked with andym on IRC a bit. Since this is so closely related to contributions (and we can't have both, I assume?!) it would make sense to do this: <payment_data type="contribution"> <link>https://addons.mozilla.org/fr/firefox/addon/:id/?source=api</link> <amount amount="5" currency="USD">$5,00</amount> </payment_data> And swap the type attribute to "required" or something if it was a for-pay add-on. We haven't seen a final marketplace spec, so let's not implement this until we're sure it's what we need.

We'll do this is part of the marketplace. Type can be "contribution" or "premium". If payment_data isn't present, then it;s free. We want to make sure we localise the price depending upon the tier of the requested locale.

Modifying contribution_data to payment_data type="contribution" will require an api version bump as per comment 1

I must have missed comment 10. Firefox 4 supports the spec we agreed on up to comment 7. If we're actually going to use something else instead then we'll need a new client bug to support the new spec and about a 12-18 week lead time before it can be in users hands (Likely Firefox 10 at the earliest right now).

No point in making life complicated, I'll stick to comment 7 format.

https://github.com/jbalogh/zamboni/commit/db3f7e Using comment 7 format.