Confirmed users
483
edits
WebAPI/WebPayment: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 95: | Line 95: | ||
Here is a detailed explanation of the in-app payment JWT: | Here is a detailed explanation of the in-app payment JWT: | ||
;iss: | **'''iss''': The issuer of the JWT. This is the application key assigned during the app registration process for this specific payment provider (BlueVia). | ||
**'''typ''': The JWT type (identifies the payment provider, BlueVia, and the JWT version that must be supported by the provider). | |||
**'''iat''': Issued at time. This is a UTC Unix timestamp of when the JWT was issued. | |||
**'''exp''': Expiration. A UTC Unix timestamp of when the JWT should expire. | |||
**'''request''': Request object. | |||
*** '''price''': This is the price of the purchased product. | |||
*** '''currency''': This is the currency code for the price. | |||
*** '''name''': A short description of the product. | |||
*** '''description''': A long description of the product. | |||
*** '''productdata''': A freeform string, no longer than 255 characters. This can be anything the app might need to identify the product with when a postback is sent back to the app. | |||
*** '''postbackURL''': URL where the payment processor sends an HTTP POST message to whenever a purchase completes. The application server needs to acknowledge these POST messages, or else the transactions will be canceled. If the payment processor stores a different postback URL, this one should override the stored one. This way, application developer could choose different endpoints for different kind of digital goods. | |||
*** '''chargebackURL''': URL where the payment processor sends an HTTP POST message to whenever a refund associated with this transaction is done. If the payment processor stores a different chargeback URL for this application, the one within the JWT should override the stored one. | |||
* For a user to make a purchase, the app must execute the Javascript method <code>navigator.pay()</code> with this signed payment request. For example, the app might have a 'buy' button that triggers this method when clicked. Then <code>navigator.pay</code> method should take the signed payment JWT or an array of them. As a result of this call a [https://developer.mozilla.org/en/DOM/DOMRequest DOMRequest] object would be returned. The developer may use this DOMRequest object to monitor the progress of the operation. | |||
<code> | |||
let request = navigator.pay([signedJWT1, signedJWTn]); | |||
request.onsuccess = function () { | |||
[...] | |||
} | |||
request.onerror = function () { | |||
[...] | |||
} | |||
</code> | |||
* The <code>navigator.pay</code> method must open a Payment Provider selection screen based on the received JWTs, so the user can choose the payment method that is more appropriate for him. B2G would only show the payment providers for the JWT '''typ''' values that are pre-registered in the UA. JWTs containing a '''typ''' value not registered in the UA would be considered as invalid. | |||
* Once the user selects a Payment Provider the UA must open a trusted dialog ("chrome" dialog) containing the Payment Provider's buy flow that is registered in the UA for the '''typ''' value of the passed JWT (TU ID Connect in case of BlueVia). | |||
* User authentication can be done via network authentication (MSISDN) or BrowserID assertion. Authorization could also be done with user password or PIN code sent via SMS. | |||
* The purchase is presented to the user for confirmation, with name, description and identifying information from TU ID Connect about the seller. | |||
* The user confirms the purchase or cancels it. | |||
* If the user cancels, the flow returns to the <code>DOMRequest.onerror</code> callback. | |||
* If the user confirms, the Payment Provider should send a POST confirmation message (a JWT) to the postback URL of the seller provided within the JWT request. The postback URL is optional, but strongly recommended. The Payment Processor (also via Mozilla Marketplace) could optionally store a default postback URL as part of his application sign-up process. If a different postback URL is provided within the JWT request, this one would override the default one stored as default in the Payment Provider. This confirmation message contains all the payment request fields plus a transaction identifier, and is signed with the seller's application secret. | |||
<code> | |||
{ | |||
iss : sellerIdentifier, | |||
typ : "tu.com/payments/inapp/v1”, | |||
exp : int(time.time() + 3600), | |||
iat : int(time.time()), | |||
request : { | |||
name : "Piece of Cake", | |||
description : "Virtual chocolate cake to fill your virtual tummy", | |||
price : "10.50", | |||
currencyCode : "USD", | |||
productData => "my_product_id=123" | |||
postbackURL => “http://developerserver.com/postback”, | |||
chargebackURL => “http://developerserver.com/chargeback” | |||
} | |||
response: { | |||
transactionID: "123456123456123456" | |||
} | |||
} | |||
</code> | |||
* To verify that the purchase is valid, the application server first needs to decode the JWT in the POST. If the purchase is valid, then the application server should record it and respond with a 200 OK that contains the order ID. The transaction should be canceled by the Payment Provider if the server take longer than x seconds to send a 200 OK response. | |||