See also: IRC log
https://github.com/w3c/webpayments/blob/gh-pages/proposals/supported-networks-list.md
Questions:
1) What are the credit transfer systems we should look at?
(ACH, SEPA, BACS, CHAPS)
2) What are the common data fields?
scribe: and is there a source of labels for these? (Cyril suggests starting with the SEPA rule book for inspiration)_
3) What will the filter language look like?
4) Who will take the next steps on editing?
http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/
<scribe> scribe: Ian
Vkuntz: SEPA may be a good
starting point, but it's restricted to EU
... I think we should focus on low-value payments
... and maybe one good angle to look at is everything that has
been defined under the CGI guidelines
... the common global implementation for ISO 20022
... that's useful because effort has already been made to think
globally
Todd: +1 for low value
[Spec note: include a design guidelines section that mentions that our focus was low-value payments]
https://www.swift.com/standards/market-practice/common-global-implementation
https://www.swift.com/file/30571/download?token=U90xX1U1
Vkuntz: Guidelines are published
as a spreadsheet
... it has the base elements we need to consider
Kris: Do we mean that we have all the potential use cases captured ... or just general?
IJ: Is country party of the filtering language?
Vkuntz: To provide some
background on CGI - it's corporate to bank space
... they have three types of elements: mandatory / conditional
/ not desired
... they left it up to each domain to define their own format
(e.g., for ACH, do this)
kriske: If we were to say "given that this is the requirement from a banking perspective"...would it be a leap of faith to say "actually from a financial institution point of view we have the requirements necessary to support any clearing system globally"?
Vkuntz: Yes, I think
IJ: What's the relationship between the CGI work and the ISO 20022 work?
Vkuntz: CGI is a spin-off of ISO 20022..it is a practical guide
country specific info from cg => https://www.swift.com/file/30586/download?token=h6rwp3p4
Reiterate: this is for consumer to merchant payments
Vkuntz: CGI is more for corporate
to bank space
... there is an important question of what banks can accept
(e.g., from a specific country)
IJ: Does merchant need to filter on system or ALSO region./country
Todd, Kris, Vincent: You will also need to identify region or country
Vkuntz: if the consumer is initiating the payment, then the restrictions are between user and their local bank
IJ: Should we limit scope to "user-initiated"?
Todd: I think we should make it one-directional - consumer initiates the payment
kriske: When you do a web payment
and your merchant has an account somewhere abroad
... so the consumer and merchant are not in the same
country...
... so somewhere there is a bank transfer between banks in 2
countries...
... is that supported here?
Vkuntz: CGI is relevant
... there's another situation where the payment provider
initiates the payment on behalf of the consumer
... the payment provider has the credentials of the
consumer
... and the payment provider can inform the merchant that the
payment has been made.
... this works in the context of sepa and cross border
... but if fees are involved, it's a different question
kriske: As a consumer buying
something in Europe at a store in the US, is that workable
here?
... For a card payment, the networks are global. With credit
transfers, it's more regional. For credit transfers
internationally, it may not be as easy
Vkuntz: It's both simple and
complex.
... if you want to initiate a payment is the merchant bank
info...in corresponding banking, you have standard settlement
instructions
... so the initiating bank will know that they have to go
through this or that route to reach a destination bank
... The merchant has to provide the name of their own account.
The routing information is defined elsewhere (agreements
between banks)
Todd: on the merchant side, the merchant needs to publish a list of countries that they accept payments from.
(IJ: ISO country codes => http://www.nationsonline.org/oneworld/country_code_list.htm )
Vkuntz: The banks have to comply
with various compliance rules
... e.g, a US bank would lose a license if doing business with
a country it should not do business with
adrianhb: There's more complexity in credit transfers due to lots of 1-1 relationships
http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/
<AdrianHB> there are not global OCT schemes
IJ: What is the analogy here for "visa, amex, discover"?
Todd: the merchant would say "I accept credit payments from the US"
kris: The merchant would probably, as part of the API, say "these are the countries I support in a credit transfer environment"
Suppose our payment method identifier is "credit-transfer"
Filtering:
Merchant says "from these countries"
App is distributed with a country (or list?) for initiating payment
kriske: The user should have
limited choice...they have a bank account in a given
country.
... so matching is whether the merchant accepts payments from
the country of the bank of the consumer
... it's based on the country of the user's bank
IJ: Can a bank have a global reach and do transfers from mutliple countries?
Todd: Yes, they can initiate
cross-border payments...
... but cross-border may not transfer well ; there are
hoops
IJ: From a spec perspective, should there be a list of countries? Is that a real world situation?
Vkuntz: The critical bits are:
- transaction amount
- type of goods bought or sold
- date of the transaction
- unique reference
scribe: that's critical in
cross-border payments. (this is our PAYMENTREQUESTID)
... the identification of the merchant in the form of an
account
... bank where the account is located
https://github.com/w3c/browser-payment-api/pull/292
http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/#init-data
=====
Summary:
1) We should look at CGI as a source of fields
2) Likely filter is on countries rather than on networks
3) We should mention any design considerations in the spec (e.g., low value payment primary use case)
scribe: also C2B
4) We need review SEPA spec first draft of input and output data
1) We should change the title to credit transfer, and update the PMI and introducing filtering on countries
Another note: We may have mandatory data and country-specific data field
Vkuntz: I think you have the
mandatory fields in CGI
... that is the result of asking banks what they need to
process payments
IJ: Is there more filtering to do like "ACH v. Wires v. Cheques"?
Vkuntz: Just look at the ACH and Wires columns (and they should be nearly the same)
<todd_a_> I need to drop off, Ian
IJ: There are a lot of "Rs"
Vkuntz: Some information is mandatory for the message but doesn't mean it should be in the API
IJ: 20 Jan?
Vkuntz: Let's say 24 January.
<scribe> ACTION: vkuntz to review the CG required list and send to the WG list (public-payments-wg@w3.org) a list of relevant terms for the API [recorded in http://www.w3.org/2016/12/16-wpwg-minutes.html#action01]
<trackbot> Created ACTION-42 - Review the cg required list and send to the wg list (public-payments-wg@w3.org) a list of relevant terms for the api [on Vincent Kuntz - due 2016-12-23].
<scribe> ACTION: Ian can update the spec to reflect conversation. [recorded in http://www.w3.org/2016/12/16-wpwg-minutes.html#action02]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).
IJ: I will send a summary to the group to ensure Cyril is aware of this direction
<scribe> ACTION: Ian to create summary of this meeting for the WPWG [recorded in http://www.w3.org/2016/12/16-wpwg-minutes.html#action03]
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).