- From: Adrian Hope-Bailie <notifications@github.com>
- Date: Wed, 30 Mar 2016 06:09:14 -0700
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Message-ID: <w3c/browser-payment-api/issues/29/203423658@github.com>
@ianbjacobs I don't think these are the same issue. #3 is about making a payment request with different amounts in different currencies. This issue is about a difference in currency between those offered by the payee and the currency that the payer wishes to us to pay. I think that @mountielee 's comment on #3 is more appropriate on this thread: >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 architecture would make it difficult for the payee to advertise the currencies that that wish to use before the payee makes the offer and attempts to match the payer's currency (DCC flow). For now I'd suggest that we support DCC as follows: 1. We allow multiple request amounts in different currencies (i.e. Resolve #3 as such) 1. We leave it to the payment processors to address currency conversion as they do today. If a payer gets a request to pay in one currency and responds that they wish to pay in another then it's up to the payee or their processor to handle this. This is only likely to happen if the payment method explicitly supports this scenario otherwise the payment app is just taking a chance (unlikely). This does mean that the payee has to somehow guess what currency the payer would like to pay with so they can offer them a price in that currency but that's not impossible for them to do (it's often done this way already). The alternative is that the payment app makes a back-channel request (to some callback URL) requesting that they make payment in another currency and get a revised payment request in that currency. TL:DR; We should support multiple prices in a single payment request that differ by currency (at a minimum). Currency conversion is out of scope for the browser API. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/browser-payment-api/issues/29#issuecomment-203423658
Received on Wednesday, 30 March 2016 13:10:13 UTC