To handle provider differentiation we need to get the MNC/MCC ahead of the page that's currently behind /mozpay/. This will likely just be case of showing the throbber and then getting the necessary data if available and passing it to the start of the payment process in webpay.

https://github.com/mozilla/webpay/commit/ecff4048f152b3e147ad13770cefef8c04eedbdb QA Notes: When this is landed on stage we need to check end-to-end payment flow for any regressions.

Testing this on Stage and found issues so re-opening so I can cover the extra cases where the transaction start needs to be called. There's a case where you're in session and the transaction isn't started: https://pastebin.mozilla.org/4753339 Should just be a case of adding additional cli.startTransaction calls.

Merged: https://github.com/mozilla/webpay/commit/5207f1de45ee8c67623637b094528dc098edec00

Just to give some context to these changes to aid QA. * All cases around how you get into payments need to be checked. E.g. logged-in. Having recently entered a pin. Reset and locked flows etc. * A failure is where you can't reach the bango screens and get stuck with a spinner which eventually times out with TRANS_TIMEOUT. Tracking where we're missing configuring the transaction is much easier if you can provide the output of 'adb logcat | grep -i console'.

Ok so I've done a round of testing with a 1.3 Keon on wifi via Stage. This is what I've tested as examples: In each case I've just looked to ensure I can get to the bango screens. * Test locked flow (test I can get locked out and returning within 5 mins shows locked screen) * Test reset flow via forgot pin link * Test already logged in (e.g. enter pin successfully, then bail then start again) * Test was-locked after the 5min lockout check I can get to the payment screens after entering a pin. * Test was-locked pin reset flow. * Test create pin flow. * Test standard successful pin entry flow.