Created attachment 8526460 [details] wmw-IAP-Error-2014-11-20-17-16-03.png Retrying again still without sitting a PIN in IAP Attempt purchase Enter a PIN when requested (note still haven't actually set one or been asked too) Error 'The payment method or price point is not supported in this region or operator" (see screen shot) This is the wrong error. The real problem is I Do Not have a PIN set on this account and have never been prompted to enter one through the IAP process. Updated in here: https://docs.google.com/spreadsheets/d/1YTGd3jM5lBbX0A2u5D6rFlj0bGD0GX1ldgvgsj_833M/edit?pli=1#gid=0
UNSUPPORTED_PAY is triggered from a Bango error. "Enter a PIN when requested (note still haven't actually set one or been asked too)" < you are doing without ever being asked for a PIN? What price item are you trying to buy?
Hi Nick, Is it possible that you have connected to the service using an SFR France SIM at any point ? Kind Regards Chris Goulding Bango
(In reply to Andy McKay [:andym] from comment #1) > What price item are you trying to buy? Unless I got a one off JWT with an invalid price point, we've been able to successfully do an IAP with the product on numerous other occasions. (In reply to Bango Platform Operations Center from comment #2) > Is it possible that you have connected to the service using an SFR France > SIM at any point ? I believe no, but Marc is the one who saw this. Any surprises Marc? Have you been using a French SIM? :P
I only have US At&T sims and have only ever used the same SIM for this testing. The account creation flow for a new account while in In App Purchases never prompts you for any credit card info or PIN creation so when you back and try and make a purchase after verifying your email for a new account, you now are prompted to enter your PIN which has never been set.
I have hunch what this might be, I'm wondering if the failure in bug 1024065, is causing a null response to be cached by webpay. When a second request comes in for the same amount, it finds that cached null value and raises a response. If that's the case it fails before its got anywhere near Bango. Will research this scenario this morning.
For the record, we researched comment #5 and believe it is not the case because our caching layer would only come into affect after the point where we are currently seeing 'bad status line' connection errors.
Since this is hard to reproduce and it's an error returned by the payment processor (Bango), one thing that would be helpful for next time it appears is a log of HTTP requests/responses that the device is seeing. Instructions: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging#Firefox_OS_phones
Can't reproduce. If we can find a way to reproduce, will re-open.