WebAPI/Direct Billing: Difference between revisions

no edit summary
No edit summary
 
(13 intermediate revisions by one other user not shown)
Line 2: Line 2:


Web API to charge payments to a customer's operator bill more easily.
Web API to charge payments to a customer's operator bill more easily.
== Proposers ==
Kumar McMillan, Jonas Sicking


== Status ==
== Status ==


This is a '''draft''' of a proposal. Nothing has been implemented yet.
This is a '''draft''' of a proposal. Nothing has been implemented yet.
'''NOTE''': also see the [https://wiki.mozilla.org/WebAPI/MobileIdentity Mobile Identity API] and [https://bugzilla.mozilla.org/show_bug.cgi?id=988469 MSISDN Verification API].


== High Level Use Case ==
== High Level Use Case ==


A user is playing an adventure game on a mobile device. The game offers a Magical Unicorn for 0,89 EUR that lets them play the game in a more majestic way. The user begins payment but does not want to enter a credit card number. The user wants to tap a button that will charge their operator bill instantly and let them continue playing the game.
A user is playing an adventure game on a mobile device. The game offers a Magical Unicorn for 0,89 EUR that lets them play the game in a more majestic way. The user begins payment but does not want to enter a credit card number. The user wants to tap a button that will charge their operator bill instantly and let them continue playing the game. The setup and payment flow should be as quick and seamless as possible.


== Rationale ==
== Rationale ==


We have [[WebAPI/WebPayment|navigator.mozPay()]] and an associated [[WebAPI/WebPaymentProvider|WebPaymentProvider API]] for direct billing but they require implementers to follow a string, end-to-end JSON Web Token based flow. This alternate API will expose just the direct billing primitives needed. It will not prescribe how to use them.
We have [[WebAPI/WebPayment|navigator.mozPay()]] and an associated [[WebAPI/WebPaymentProvider|WebPaymentProvider API]] for direct billing but they require implementers to follow a strict end-to-end JSON Web Token flow. This alternate API will expose just the direct billing primitives needed. It will not prescribe how to use them.


== Access Control ==
== Access Control ==


Because there are too many sensitive APIs in here, only trusted web content can access this API. Access will be whitelisted by domain. No other web content will have access to this API.
Because there are too many sensitive APIs in here, only trusted web content can access this API. Access will be whitelisted by domain. No other web content will have access to this API. '''TBD''': do we need to require a new window for that to work?
 
When thinking of a way to allow open access to these APIs, these are some problems we ran into:
* Arbitrary web content cannot a send silent SMS because it could charge users money
* If we whitelist short codes (which are free of charge) per operator/region then there is potential for abuse: web content could maliciously hit a short code which would cost the payment provider money
* mcc/mnc expose the user's location and network which is a privacy concern
* iccIDs can be used for fingerprinting
* It may not be possible to prompt the user to grant access in a meaningful way
* Standard app permissions do not apply because payments is a service offered to the users of apps. The app itself is not the one that needs permission.


== API ==
== API ==
Line 26: Line 40:
     * Send an [http://en.wikipedia.org/wiki/Short_Message_Service MO (mobile originated) SMS] without storing it on the device's SMS database or requesting delivery status.
     * Send an [http://en.wikipedia.org/wiki/Short_Message_Service MO (mobile originated) SMS] without storing it on the device's SMS database or requesting delivery status.
     * The SMS will not show any notifications and will not appear in any SMS application consuming the [https://wiki.mozilla.org/WebAPI/WebSMS WebSMS API].
     * The SMS will not show any notifications and will not appear in any SMS application consuming the [https://wiki.mozilla.org/WebAPI/WebSMS WebSMS API].
    * The number must be a short code that does not charge the user.
     */
     */
   DOMRequest sendSilentSms(in DOMString number, in DOMString message);
   DOMRequest sendSilentSms(in DOMString number, in DOMString message);
Line 31: Line 46:
   /**
   /**
     * Intercept any incoming MT (mobile terminated) SMS sent from the given number.
     * Intercept any incoming MT (mobile terminated) SMS sent from the given number.
    * The number must be a short code that does not charge the user.
     */
     */
   void observeSilentSms(in DOMString number, in jsval callback);
   void observeSilentSms(in DOMString number, in jsval callback);
Line 78: Line 94:


In order to show the user a correct price for their region, the payment provider can use the '''mcc''' and '''mnc''' codes. These codes can also be used to enable/disable specific regions when payments are not supported or still in development.
In order to show the user a correct price for their region, the payment provider can use the '''mcc''' and '''mnc''' codes. These codes can also be used to enable/disable specific regions when payments are not supported or still in development.
[[Category:Web APIs]]
Confirmed users
1,340

edits