Closed Bug 832108 Opened 11 years ago Closed 11 years ago

Add support for a SMS inline activity to allow switching between the trusted UI within marketplace and the SMS app for the payment SMS challenge user flow

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::SMS
Platform:
Other
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: krupa.mozbugs, Unassigned)

References

Details

(Keywords: productwanted, Whiteboard: interaction, v2) 

steps to reproduce:
1. Launch marketplace-dev app on your unagi phone
2. Log in to Identity
3. Search for the paid app 'private yacht'
4. Click on the purchase button
5. Create your Payments PIN
6. When prompted to send an SMS to 22646, click on 'Send SMS' button
7. Trusted UI closes and SMS app is launched
8. Send the specified SMS

expected behavior:
a. If the SMS was sent successfully, then the SMS app closes and returns focus to the trustedUI, so that the user can proceed with the app purchase.
b. If the SMS was not sent, we return the focus to the trustedUI, where the user  is shown an error message with an option to return to the marketplace app or try again(?)

observed behavior:
- After successfully sending the SMS, the user has to close the SMS app and manually launch the marketplace app to proceed with the purchase.
- If the SMS failed, the user is abandoned in the SMS app.

logs:
http://pastebin.mozilla.org/2066299
Talked with Fabrice about this on IRC.

What the payment provider probably is doing is firing a web activity over to the SMS app to send a new message after step #6 from the marketplace dev app in the browser. Upon finishing sending the SMS on step #8, we should return back to the browser app with a trusted UI shown, whether it's successful or not with information back to the calling app on the success or failure.

However, it looks like the 2-way activity is failing here for SMS.

Etienne - Fabrice referenced you as a good point of contact here for resolving this. Any thoughts?

testcase-wanted - I'm going to get a reduced testcase for this.

Noming also as this impacts a very bare bones flow in payments.
blocking-b2g: --- → tef?
Flags: needinfo?(etienne)
Keywords: qawanted, testcase-wanted
QA Contact: mbarone976 → jsmith
So in my reduced test case I tried I see that it's one way when I tried this:

http://jds2501.github.com/webapi-permissions-tests/smsactivity.html

So we might be doing the right behavior here. But I'm not sure. I'm going to wait for Etienne's input here.
Ah, I think I found what's going on in the source:

window.navigator.mozSetMessageHandler('activity', function actHandle(activity) {
  if (!MessageManager.initialized) {
    MessageManager.init();
  }
  // XXX This lock is about https://github.com/mozilla-b2g/gaia/issues/5405
  if (MessageManager.lockActivity)
    return;
  MessageManager.lockActivity = true;
  activity.postResult({ status: 'accepted' });
  var number = activity.source.data.number;
  showThreadFromSystemMessage(number);
});

Looks like what we're doing here is that we're immediately sending a success back that the SMS activity was accepted. Then, we move onto grabbing the number off of the activity (which appears to work based on Krupa's comment) and show the thread in the SMS app.

I don't get the sense by looking here that this actually is a two-way web activity - it looks like it's a one way web activity where you will remain in the SMS app.
Actually, I think it's intended behavior that this is one-way. Here's an example of why this makes sense:

1. Create a contact with a phone number in the Contacts app
2. Select the contact and the message symbol

=> We fire a web activity over to the SMS app with the contact info

3. User proceeds to start SMS conversation

This represents a one-way activity, and makes sense that it is, given that we move over to the app to begin a conversation with a given set of contact information. Bouncing back in a two-way activity would be incorrect, as with most SMS threads, conversations go on for multiple messages.

Sounds like this is not a bug in the SMS app, but is expected behavior. The bug lies then in the payment provider's incorrect understanding of how the SMS activity works.
blocking-b2g: tef? → ---
Yes the SMS app does not provide an "inline" activity at the moment.
And looks like that's what the payment flow in the description is expecting.

So this is actually a feature request: implement an inline activity support for the SMS app.
Flags: needinfo?(etienne)
Product Wanted & UX input needed.

So, it's end game right now, so trying to implement a new feature to solve a problem we didn't think about in the payment flow puts us at high risk for missing the "10 day" deadline Andreas has mentioned. However, Rick has indicated that payments are a 2013 top objective, so screwing up anything in this flow can have some bad consequences on the phone and marketplace's success.

Peter and David - What can we do mitigate the problem presented in this bug for v1?

The original optimal solution we had got cut from v1 due to risk - which was silent SMS to the SMS challenge for Bango. The backup less optimal solution was to do the SMS challenge through a web activity - although what was intended was a 2-way, inline activity. However, the SMS app for v1 right now only supports a one-way, window activity. This means that once the user leaves the payment flow to do a SMS challenge, they will be stuck in the SMS app unless they explicitly decide to return back to the app in the payment flow. That's a very bad user experience to require an explicit app change. It also can potentially heavily impact a "time to complete" speed for the payment flow, potentially even causing us to lose users in the process of finishing off the payment given a poor UX this provides.

If product feels strongly that we're going to have to implement an inline activity to fix this problem in the SMS app, then feel free to modify the bug title to indicate that and mark this bug to block. If there are other options available the payment provider or marketplace can do to help ease the pain of this known missing feature needed for the payment flow, please indicate how.
Flags: needinfo?(pdolanjski)
Keywords: productwanted
Flags: needinfo?(dbialer)
Flags: needinfo?(msandberg)
Flags: needinfo?(jcarpenter)
Is there any quick fix to send an SMS and return the flow to the payment provider? Just to clarify, the *current* Send SMS button is simply a link using the sms protocol. All it does is link to sms:[shortcode]?body=[body]
Keep in mind that when the user loads the payment flow on the cellular network (a data connection) they will not need to send an SMS. The phone can be identified via enriched operator headers. As a workaround we could use the Mobile Connection API to tell the user "you need to turn on the cell network to set up carrier billing"
(In reply to Kumar McMillan [:kumar] from comment #7)
> Is there any quick fix to send an SMS and return the flow to the payment
> provider? Just to clarify, the *current* Send SMS button is simply a link
> using the sms protocol. All it does is link to sms:[shortcode]?body=[body]

I'm guessing doing that link is probably invoking the SMS web activity.

(In reply to Kumar McMillan [:kumar] from comment #8)
> Keep in mind that when the user loads the payment flow on the cellular
> network (a data connection) they will not need to send an SMS. The phone can
> be identified via enriched operator headers. As a workaround we could use
> the Mobile Connection API to tell the user "you need to turn on the cell
> network to set up carrier billing"

Does web content even have access to that API? I'm not sure...
(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Kumar McMillan [:kumar] from comment #7)
> > Is there any quick fix to send an SMS and return the flow to the payment
> > provider? Just to clarify, the *current* Send SMS button is simply a link
> > using the sms protocol. All it does is link to sms:[shortcode]?body=[body]
> 
> I'm guessing doing that link is probably invoking the SMS web activity.
> 
> (In reply to Kumar McMillan [:kumar] from comment #8)
> > Keep in mind that when the user loads the payment flow on the cellular
> > network (a data connection) they will not need to send an SMS. The phone can
> > be identified via enriched operator headers. As a workaround we could use
> > the Mobile Connection API to tell the user "you need to turn on the cell
> > network to set up carrier billing"
> 
> Does web content even have access to that API? I'm not sure...

Just checked - web content does not have access to that API. Only certified apps can access that API.
There was an alternative SMS path that had originally been suggested.  "User SMS MT identified, payment on bill"
User enters phone number in trusted UI
Bango sends a PIN code via SMS (user switchs to SMS to retrieve the code, and switchs back to trusted UI)
User enters code
Payment provider verifies and then presents purchasing screens.

I am not sure this solves the same issue, but is a different implementation, which, I don't believe would cause any Gaia changes or require privileges.
Flags: needinfo?(dbialer)
(In reply to David Bialer [:dbialer] from comment #11)
> There was an alternative SMS path that had originally been suggested.  "User
> SMS MT identified, payment on bill"
> User enters phone number in trusted UI
> Bango sends a PIN code via SMS (user switchs to SMS to retrieve the code,
> and switchs back to trusted UI)
> User enters code
> Payment provider verifies and then presents purchasing screens.

This sounds like a poor experience for the user in the sense that they don't get to set their own pin. There is a very high probability they will forget the PIN and need to reset it the next time the purchase something - effectively pushing this problem to the workload of the user. 

My suggestion is that we do push for an inline activity, this flow is bad enough already and at this point every little thing counts. As jsmith pointed out, it will bring the success rate of the payment flow significantly which directly contradicts the goals that Rick has specified for apps in 2013.
Flags: needinfo?(msandberg)
This bug is totally going to start trouble in triage, but here goes nothing.

Product needs to make the call here.
blocking-b2g: --- → tef?
(In reply to Maria Sandberg [:mushi] from comment #12)
> (In reply to David Bialer [:dbialer] from comment #11)
> > There was an alternative SMS path that had originally been suggested.  "User
> > SMS MT identified, payment on bill"
> > User enters phone number in trusted UI
> > Bango sends a PIN code via SMS (user switchs to SMS to retrieve the code,
> > and switchs back to trusted UI)
> > User enters code
> > Payment provider verifies and then presents purchasing screens.
> 
> This sounds like a poor experience for the user in the sense that they don't
> get to set their own pin. There is a very high probability they will forget
> the PIN and need to reset it the next time the purchase something -
> effectively pushing this problem to the workload of the user. 
This isn't about setting a PIN, it is about getting a code to send back to reply back to the SMS you receive to authenticate.
> 
> My suggestion is that we do push for an inline activity, this flow is bad
> enough already and at this point every little thing counts. As jsmith
> pointed out, it will bring the success rate of the payment flow
> significantly which directly contradicts the goals that Rick has specified
> for apps in 2013.
I believe the TrustedUI was designed for MT flow as described above.
I will consult with peter and loop in the necessary people.
(In reply to Jason Smith [:jsmith] from comment #6)
> Product Wanted & UX input needed.
> 
> So, it's end game right now, so trying to implement a new feature to solve a
> problem we didn't think about in the payment flow puts us at high risk for
> missing the "10 day" deadline Andreas has mentioned.

FWIW we thought about this. However, if I recall correctly, it was decided that we would only be supporting the SMS MT flow described in comment 11.
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #15)
> FWIW we thought about this. However, if I recall correctly, it was decided
> that we would only be supporting the SMS MT flow described in comment 11.

I meant for v1

(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Kumar McMillan [:kumar] from comment #7)
> > Is there any quick fix to send an SMS and return the flow to the payment
> > provider? Just to clarify, the *current* Send SMS button is simply a link
> > using the sms protocol. All it does is link to sms:[shortcode]?body=[body]
> 
> I'm guessing doing that link is probably invoking the SMS web activity.
>

I can confirm that:

1) https://mxr.mozilla.org/mozilla-central/source/b2g/components/SmsProtocolHandler.js#47
2) https://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#301
3) https://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#535
David over email has claimed this won't block v1 as it's too late to get in even though it's a poor UX. We are going to have figure out another approach for v1.

However it's strongly suggested we get this done in v1.1. leo?
blocking-b2g: tef? → leo?
Flags: needinfo?(pdolanjski)
Flags: needinfo?(jcarpenter)
Summary: Switching between TrustedUI, SMS app and marketplace app → Add support for a SMS inline activity to allow switching between the trusted UI within marketplace and the SMS app for the payment SMS challenge user flow
Just to clarify this, I believe this case should only happen when the user is purchasing for the first time and is on a WiFi network so that the payment provider is not able to authenticate the user's phone number via the network.

That said, even if where the user is forced to exit the marketplace, the authentication should still occur.  While a pretty poor user experience that we should try to fix in this release, I think we can figure out some workarounds if necessary by giving the user a message telling them that they will leave and need to return.
Momentarily leaving aside the alternative approach cited by David, implementing an inline activity for Messages seems like the best approach here. That activity should also allow us to prefill the recipient and message fields, as the existing window activity already seems to.

(In reply to David Bialer [:dbialer] from comment #11)
> There was an alternative SMS path that had originally been suggested.  "User
> SMS MT identified, payment on bill"
> User enters phone number in trusted UI
> Bango sends a PIN code via SMS (user switchs to SMS to retrieve the code,
> and switchs back to trusted UI)
> User enters code
> Payment provider verifies and then presents purchasing screens.
> 
> I am not sure this solves the same issue, but is a different implementation,
> which, I don't believe would cause any Gaia changes or require privileges.

Why did this approach fall by the wayside in the first place? The nice thing about it was it enabled the user to view the incoming PIN from the SMS notification at the top of the screen without having to leave the Trusted UI at all.
Adding the "v2" whiteboard tag, which we're using as a generic catch all for future version feature tracking.
Whiteboard: interaction, v2
> Why did this approach fall by the wayside in the first place? The nice thing
> about it was it enabled the user to view the incoming PIN from the SMS
> notification at the top of the screen without having to leave the Trusted UI
> at all.

It hasn't - we can just make some config changes to enable (we'll make this change on the test platform), this approach has some issues: 

1 - there is a charge to send an SMS to the user
2 - requires "shortcode" to be purchased (we use "22646" in the US) for each region
3 - doesn't solve the problem (user exits the marketplace, and is not automatically returned)


Is there anyway you could make a GET request to our ID service using the devices carrier connection (even if the user is on wifi)?
do we know how many users will be dropped out of the 1st time payment flow as a result of this bug? my understanding from user research early on this project was 1 in every 5 in the Lat Am region.
Flags: needinfo?(dbialer)
We believe it is not a corner case.  Possibly around 40% will not complete authentication was discussed.

This is the proposed fix:
after the use sends the SMS, a confirmation SMS is sent that says something like "you are authenticated - complete your purchase now" with a link to click that will open the marketplace back up to the trustedUI screen to buy.

Kumar is investigating this path to see if we can do that.

Steve will summarize.
Flags: needinfo?(dbialer)
(In reply to David Bialer [:dbialer] from comment #24)
> We believe it is not a corner case.  Possibly around 40% will not complete
> authentication was discussed.
> 
> This is the proposed fix:
> after the use sends the SMS, a confirmation SMS is sent that says something
> like "you are authenticated - complete your purchase now" with a link to
> click that will open the marketplace back up to the trustedUI screen to buy.
> 
> Kumar is investigating this path to see if we can do that.
> 
> Steve will summarize.

Hmm...apparently the link approach doesn't work either :(. Which is surprising, cause I thought that was going to work.

I just tested this by sending a SMS to my phone with https://marketplace.firefox.com and https://www.google.com. Both are not clickable links.
This appears to be a bug 832829 in Gaia?
I think SMS'ing a link is a no-go. Even despite not rendering HTML (this might be fixable with SMS content types) jsmith and I couldn't think of a way to make the SMS app open the Marketplace (or third party app) without changing client code and / or manifests for new permissions, web activities, etc.

Since the constraint for V1 is strictly no client changes, the best thing I can think of is to simply reply with an informative text. Keir, could we do that? Something like :

"You are almost finished. Press the home button and switch back to <App Name> to complete your purchase."

To populate App Name we could use a new option in the Billing Config API call.
(In reply to David Bialer [:dbialer] from comment #26)
> This appears to be a bug 832829 in Gaia?

That's actually a dupe. The original bug is bug 796788.
(In reply to Josh Carpenter [:jcarpenter] from comment #20)
> Momentarily leaving aside the alternative approach cited by David,
> implementing an inline activity for Messages seems like the best approach
> here. That activity should also allow us to prefill the recipient and
> message fields, as the existing window activity already seems to.
> 

If we are talking about a v2 feature, then IMHO the silent SMS option would provide a way better UX than the inline activity for Messages. But that requires further analysis and significant platform work.

(In reply to Keir Kettle from comment #22)
> 3 - doesn't solve the problem (user exits the marketplace, and is not
> automatically returned)
> 

If the short code is shown in the notification bar, the user does not need to leave the marketplace.
 
> Is there anyway you could make a GET request to our ID service using the
> devices carrier connection (even if the user is on wifi)?

AFAIK with the current implementation it is not possible. But it might be possible in future versions as we could inject a function in the payment provider flow to switch the connection from WiFi to 3G. This would also require some platform work though.
team - product (david), UX (maria) and dev (kumar) for payments met today.

in order to eliminate impact to v1.0 - we recommend the marketplace payments team work with bango to deliver the alternate solution described below (MT verification)

i think this bug can be closed out as "won't fix" and david bialer can bring forward any requirements for future versions.

expected behavior:
1. Launch marketplace-dev app on your unagi phone
2. Log in to Identity
3. Search for the paid app 'private yacht'
4. Click on the purchase button
5. Create your Payments PIN
6. When prompted, enter your phone number into the payments flow
7. See message in payments flow that a " confirmation is being sent via SMS and you will be asked to re-enter the code [ here ] "
8. See confirmation code in SMS on top of the screen without leaving trusted UI
8b. if user misses the SMS text, then they leave marketplace payments, go to sms app
8c. get confirmation code, re-open marketplace app, see trusted UI and payments flow
9. enter confirmation code into payments flow and proceed with payment process

benefits:
- user is not dropped out of flow
- user is not billed for SMS text out from phone
- this should not have impact on device

Kumar, David, Maria - Did I miss anything?
Yep, this is the new behavior we're requesting. I opened the payments screen on my b2g phone and sent a text to it from another phone. I could clearly read the word in the body of the text as it flashed on the screen. When I pulled down the notification drawer I could also read the word without switching to the SMS app. Thus, we think this flow will have a better chance at not losing the user entirely. It requires more typing but at no point would the user be lost.
(In reply to Kumar McMillan [:kumar] from comment #31)
> Yep, this is the new behavior we're requesting. I opened the payments screen
> on my b2g phone and sent a text to it from another phone. I could clearly
> read the word in the body of the text as it flashed on the screen. When I
> pulled down the notification drawer I could also read the word without
> switching to the SMS app. Thus, we think this flow will have a better chance
> at not losing the user entirely. It requires more typing but at no point
> would the user be lost.

True, but there's privacy implications of that approach. The payment flow is asking for a phone number and handing off to the payment provider. How can a user trust the fact that the payment provider isn't going to do something unintentional with that phone number? Such as spam them with text messages?
We can close this though. My comment is more of a side comment. Might not be an issue, but may be worth checking out.
Status: NEW → RESOLVED
blocking-b2g: leo? → ---
Closed: 11 years ago
tracking-b2g18: ? → ---
Resolution: --- → WONTFIX
I also think SMS MT is the best option for the time being. So let's stick to that (as already talked several weeks before)

Just one comment: we still need to define for how long we will establish a cookie to remember the SMS-based authentication and don't repeat the process for each payment over wifi. This conversation is still pending.
(In reply to David Lozano from comment #34)
> Just one comment: we still need to define for how long we will establish a
> cookie to remember the SMS-based authentication and don't repeat the process
> for each payment over wifi. This conversation is still pending.

Carriers tend to have a view on this, so its configurable on this basis, current default is 360 days(!), should probably be ~30 days.
On our call today, Bango mentioned that they're working on the new MT flow right now. I created bug 834257 to track it.
You need to log in before you can comment on or make changes to this bug.