Dynamic Currency Conversion (DCC) Support

[rlovetx]

Hi,

One type of payment that doesn't appear to be fully catered for is DCC. For those who haven't seen this, this is where a customer has the option to pay in their credit card's currency rather than the local currency.

The credit card companies allow this, but have strict Compliance guidelines to protect the consumer.
Essentially, the DCC offer must include:

1. the exchange rate being applied
2. the margin being added to the foreign exchange rate (and in some cases the rate source)
3. disclaimer text (varies by credit card type).

So, for example--

An American customer (currency = USD) buying from a UK merchant (currency = GBP).
The customer selects GBP 75 worth of goods and enters their Visa card details.
The merchant gives the customer a DCC payment option such as--

Pay in your home currency (USD) 112.01
Exchange rate of 1.493 is based on X Bank Rate plus a 3% standard margin. Cardholder choice is final. The DCC service is provided by CompanyY.

To properly process the payment, a DCC provider will need:

1. the base currency (GBP),
2. base amount (GBP 75),
3. foreign/transaction currency (USD),
4. foreign/transaction amount (USD 112.01).

Will the proposed payment standard accommodate the above process?

From looking at the draft specification, there appear to be some optional data fields for the payment that may accommodate the processing needs of a DCC provider. Am I interpreting these correctly?

But, I think support for the DCC offer would be needed as optional fields to allow for DCC offers to be made.

[ianbjacobs]

@rlovetx,

Thank you for the concrete use case. I think this question relates to issue #29

Ian

[dlongley]

Related to #3.

[dlongley]

Seems like the information required for DCC should be payment-method specific data and we could let Payment Apps handle it. Especially since payment instruments are their domain and there is card type specific disclaimer text and so on.

[fredMeignien]

In most cases, DCC is achieved through a message flow between the Merchant PSP (acquirer) and the DCC provider chosen by the acquirer. At the acceptor level (thus for the customer), there are the following impacts: 1/ there is an intermediary pseudo payment response displaying to the customer the exchange rate conditions and asking him whether he is OK or not for DCC. 2/ If he is consents to the DCC proposal, the usual authorisation process is carried on. At authorisation response step, it is mandatory to provide to the customer, via the authorisation payment response message, the exchange rate conditions that were applied (currencies, rates, mark-up on the rate, fees...). So, the message flow includes an extra step, and supplementary data have to conveyed to the customer.

[rsolomakhin]

Seems like the information required for DCC should be payment-method specific data and we could let Payment Apps handle it. Especially since payment instruments are their domain and there is card type specific disclaimer text and so on.

+1 to keep the PaymentRequest simple and let the app handle this.

The message flow includes an extra step, and supplementary data have to conveyed to the customer.

I would prefer this extra step to be handled around PaymentRequest, either in the website or in the payment app.

[adrianhopebailie]

I would prefer this extra step to be handled around PaymentRequest, either in the website or in the payment app.

+1 but we do need to ensure that we have the minimum data in the initial request to meet various legal requirements

[rsolomakhin]

I got the impression that adherence to legal requirements is slated for v2. That is, if a legal requirement is blocking a website from adopting PaymentRequest, the website should submit an issue/pull-request here and wait for it to be adapted. How does that sound?

[fredMeignien]

DCC is not major priority. I think we should ensure a robust API first, and see later on which enhancements are the most expected by the market : there are also lots of needs around pre-auth and multi-steps payments. As I worked quite a lot on DCC for a new ISO20022 card protocol, I'll send the list of data that should be present in the final payment response to comply with regulations. However, it does not seem for me, at that stage, of great added value.

[rlovetx]

The additional data required by all credit card schemes that offer DCC are the base/merchant currency, base/merchant currency amount, foreign exchange rate and a DCC flag.
Most multicurrency pricing products need the same data to support Treasury/settlement (minus the DCC flag). The Acquirers generally want this info as well as Treasury partners such as ourselves (otherwise transactions are foreign only and all parties "lose" the base amounts).
So, a DCC transaction would need data like this to support both the auth (for Visa) and settlement (all cards that accept DCC).
Please see the example into post above.

[adrianhopebailie]

On the back of the comments in this thread I believe that DCC is something that is payment method specific which implies it should be handled via additional fields in the payment method custom data.

I suggest we close this as out of scope for the API as it should be handled per payment method.