Closed Bug 864875 Opened 11 years ago Closed 10 years ago

Hide Marketplace apps after broken Bango API calls

Categories

(Marketplace Graveyard :: Payments/Refunds, defect, P4)

Avenir
x86
macOS
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: kumar, Unassigned)

References

Details

If any Bango API call fails during Marketplace payment setup, we should hide (or flag?) the app so it cannot be purchased.
Priority: -- → P1
Here's some relevant discussion about how to handle this if there's a manifest error or purchase error: bug 780415
See Also: → 780415
cvan, don't hate me :)
Assignee: nobody → cvan
This is specifically for setting up payments or for when people try to make payments?  comment 0 says during setup but i'm not sure why the app would ever be purchasable if something is failing during setup.
Assignee: cvan → nobody
There are multiple issues here and we addressed similar with Paypal.

- its possible to get to the end of the setup right now and end up with an app that can't actually be purchased. This occurs when there's a problem with Bango at a certain point in the process. Because we've got a bunch of API calls all over the place, we've lost the ability to keep ACIDity.

- there can be a number of failures that occur during payments, these could be the fault of developers or bango or not.

I'd suggest:

- see if we can write a "check its good for bango" method that checks as best as it can that an app is good to be sold. This might be checking the zamboni and solitude db's and maybe call some Bango API's. We can then call this at suitable points eg: cron job, after setting up payments to ensure things are ok

- we want to be very careful on pushing a paid app out of the marketplace. It could be that bango is down, or solitude is down. I would suggest a whitelist of failures and when those occur we notify the developer or push into the re-review queue. We don't want to push every paid app into the re-review queue when Bango goes down, that would suck.

If I don't see any dissent on these ideas, I'll file bugs on these.
I like that, although I'd skip #2 until we have an actual whitelist.  No need to write that feature if we don't have actual errors we can act on.
bug 865034 and bug 865035 added.
Priority: P1 → --
The approaches in comment #6 sound great to me. Another thing to do is to audit all code here https://github.com/mozilla/zamboni/blob/master/mkt/developers/models.py We should make sure all payment setup is in a transaction so that API failures roll back any zamboni DB changes that might otherwise put the app in a purchasable state.
Flags: needinfo?(keir)
You can check if the bango apis are available by doing a GET request to the billing webservice WSDL.  Other than that determining if 'its good for bango' would require knowledge of the price, the currency, the connection type and the bango number.
Flags: needinfo?(keir)
(In reply to Keir Kettle from comment #8)
> You can check if the bango apis are available by doing a GET request to the
> billing webservice WSDL.  Other than that determining if 'its good for
> bango' would require knowledge of the price, the currency, the connection
> type and the bango number.

So that's CreateBillingConfiguration? Cool we'll do that then. Thanks
Andy, it sounds like we can maybe do a billing config call similar to what webpay does to start a payment https://github.com/mozilla/webpay/blob/master/webpay/pay/tasks.py#L104-L113 However, I'm not sure if we can fully simulate everything without a real transaction.
Assignee: nobody → amckay
Priority: -- → P2
Target Milestone: --- → 2013-07-11
Target Milestone: 2013-07-11 → 2013-07-18
(In reply to Andy McKay [:andym] from comment #4)
> There are multiple issues here and we addressed similar with Paypal.
> 
> - its possible to get to the end of the setup right now and end up with an
> app that can't actually be purchased. This occurs when there's a problem
> with Bango at a certain point in the process. Because we've got a bunch of
> API calls all over the place, we've lost the ability to keep ACIDity.
> 
> - there can be a number of failures that occur during payments, these could
> be the fault of developers or bango or not.

The API is in place, filed bug 895193.

> I'd suggest:
> 
> - see if we can write a "check its good for bango" method that checks as
> best as it can that an app is good to be sold. This might be checking the
> zamboni and solitude db's and maybe call some Bango API's. We can then call
> this at suitable points eg: cron job, after setting up payments to ensure
> things are ok

Same API is in place.

Solitude now knows which apps have explicit check failures and transaction failures. I'm thinking we make a solitude API that returns a list of "failed" apps with details about those failures. The Marketplace or some other tool can consume that list and decide what it wants to do about them.
Depends on: 895193
Depends on: 895199
Target Milestone: 2013-07-18 → 2013-07-25
Target Milestone: 2013-07-25 → ---
Version: 1.2 → 1.4
Version: 1.4 → 1.5
Assignee: amckay → nobody
Priority: P2 → --
Version: 1.5 → Avenir
Did you mean to remove the priority Andy?  If its not P2 wouldn't it be P1 or P3?
Flags: needinfo?(amckay)
Sorry, I'll drop it down. I'm just not sure this is an issue anymore, Bango will pretty much accept the payment for any payment account and then sort it all out later. I haven't yet seen a payment fail with Bango because of anything the developer did.

So it might nice to do a report of this, but at this moment, I don't see us needing it.

In comparison, Paypal had the habit of breaking for a multitude of reasons on the payment account. Currencies, balances and so on would cause issues. If we implemented Paypal or another payment provider, we could revisit it then.
Flags: needinfo?(amckay)
Priority: -- → P4
No longer depends on: 895193
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.