Credit Transfer

02 Feb 2017


See also: IRC log


Cyril, Kris, Ian, Todd, vincent


ISO 3611-2 v. CLDR

Issue 34

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



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].

Next call

For the next meeting, please look at vincent's data

Next call: 16h00 on the 10th

I will send out an invitation!

Summary of Action Items

[NEW] ACTION: Ian to add back supported schemes [recorded in http://www.w3.org/2017/02/02-wpay-minutes.html#action01]
Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/02/02 16:51:37 $