This issue comes from WICG/paymentrequest#19 and was discussed at the F2F.

two types of currency are used currently.
currency for merchant and
currency customer selected.

with DCC(Dynamic Currency Conversion) mechanism
merchant has product priced $100
and merchant add additional currencies by adding some margins.

merchant will offer multiple currencies and amount to customer.
when payment made with different currency than merchant's original currency

merchant will receive settlement amount based on their original currency
customer will pay different currency amount by customer's card issuer.
DCC vendor will share margins with Acquirer, merchant

The current wording of the draft also prevents the currency being specified as a non-fiat ISO 4217 currency. In other words, you couldn't be compliant with the specification and create a payment request in, for example, bitcoin or ripple. Is this a separate issue?

https://en.bitcoin.it/wiki/Bitcoin_symbol suggest XBT is the 'unofficial ISO4217' code, I suggest we explicitly call this out in our spec. The wiki pages referenced also calls out ETH for Ether.

In Chrome we want to allow all currencies in format "[A-Z]{3}" (three upper case ASCII letters). This allows for the proposed currency codes as well.

Should it be possible to provide amounts in more than one currency?

Let's restrict each payment request to a single currency code, until such time as merchants express their need for this feature.

-1, we at least need different methods to support different currency codes such that CryptoCurrencies can be supported alongside traditional currencies in a single paymentrequest.

Let's restrict each payment request to a single currency code, until such time as merchants express their need for this feature.

@rsolomakhin -1, we (Digital Bazaar) have a number of use cases where we need to be able to differentiate pricing based on currency (with merchants that accept payment in more than one currency, for example).

While it is true that we could generate one payment request for every type of currency, we see that approach as sub-optimal as we're going to be repeating all other data in the payment N times for every currency that is accepted.

I am concerned about the combinatorial effect of allowing multiple currencies, so perhaps we should start marking up some examples and see how complicated it gets. The worst case that I can see is accepting payment in multiple currencies across multiple payment instruments.

@mountielee I don't think this issue addresses DCC directly but it is a prerequisite for DCC. I agree that it will be impossible to offer DCC without this.

@mountainhippo, @mattsaxon, @rsolomakhin I have submitted PR (#101) to address this based on the WG's previous resolution in this regard

I am a firm +1 for allowing multiple prices to be included in a payment request. These may differ based on currency but I'd also like them to differ based on payment method (See #4). We need to look at the format of the input data to the payment request and consider how we might accommodate these requirements.

I'm increasingly thinking that there are sufficient possible dimensions with surcharges, differences between currencies etc that for some of these less-common cases, a call-back (event) to the merchant site to recalculate might be in order (as with the shipping details). Is this something anyone has explored/discarded?

@davidillsley yes, see #109

The challenge we have with doing this via the browser API is that the current events/callbacks system is intended to be an exchange between the website and the user agent before the request is passed to the payment app.

Once that is done there is no obvious way to continue exchanging data between them. Of course this may not be true if we define more specifically what a payment app IS but to date we have danced around this issue in a fairly uncomfortable way.

E.g. If a payment app on a mobile device is actually a separate app to the browser (which is itself an app) then we are severely limited in what is possible ito IPC between the apps. The support for this is very different across platforms and we're getting into a space we can't control.

It's becoming increasingly clear to me that we need to define a default web-based payment app behavior that all user agents MUST support and then allow them to innovate in how they support native apps.

It's becoming increasingly clear to me that we need to define a default web-based payment app behavior that all user agents MUST support and then allow them to innovate in how they support native apps.

+1 as my hope has always been that we do this first. The Web Payments Community Group's proposal did this as the minimum bar to ensure a level playing field wrt. payment apps.

PR #133 proposes a way to support this in the request.
How this is supported by the payment app is not in scope.

Please review the PR and if you are happy with the approach I will close this issue.

Apologies for coming late to this discussion.
For DCC transactions (mountielee summarises this well above), Visa and MasterCard have slightly varying requirements, but require the merchant to share the foreign exchange rate, any margin applied to the conversion and a disclaimer. Would it be possible to include these as separate parameters provided to the customer by the merchant as part of the payment request so they can be displayed to the customer?

@rlovetx thanks for this input.

I don't think my proposal in #133 would have satisfied all of your requirements and has been closed now in favor of a number of smaller changes that addressed some of the other issues.

My proposal was simply to provide a sequence of CurrencyAmounts which amounts to the payee making the offer in multiple currencies but no more than that.

I think we need a new concrete proposal that addresses all of your requirements:

1. FX rate
2. Payee applied margin
3. Disclaimer

Although I must confess to never having seen these when I have been offered a DCC payment

@adrianhopebailie thanks for your reply.

I'll start a new issue.

The credit card companies do require the three items to be shown for DCC--and have actually fined merchants/acquirers for improperly presenting DCC offers. Saying that, I've seen some VERY dodgy implementations of DCC that aren't remotely compliant with card company rules.