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

When a user selects a payment handler, there is no further communication (or at least not in general) from the merchant or browser to the payment handler. 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. Scenarios include:

• 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.

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 handle 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:

• 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.

Do not initiate push payments in payment handlers

In the scenario described in issue 759 from AdrianHB, payment handlers do not initiate payments. They return information to the merchant either to initiate the payment when satisfied, or request updates from the user (through the payment handler).