WebAPI/WebPayment/Multi-SIM

From MozillaWiki
Jump to: navigation, search

Background information

See the WebPaymentProvider for how one would access multi-SIM data.

Payment User Stories

1. As a User when I am on a data network and am purchasing an app I would like to be offered the option to pay for my purchase with the operator that I am currently using for my data if that operator supports payments, otherwise I should be offered an option to pay with my credit card.

  • if I have not previosly made a purchase with that SIM before with my existing Persona account my device should be authenticated before any payment is charged to my account.
  • if I have made a purchase previously with that operator from the Marketplace with that exact SIM, the payment system should recognize that and I should be automatically authenticated.

2. As a User, if I am in flight mode and do not have a current data network (BUT WIFI!), when I use Marketplace I would like to be offered the option to pay for my purchase with the operator that I have set for my data network (even if not in use) if my operator supports payments, otherwise I should be offered an option to pay with my credit card.

  • if I have not previously made a purchase with that SIM before with my existing Persona account my device should be authenticated before any payment is charged to my account.
  • if I have made a purchase previously with that operator from the Marketplace with that exact SIM, the payment system should recognize that and I should be automatically authenticated.

3. As a User I would like to understand that my data network operator that I am currently using with Marketplace will also be used for my payments. (There is also a confirmation screen for this - so users are not billed without knowing this is happening)

4. As a User, if I switch the choice of my data network SIM in my phone since my last purchase of an app, when I purchase an app, I should be able to purchase an app on the new data network SIM if my operator supports operator billing.

Firefox OS v1.3

For v1.3 bug 936471 was filed and fixed to mend the regression caused by the DSDS feature.

Single-SIM scenario

Payments should work ok in a single-SIM scenario, even with DSDS support in the platform.

Multi-SIM scenario

There is currently no plans for shipping any multi-SIM commercial device, but in that remote case, we might have some issues. The current situation after bug 936471 is:

  • We are exposing the iccID/mcc/mnc information *only* for the SIM located in slot[0].
  • This solved the immediate regression for single-SIM but didn't solve the problem for multi-SIM.
  • With this model in a multi-SIM, use cases like the following won't work:
    • The SIM at slot[0] is valid for carrier billing.
    • The SIM at slot[1] is the primary SIM for SMS.
    • The user starts her first payment. The payment provider gets the information from the SIM at slot[0] and starts the silent SMS flow.
    • The SIM at slot[1] will be used for the silent SMS flow, since it is the primary SIM for SMS.
    • Result: we will be authenticating the wrong SIM :(

The UX might also be confusing in this case:

  • slot[0]: not valid SIM for payments
  • slot[1]: valid SIM for payments, but unknown for the payment provider.
  • The payment provider does not even know that the device has multiple SIMs, so I guess that we would silently skip the carrier billing step. But the user knows that she has a valid carrier billing SIM inserted on the device. She will need to try luck and change the slots for the SIMs with any pointers or recommendations from our side.

Firefox OS v1.4

In order to have a full support for multi-SIM payments where:

  • The user is always aware about which one of her SIMs is used for payments if the SIM is in the device.
  • We always authenticate the correct SIM that is used for payments.
  • We know when to remove the payment session to trigger a new authentication flow.

the proposal is the following:

  • We will expose to the payment provider the serviceId associated with the SIM selected for payments via mozPaymentProvider.paymentServiceId. It can be the primary SIM for data by default, it doesn't really matter.
  • We will expose to the payment provider the whole list of ICCID/MCC/MNC for all the SIMs in the device indexed by serviceId, indicating which one is the primary one for data. We will remove the .iccIds, .mcc and .mnc properties and will introduce a new .iccInfo property of this form:
    • {'serviceId1': { iccId: '1234', mcc: '222', mnc: '333', dataPrimary: false }, 'serviceIdN': { iccId: '5678', mcc: '222', mnc: '333', dataPrimary: true }}
  • If there is a record of a previous payment (I guess, a payment cookie), the payment provider will need to check that nothing changed wrt to the SIM selected for payments. Otherwise, a new authentication flow needs to be triggered.
  • If there is no record of a previous payment, a new authentication flow needs to be triggered. The payment provider will need to process the list containing the services information in order to set the correct SIM for payments. The decision algorithm could be something like this.
    • Once the payment provider selects the appropriate SIM it will set the serviceId associated with this SIM via mozPaymentProvider.paymentServiceId.
    • Note that in case that the (not silent) SMS flow is required, we will need to ask the user for her MSISDN and this could be an MSISDN from an external SIM. In this case, the payment provider will set the service ID to null and will need to call mozPaymentProvider.observeSilentSms(number). If the SMS is received in the device, we can set the serviceId of the receiving SIM as the one selected for payments.
  • If there is a record of a previous payment and the payment serviceId is null, it means that the payment was done with an external SIM and so we need to allow the user to remove the payment session to retrigger the authentication flow with another SIM.
  • The selected SIM will be the one used for the silent SMS flow if needed and the one shown in settings as primary for payments, if we decide to show this information.

Bug 938993 will track the client side changes required for this and Bug 942361 the payment provider changes.