Connectivity: wifi with Data Roaming Enabled SIM used: telcel SIM (552661-8995) Gaia/device: Flame/2.1 test app used:Test app (bangoandboku)- 3.75 pesos and 1.50pesos steps to reproduce: 0. User is logged in 1. Search for paid app on marketplace stage app 2. Start the purchase flow 3. Enter PIN expected behavior: Boku screen loads actual behavior: After showing 'retrieving transaction' for a while, the purchase fails with "Error- an unexpected error occurred TRANS_NOT_FOUND" logs show 02-04 12:31:58.260 E/GeckoConsole( 213): Content JS LOG at https://marketplace-cdn.allizom.org/mozpay/spa/js/main.min.js?bust=33c56986201a51fccfb663b197dd27319cfaa274:62 in r: [lib][cancel] Running paymentFailed with errorCode: TRANS_NOT_FOUND 02-04 12:31:58.270 I/Gecko ( 213): -*- PaymentManager: Received 'Payment:Failed' message from content process 02-04 12:31:58.290 I/Gecko (21938): -*- PaymentContentHelper: Received message 'Payment:Failed': {"requestId":"id{10483ea1-ade1-44bd-9af1-a3a431f3fe89}","errorMsg":"TRANS_NOT_FOUND"} 02-04 12:31:58.300 E/GeckoConsole( 213): 1423081918309 Identity.FxAccounts DEBUG unwatching: {102fa72e-3d0f-467c-9a62-1abd20b07e8b} 02-04 12:31:58.300 E/GeckoConsole( 213): 1423081918309 Identity.FxAccounts DEBUG unwatching: {102fa72e-3d0f-467c-9a62-1abd20b07e8b} 02-04 12:31:58.480 E/GeckoConsole(21938): Content JS ERROR at https://marketplace-stage.cdn.mozilla.net/media/fireplace/js/include.js?b=1423077629435:4 in u/<: [fxpay] mozPay: received onerror(): TRANS_NOT_FOUND 02-04 12:31:58.480 E/GeckoConsole(21938): Content JS ERROR at https://marketplace-stage.cdn.mozilla.net/media/fireplace/js/include.js?b=1423077629435:4 in u/<: [payments] fxpay error: TRANS_NOT_FOUND reproducible: yes

kraj-12519% adb logcat | grep -E 'MCC|MNC' E/GeckoConsole( 1223): Content JS LOG at https://marketplace-stage.cdn.mozilla.net/media/fireplace/js/include.js?b=1423077629435:4 in u/<: [mobilenetwork][undefined][getNetwork] Trying MCC = 334, MNC = 020, SPN = TELCEL

trying out some more logging to see what Spartacus is sending: https://github.com/mozilla/spartacus/commit/f7440626c5f3c332446c84aa112fad02f2372349

/main.min.js?bust=97be100b803d47f0a8523c09308e53eee22d9ba2:63 in a<.startTransaction: [models][transaction] starting transaction with MCC:MNC 334:020 ^ looks like the client is starting with the right network so let me check on the server logs

ok, I found the error: http://sentry.dmz.phx1.mozilla.com/marketplace-stage/marketplace-stage-webpay/group/23960/ When we check the transaction Boku says 'Consumer info validation error' which sadly is not mentioned in our version of their API documentation. Krupa, is there anything you can think of that might be odd about the 'consumer' account? I assume in this case it means your billing account associated with the SIM. Does it work with any other SIM? The Boku transaction ID is 50841849063a61933503363a (that may not be this exact one but it's one that is failing)

I cannot think of anything wrong with the SIM since I have previously purchased apps on that SIM. It has a $100 balance.

Hi John. Can you help us debug why we're getting 'Consumer info validation error' (code: 500) for our API call to action=verify-trx-id ? This is on our stage server which connects to the API as user ID mozilla-stage-server . An example of a Boku transaction causing the failure is 50841849063a61933503363a

Ah, thank you for clarifying. It appears that our RISK platform nixed that transaction because Krupa's IP address (US based) didn't match its country (MX). I have whitelisted the MSISDN so this doesn't happen again.

As for the 'verify-trx-id' API call, a more secure way of determining the validity of a callback is to verify its MD5 signature. More information on this can be found in the (attached) Boku Security Implementation guide. The 'verify-trx-id' API call just confirms whether a transaction that occurred in the past 72 hours originated from Boku's payment platform. However, it doesn't provide any details about the integrity of the callback data (MD5 signature does).

I re-ran the 'verify-trx-id' API calls made by Mozilla over the past 7 hours or so and did not encounter a "Consumer info validation error": action=verify-trx-id&trx-id=5bad29ba36d720d1409ec931&merchant-id=mozilla-stage-server action=verify-trx-id&trx-id=5bad4ad83a69f81af8645b10&merchant-id=mozilla-stage-server action=verify-trx-id&trx-id=5ba8003d3a69f81a0e31d335&merchant-id=mozilla-stage-server action=verify-trx-id&trx-id=5611d08f3a69f81a99995df1&merchant-id=mozilla-stage-server action=verify-trx-id&trx-id=5b433a893a2924a0d40c9555&merchant-id=mozilla-stage-server action=verify-trx-id&trx-id=5b3fc7533a2924a0d2325a85&merchant-id=mozilla-stage-server action=verify-trx-id&trx-id=5b327e623a69f81a86e108e5&merchant-id=mozilla-stage-server action=verify-trx-id&trx-id=5611d08f3a69f81a99995df1&merchant-id=mozilla-stage-server action=verify-trx-id&trx-id=5611d08f3a69f81a99995df1&merchant-id=mozilla-stage-server action=verify-trx-id&trx-id=5611d08f3a69f81a99995df1&merchant-id=mozilla-stage-server

Thanks John. I'm not seeing that error anymore either. I'm seeing mostly this one Provider=boku post failed: Client Error 400: https://payments.allizom.org/provider/boku/event/ Content: {u'param': [u'Transaction already completed; uuid=webpay:3cbee13e-0ea1-49e7-982e-5a091b6ff6bd']} which is most likely a problem with Mozilla's system. I'll investigate. We also are seeing periodic timeouts from Boku though: HttpServerError: Server Error 500: https://payments.allizom.org/provider/boku/event/ Content: {u'error_message': u'API Error: 6 Failed - Transaction timed out', u'error_code': u'BokuException', u'error_data': {}} Our graph shows that it's been happening throughout testing as much as 20 times in one day but mostly less than that. I also see the price error in our logs still: HttpClientError: Client Error 400: https://payments.allizom.org/boku/transactions/ Content: {u'__all__': [u'This price was not found in the available price tiers.']} which is the issue we already discussed.

Krupa, now that I added some additional logging (bug 1130036) can you reproduce and attach a new logcat at your convenience? That will help me tie together all the different errors I'm seeing.

there's a chance that bug 1130119 fixed this too

in these newer attached logs, our call to get_provider_seller_uuid() is returning ObjectDoesNotExist which means the app cannot be found in Solitude. That's odd. Is it still happening after the patch from bug 1130119?

New logcat from krupa. The app being purchased isn't set up right. This is what caused the trans_not_found: >>> res = client.slumber.generic.product.get_object_or_404(public_id='4b65f657-7a57-497c-9ebd-35584bb1c26b') Traceback (most recent call last): File "<console>", line 1, in <module> File "/data/addons-stage/www/marketplace.allizom.org-webpay/deploy-webpay-stage-20150209202728-ccf7497243/venv/lib/python2.7/site-packages/curling/lib.py", line 248, in get_object_or_404 return self.get_object(**kw) File "/data/addons-stage/www/marketplace.allizom.org-webpay/deploy-webpay-stage-20150209202728-ccf7497243/venv/lib/python2.7/site-packages/curling/lib.py", line 234, in get_object raise ObjectDoesNotExist ObjectDoesNotExist I'm digging deeper into why...

This purchase failed because the app only supports Bango, not Boku. That's weird that it failed though. >>> from mkt.webapps.models import Webapp >>> from mkt.constants.payments import PROVIDER_LOOKUP >>> [PROVIDER_LOOKUP[p.payment_account.provider] for p in Webapp.objects.get(pk=504579).all_payment_accounts()] ['bango']

from IRC: krupa: just purchased an app with both bango and boku set up and it worked bug 1132157 also filed for the bango-only thing but that may not be valid