WebAPI/WebPayment: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 152: Line 152:


[[File:WebPaymentAppPaymentFlow.png|600px|thumb|center|Buy flow]]
[[File:WebPaymentAppPaymentFlow.png|600px|thumb|center|Buy flow]]
=== Marketplace payment ===
=== Marketplace payment ===
''(This is just a proposal and not the current Marketplace scenario)''
The Mozilla Marketplace use <code>navigator.pay</code> to execute purchase transactions for apps. The only difference to in-app payments is that the Marketplace use the app as the issuer (recipient of funds), instead of itself.
Once the user starts an application purchase process, the marketplace generates a payment request that contains all the information about the application being purchased: price, currency, name, description and so on, with the addition of the '''application key''' that identifies the '''developer''' as issuer of the transaction (recipient of funds) and the marketplace '''postback''' and '''chargeback''' URLs, so the '''Marketplace''' could receive notifications about the transaction result or refunds associated with the transaction. The marketplace signs the payment request with the application secret.
<code>
  {
    iss : sellerIdentifier,
    typ : "tu.com/payments/inapp/v1”,
    exp : int(time.time() + 3600),
    iat : int(time.time()),
    request : {
      name : "Demo app",
      description : "Demo app",
      price : "0.99”,,
      currencyCode : "USD",
      postbackURL: “marketplace.mozilla.org/postback”,
      chargebackURL: “marketplace.mozilla.org/chargeback”,
      productData => "my_product_id=123"
    }
  }
</code>
The buy flow is the same as the in-app payments case for the payment processor's side. As mentioned before, the difference to in-app payments requests is that a marketplace request must contain a postback url in order to notify the market about the successful transaction. This postback and chargeback URLs should prevail over the postback url stored for the application key, so notifications should be received by the marketplace instead of the developer. Once the marketplace receives the details of the transaction it should unlock the application installation, and it could optionally notify the developer about it via the registered postback url for the application.
=== Refunds ===
Refunds depend on the technical capabilities of the payment provider. If technically feasible, the UA should direct users to a Payment Provider-hosted refund page (trusted dialog launched from the settings area) that lists the most recent purchases and allows to cancel them. Authentication occurs via MSISDN or BrowserId as for payments.
==== Marketplace refunds ====
The Marketplace must keep a list of transactions allowing the user to cancel the latest transactions. Applications should be uninstalled from the user's device after canceling the associated transaction. A chargeback notification will be sent to the developer.
==== Refunds for in-app purchases ====
The payment processor (BlueVia) will keep a list of transactions accessible via user profile, allowing the user to cancel the latest ones. A chargeback notification should be sent to the developer once a refund is requested. The way the developer handles the chargeback notification would depend on the nature of the sold digital good and it is developer's responsibility to cancel or remove it properly from the user's device.
== Online payments from other networks ==
Users can pay over wifi connections if the Payment Provider integrates with BrowserID or a SMS verification flow is provided. In this case, payments actually can occur via other devices and the same BrowserID (e.g. by a user logged into a desktop browser with the same identity that is tied to a carrier account).
== Developer control ==
The Payment Provider can expose an API to share aggregated transaction info with the Marketplace to allow developers to keep track of app sales from within the Marketplace. The Marketplace can aggregate this information from all the Payment Providers the developer signed up for for the particular app.
== See also ==
https://docs.google.com/document/d/1NLKbHVPQXa9uvDBC3cfgOD7sIrtIxi0qDoXMQrxcCsI/edit
Confirmed users
483

edits

Navigation menu