These notes reflect discussion among Jason Normore, Andre Lyver, Rouslan Solomakhin, and Ian Jacobs about Web Payments WG issue 3, issue 4, issue 178, issue 29.

Design principles

• Keep the simple case of one total simple.
• Support the communication of data from the merchant, but allow the mediator and payment apps to manage display and user interaction.
• Allow merchants, payment methods, and payment apps to handle most currency issues.

Proposal

Changes to Payment Request API

• In addition to “total” in PaymentDetails, add [optional] “total” to PaymentMethodData.
• Add an event “PaymentMethodsChange” so that the merchant can update the payment request based on user selection of payment method.
• Add a statement that the mediator MAY display different totals when displaying payment method information.
• Add a statement that the merchant SHOULD verify that the total in the payment response matches the merchant’s expectations.

Changes to (future) Payment App Spec

• Add a statement that the payment app MAY display different totals when displaying payment method information.

Leave Out of Scope ("for v1")

• API support for more than one total per payment method.
• Dynamic Currency Conversion (DCC).
  • See the Background below for more explanation on forms of currency conversion that can be done.

For discussion: This proposal does not include firing PaymentMethodsChange when the user changes payment method in a third party payment app. Is that necessary? Is it desirable? Is it possible?

User Experience on Payment Method Change

• As with Shipping Address, the idea of PaymentMethodsChange is to update the payment request. The proposal does not imply that the merchant receives notification of payment app selection, just payment method selection.
• Imagine different user experiences:
  • In the case where the user selects a payment app, we anticipate control being handed to the payment app and thus PaymentMethodsChange would not fire. The next paymentRequest API activity would involve the payment response.
  • In the case where the user instead selects (a payment instrument for) a given payment method directly --whether offered natively by the browser or via a third party payment app-- if the user's experience is to "immediately request authorization" upon selection of the instrument, then it does not make sense for PaymentMethodsChange to fire.
  • On the other hand, if the user's experience is to "select that payment instrument for additional interaction" then it does make sense for PaymentMethodsChange to fire (to update the total) before the user authorizes payment.

For discussion: What user experience do we anticipate or want to encourage regarding payment method/instrument selection? Should payment app registration (and updates) include the (optional) ability for the app to share information about specific instruments, which would enable the mediator to improve the user experience before handing control to the third party payment app?

Different ways to handle multicurrency

"Standard" Multiple Currency Options

The merchant operates separate merchant accounts for each currency. The list of currencies accepted by the merchant is limited based on the acquirer's ability to settle funds in these currencies. A user typically pre-selects a preferred currency (or, sometimes, country) before starting to shop, or shops (after redirection) on the merchant's country-specific site. The transaction is authorized in the user's preferred currency, and settlement happens in the same currency.

Multi-Currency Processing (MCP)

In this scenario, the merchant typically only needs one merchant account with a PSP in their preferred settlement currency, and is provided with a feed or API of exchange rates which they can use to convert all their prices so that customers can shop in the user's preferred currency. As in the "standard" case, the user can select a preferred currency (or country). Unlike the "standard" case, the supported currency list can now be much more extensive and complete, rather than limited to a handful of merchant settlement currencies. At checkout time, the user is authorized and charged in the user's preferred currency, but the funds settle in the merchant's account in the merchant's preferred currency.

Dynamic Currency Conversion (DCC)

With DCC, the currency conversion takes place a checkout time. The issuing bank/country of the cardholder is determined when the card number is provided. If the card currency differs from the merchant's preferred currency, the cardholder is presented with an option to pay in their native currency, or in the merchant's currency. In this situation, the price of the goods are converted from the merchant's settlement currency to the cardholder's native currency, with an fx markup that is typically shared between the merchant and the acquirer, and/or DCC provider.

Observations about Support for these Options

• The Payment Request API supports the Standard and MCP options, since the currency was already preselected by the user while browsing. The merchant creates the PaymentRequest with the total amount in that currency.
  
  • Furthermore, payment apps and merchants can engage in back-channel discussions to confirm currency options.
• DCC can be done by (third party) payment apps.
  • If we want to call this out, we should address the issue of which data appears in the payment response: the merchant's specified amount/currency, the converted amount/currency, or both? Given that the merchant may have a revenue share of the f/x, it can be assumed that there is already reporting in place between the merchant and the payment app for this, but for the sake of completeness, Payment Request should be able to include the details of the f/x that took place.
  • Note that if the merchant does not wish to support a converted currency, they can reject the payment response and relaunch dialog with the user.

For discussion: Should we call out in the future payment app spec that payment apps MAY do DCC, should we discourage it, or should we remain silent?