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)
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.
Reporter | ||
Updated•11 years ago
|
Blocks: marketplace-payments
Priority: -- → P1
Comment 1•11 years ago
|
||
Here's some relevant discussion about how to handle this if there's a manifest error or purchase error: bug 780415
See Also: → 780415
Comment 3•11 years ago
|
||
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
Comment 4•11 years ago
|
||
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.
Comment 5•11 years ago
|
||
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.
Reporter | ||
Comment 7•11 years ago
|
||
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.
Updated•11 years ago
|
Flags: needinfo?(keir)
Comment 8•11 years ago
|
||
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)
Comment 9•11 years ago
|
||
(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
Comment 10•11 years ago
|
||
The billing web service is https://webservices.bango.com/directbilling_v4_0/?wsdl
Reporter | ||
Comment 11•11 years ago
|
||
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.
Updated•11 years ago
|
Assignee: nobody → amckay
Priority: -- → P2
Updated•11 years ago
|
Target Milestone: --- → 2013-07-11
Updated•11 years ago
|
Target Milestone: 2013-07-11 → 2013-07-18
Comment 12•11 years ago
|
||
(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.
Updated•11 years ago
|
Target Milestone: 2013-07-18 → 2013-07-25
Updated•11 years ago
|
Target Milestone: 2013-07-25 → ---
Updated•11 years ago
|
Version: 1.2 → 1.4
Updated•10 years ago
|
Version: 1.4 → 1.5
Updated•10 years ago
|
Assignee: amckay → nobody
Priority: P2 → --
Version: 1.5 → Avenir
Comment 13•10 years ago
|
||
Did you mean to remove the priority Andy? If its not P2 wouldn't it be P1 or P3?
Flags: needinfo?(amckay)
Comment 14•10 years ago
|
||
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
Updated•10 years ago
|
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.
Description
•