Closed
Bug 987824
Opened 10 years ago
Closed 10 years ago
Set MNC MCC when transaction is configured.
Categories
(Marketplace Graveyard :: Payments/Refunds, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: scolville, Assigned: scolville)
References
Details
(Whiteboard: [qa+])
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.
Assignee | ||
Updated•10 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•10 years ago
|
Summary: Add interstitial MNC MCC page → Set MNC MCC when transaction is configured.
Updated•10 years ago
|
Priority: -- → P1
Assignee | ||
Comment 2•10 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [qa+]
Assignee | ||
Updated•10 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 3•10 years ago
|
||
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.
Assignee | ||
Comment 4•10 years ago
|
||
Merged: https://github.com/mozilla/webpay/commit/5207f1de45ee8c67623637b094528dc098edec00
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 5•10 years ago
|
||
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'.
Assignee | ||
Comment 6•10 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•