|
|
| Line 311: |
Line 311: |
|
| |
|
| = Payment Provider facing API = | | = Payment Provider facing API = |
| The native implementation injects two callbacks as global functions within the payment provider flow.
| |
| <code>
| |
| function paymentSuccess(aResult);
| |
|
| |
| function paymentFailed(aErrorMsg);
| |
| </code>
| |
|
| |
|
| where <code>aResult</code> and <code>aErrorMsg</code> are simple strings.
| | See the [[WebAPI/WebPaymentProvider|WebPaymentProvider]] spec for details on how to implement a payment provider for <code>navigator.mozPay()</code>. |
| | |
| These functions should be called by the payment provider to finish the payment flow. Both functions would close the payment flow window and trigger the [https://developer.mozilla.org/en-US/docs/DOM/DOMRequest.onsuccess onsuccess] or [https://developer.mozilla.org/en-US/docs/DOM/DOMRequest.onerror onerror] events over the [https://developer.mozilla.org/en-US/docs/DOM/DOMRequest DOMRequest] returned by the <code>navigator.mozPay</code> call. The <code>aResult</code> and <code>aErrorMsg</code> strings passed by the payment provider would be available for the application as [https://developer.mozilla.org/en-US/docs/DOM/DOMRequest.result DOMRequest.result] and [https://developer.mozilla.org/en-US/docs/DOM/DOMRequest.error DOMRequest.error] values respectively. For more details about the specific error codes returned by the BlueVia Payment Provider go to
| |
| | |
| In the next future we would probably want to expose more functionality, so the Payment Provider can have a better control and a better communication mechanism with the platform. Function for hiding and showing the payment flow or for requesting data to the system application would be really useful.
| |
|
| |
|
| == BlueVia Payment Provider == | | == BlueVia Payment Provider == |