PushPayments

This page is for observations about how to manage push payments by payment handlers. This page was prompted by discussion around issue 27, billing address collection from payment handlers.

Problem Statement

Once a user selects a payment handler and the browser launches it, there is no further communication (or at least not in general) from the merchant or browser to the payment handler. When the user completes interaction with the payment handler, the payment handler returns data to the browser. For some payment methods (e.g., credit cards) where the payment handler does not initiate payment, this is not a problem. The merchant can receive data in the payment response and request corrections of the user through retry().

However, if the payment handler initiates payment based on insufficient information exchange with the merchant, this can create problems. Here are scenarios that illustrate potential problems:

• The payment handler is the authoritative source of billing address. The total from the merchant depends on billing address (e.g., VAT) and thus the total received by the payment handler is wrong. Payment occurs before it can be corrected by the merchant.
• The user engages in some other activity in the payment handler (e.g., reaching agreement on the terms of a real-time loan) based on information from the merchant, but that information needs to be changed based on the user's interaction with the payment handler (e.g., the billing address affects the total, and the loan depends on the total.)

Approaches for addressing this issue

WG participants have suggested multiple ways to address this issue. Some of these approaches may not be mutually exclusive. This document is only meant to summarize ideas, not analyze or endorse them.

Establish definitive information before launching the payment handler

For example, prompt the user to enter a definitive billing address before being allowed to select a third party payment handler.

Enable the payment handler to communicate with the merchant (via the browser)

In this flow, the payment handler can request updated information when necessary, and only initiate payment once satisfied with the information.

Example flow:

• The user has not yet selected a billing address.
• The user selects a payment handler.
• Within the payment handler, the user selects a payment instrument with associated billing address.
• The payment handler informs the browser that the user has selected a billing address. The payment handler waits for a response (read: promise to resolve) that may update the total. The payment handler will not complete the transaction until hearing back from the merchant.
• The browser fires the onpaymentmethodchange event to let the merchant know the billing address has changed.
• The merchant responds with a (possibly null) update of the total.
• The browser gives the (possibly updated) total back to the payment handler.
• The payment handler displays the total and allows the user to proceed.

Enable the payment handle to communicate with the merchant (via a merchant server)

• I don't think we've discussed this option but it's conceivable the payment handler could communicate directly with a merchant server.

Merchant initiates payment on the backend given data from payment handler

In this approach, a step is added between the user pushing "Ok" in the payment handler and initiation of the payment: the merchant receives data, analyzes it, and, if satisfied, forwards it to a service (e.g., identified by a URL) where payment initiation happens. If the merchant is not satisfied, they can use the retry() method.

Adrian Hope-Bailie describes this scenario in issue 759 from AdrianHB.

Payment handler initiates payment after confirmation by merchant

In this approach, a step is added between the user pushing "Ok" in the payment handler and initiation of the payment: the merchant receives data, analyzes it, and, if satisfied, returns a confirmation to the payment handler, which then proceeds with the payment. If the merchant is not satisfied, they can request to abort() the payment handler and then retry().