Confirmed users
483
edits
WebAPI/WebPayment: Difference between revisions
→In-app payment
m (→In-app payment) |
|||
| Line 132: | Line 132: | ||
} | } | ||
</code> | </code> | ||
* The <code>navigator.mozPay</code> method must open a | * The <code>navigator.mozPay</code> method must open a payment request confirmation screen based on the received JWTs, so the user can confirm and 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). | * 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. | * 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 authorization mechanisms is reponsibility of the Payment Provider and it is beyond the scope of this document. | ||
* The purchase is presented to the user for confirmation, with name, description and identifying information from TU ID Connect about the seller. | * 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. | * 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 cancels or something goes wrong with the payment process, 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. In the following example, the ''transactionID'' field is specific to the BlueVia payment provider. | * 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 (for the '''price''' case, only the selected value is returned) plus a transaction identifier, and is signed with the seller's application secret. In the following example, the ''transactionID'' field is specific to the BlueVia payment provider. | ||
<code> | <code> | ||
| Line 166: | Line 166: | ||
</code> | </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. | * To verify that the purchase is valid, the application server first needs to decode and verify 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. | ||
<span style="color:#800000">The JWT format and callbacks above are compatible with Google's in-app payment system, as well as Mozilla's paypal-based in-app payment flow.</span> | <span style="color:#800000">The JWT format and callbacks above are compatible with Google's in-app payment system, as well as Mozilla's paypal-based in-app payment flow.</span> | ||