See also: IRC log
Kris: SWIFT uses 3166-2
... and ISO 20022 does
Ian: Note that the question here is not what data is sent in the payment response, but the syntax of the filter on countries. (We didn't close issue 34.)
(Matt's issue https://github.com/w3c/webpayments-methods-credit-transfer-direct-debit/issues/33 )
(question is to add back supportedNetworks)
(We may need to change the name to avoid confusion if "networks" here means something different from "card networks" as used in basic card spec.)
Cyril: Not sure how much merchants can filter on country in light of contractual obligations to schemes
IJ: Country is for ecommerce, network is for payment
Q. Do we need the network filter also?
(from email: Matt: +1)
Cyril: +1
<todd_a> +
(Todd: +1)
Kris: +1
cyrilV: Merchant has to obey
certain laws.
... and network rules
IJ: Are there schemes that support country filters?
Todd: I look at this as include
v. exclude. There are obviously countries that merchants can't
do business with for some rules. The network providers would
already know and would not allow the transactions to occur in
any case.
... so I think an include feature is useful.
Cyril: I think that "people will
know" what they can't use
... if the merchant can use the API to cherry-pick countries,
the user experience will be a nightmare
... merchants might be confused about the different between
shopping and payment
... I would be concerned that an app is not available _without
explanation_ to the user
IJ: The question for me here (around countries) is whether there are other credit transfer systems that allow merchants to arbitrarily refuse to accept credit transfers from certain countries
vincent: Merchants need to be
able to say "I don't accept payments from this country"
... e.g., a US person cannot accept payments from banned
countries...the banks block the payments
Q: Should the right user experience be (1) not show a payment app based on merchant info or (2) let the payment happen and allow the network to produce the error.
vincent: The use case I have in
mind is where the merchant knows that there are additional
charges
... and so the merchant decides not to accept credit transfers
from those countries.
... and I think then that the merchant would rather not show
the payment app
cyril: What is the implication in our API?
Ian: country code in the filter
Cyril: the country filter does not make sense for some schemes. (And the spec should make that clear)
IJ: I think we have to be careful
to avoid semantic relationships among filter fields...because
that makes it harder to do purely syntactic filtering without
semantic checks (that are payment method specific)
... Are people comfortable including the field, knowing that
it's syntactic filtering only, and relying on the merchant and
payment app to provide relevant information correctly.
Vincent: From a user experience
point of view, I want to avoid this: you initiate credit
transfer and then a couple of hours later you get an email that
says the credit transfer can't happen
... if you can exclude from the beginning that you can't make a
payment when you order from belgium to france
Cyril: Is that about shipping
(address)/
... is it about payment or delivery?
IJ: Does your use case, Vincent apply to digital goods?
Vincent: yes
Todd: What's the difference
between ship-to and bill-to address?
... for ACH, the account tied to the payment ... the bill-to
address is probably more important than ship-to
Vincent: In most cases it doesn't
make a difference but it could make a difference (e.g., around
taxes)
... e.g., when UK exits SEPA there will be special tax
arrangements put in place
Cyril: But that will be another scheme
===
Summary:
1) We need filtering by schema
2) It is possible that we don't need filter by country because other information around the purchase (e.g., shipping or billing information) can inform whether the merchant accepts credit transfer.
Cyril: I think we may still want to include a country filter because we don't know all the systems in the world....since we don't know what payment scenarios users will find themselves in, and so we should allow the payment app to try to gain a match
CyrilL: I think that Vincent is
right when he speaks about Switzerland.
... the European rules on fees are not the same
... they are in SEPA in terms of protocols, but I believe that
fees may vary
... so the merchant may want to say I accept SEPA but not from
this country due to fees
... or taxes
=====
<scribe> ACTION: Ian to add back supported schemes [recorded in http://www.w3.org/2017/02/02-wpay-minutes.html#action01]
<trackbot> Created ACTION-190 - Add back supported schemes [on Ian Jacobs - due 2017-02-09].
For the next meeting, please look at vincent's data
Next call: 16h00 on the 10th
I will send out an invitation!