Payment Agent TF meeting -- 09 Jan 2015

<hjeuer> So dave is the hero today!

<steph> scribe: david

<scribe> scribenick: dezell

<scribe> scribe: david ezell

recap of Use Case TF

<scribe> Meeting: Web Payments IG Payment Agent TF

manu: we had an assignment to flesh out the use cases before the call yesterday, and we had enough to make some progress.
... our plan between now and the F2F is to go in depth on a couple a week based on our preliminary priority findings.
... the plan is to move the use cases from the wiki in to an "FPWD" for use cases. This will be easier to review.
... We chose 3 use cases for initial inclusion in the "FPWD" - 1) Payment Request 2) Choice of Payment Instrument Instrument, and 3) Push-payment.

<manu> dezell: May I request that people please review the status of the use case task force - it's a self-selected group. We put the most important, least controversial ones into the document.

<manu> dezell: Please watch use case task force page - look at the "Status" section.

<manu> Link to status section: https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force#Status

<scribe> Agenda: https://lists.w3.org/Archives/Member/member-webpayments-ig/2015Jan/0001.html

Agenda bash

manu: I'd like to discuss the document I circulated.

pat: I'd also like to give a diagram status update, changes based on comments before the break.

joerg: we now need to merge work from manu and pat.

<manu> +1 to talk about Pat's diagrams.

<manu> Transaction phase-based approach to Payment Agent: https://docs.google.com/document/d/1q_1OA1FPE1L-jkXlvu89RFSJ3FGWeHyw5SUJotfiACk/edit#

Transaction phase-based approach to Payment Agent

<manu> https://docs.google.com/document/d/1q_1OA1FPE1L-jkXlvu89RFSJ3FGWeHyw5SUJotfiACk/edit#

manu: the wiki we have developed is that it throws quite a bit at the reader.
... "dense reads" don't get read.

<manu> For an example, let's look at phase3: https://docs.google.com/document/d/1q_1OA1FPE1L-jkXlvu89RFSJ3FGWeHyw5SUJotfiACk/edit#heading=h.azz2z0d14zgh

manu: this format breaks down the information into a high-level view, and allows going to use cases.

<manu> For an overview of the Payment Agent, look here: https://docs.google.com/document/d/1q_1OA1FPE1L-jkXlvu89RFSJ3FGWeHyw5SUJotfiACk/edit#heading=h.fz60236fv1sw

manu: so this is the proposal, breaking things into phases, and then allowing drill down.

pat: I like the idea of breaking the process into component parts.
... that allows breakdown into steps "A, B, C" and then those steps might be reused.
... I think this model allows the "mental ladder".
... In general I like it.

joerg: so to contrast the diagram from pat with manu's document, the diagram has all the details in one place.

<manu> +1 to use same vocabulary / modules - work on aligning them.

joerg: we need the same vocabulary and the same modules, so that our discourse remains sensible.

<padler> +1 on using multiple viewpoints

joerg: architectural view, phases or flows, use cases. These are the 3 views.

<manu> Use Cases are - "What we want to happen."

<manu> Payment agent is - "How it happens"

joerg: I think once we normalize these things we'll be close to a design.

manu: agreed that we need to normalize.
... concerns - it assumes there is one flow, which may be a bad assumption.
... question - do we want to show one flow (easy to grasp) or produce multiple flows?
... this is my biggest concern, in over simplifying.

joerg: I think we first (as experts) need to "believe in it" - then later on simplify it.

<Zakim> manu, you wanted to raise concerns about "the flow"

<manu> dezell: I like the document in general, it's a bit like OOB - use cases in the center, maybe deployment/architecture outside.

<manu> dezell: This is highly technical discussion, as an Interest Group, it's not really for this task force to consider - but we do want to think about what WG should be created to work on this work.

<manu> dezell: One last point about use cases - there are a bunch of different flows here. Typically, the way I've been able to make this work is to create alternate flows and exception flows. The only way these flows make sense is the pre-conditions and post-conditions are spelled out.

<manu> dezell: Anything that's spelled out - any pre-conditions are set to post-conditions. Any exceptions lead to post-conditions staying the same.

<manu> dezell: I think if we approach it this way, we can achieve that.

<manu> dezell: If we look at the use cases, it looks like we have a large one, which is payment, and a whole bunch of alternate flows.

joerg: I appreciate the architectural concepts.

pat: as I think about this discussion - manu's diagram tries to simplify the use cases (unification) vs. too many use cases to comprehend.

<manu> +1 to Pat - get reader accustomed to basic path/concepts, then let them dive into the details.

pat: back to the original diagram - the top level is different "payment schemes" and maybe that's the first breakdown.
... we could say "you're going to see a bunch of use cases following".
... I'm wondering what is the next step - how do we "bucket" or breakdown the components to aid in reuse and understanding?

<hjeuer> Flows from user-view added to wiki by joerg: https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force#Flows_and_Protocols

joerg: these diagrams are in powerpoint if people would like to work with them.
... the second diagram is very basic, but I think it reflects what we're trying to do.

(joerg walks through the diagram)

joerg: and there are also numerous payment instruments in play, which may be "primed" by the customer in advance of the actual transaction.
... all payment instruments can all live in the active list.
... including coupons, cards, or accounts.
... the design tries to make the flows of the arrows very consistent, so that the customer is not surprised.

<manu> +1 for it being rather non-technical overview. I like it.

joerg: this is a non-technical overview, though it looks technical.

pat: seems like either the payer or the payee might complete various "parts" of the scenario.
... it seems like we should categorize the phases as payer, payee, or either.
... let's say I'm a payer paying with cash, but the merchant still needs to perform levels of the transaction require to create the digital receipt.

<Zakim> manu, you wanted to mention two concerns - physical receipts and regulatory jurisdictions.

manu: pat has reminded me of the concern about the possibility of completing steps in "analog". The receipt process needs to be analog as well.

<steph> it was Neil from transafrica

manu: the example given at our f2f was that in some parts of the developing world, the payment may be totally electronic, but uses a paper receipt.
... second point, we talk about regulatory restrictions, but we haven't yet got this represented in our diagrams.

joerg: regulation can be quite complex. Our best attempt should be not to be in violation.

<manu> re: foreign exchange - datapoint: AirBnB does ForEx for you for a 3% fee.

pat: so to the point of regulatory restrictions - traditionally, merchant serves the payer, and the merchant makes sure of regulatory compliance.
... with the payer directly working outside the merchant, there are potential issues with regulations.

<manu> re: foreign exchange - datapoint: PayPal does ForEx for you for a ??? fee (and even provides an option of using an alternative pricing benchmark).

joerg: I think the point is that the Payment Agent has to negotiate compliant protocols.

pat: it comes down to the payment scheme, e.g. VISA/MasterCard dictates who can do what.
... the wallet has to plug into these payment schemes.

<Zakim> dezell, you wanted to talk about "laws"

<manu> dezell: Quick comment - it is not necessarily the protocol that the wallet will need to worry about, it's what use cases might be allowed.

<manu> dezell: Offering discounts for using certain payment instruments, merchants regularly sign agreements with card networks to not allow other discounts.

<manu> dezell: It might need to be internalized in the payment agent.

pat: on that point - if I'm at a merchant's website saying what they're willing to accept, here are the schemes that I trust.
... I can't discount from one or the other. But the >payer< wallet might know that mastercard discount may apply.

<manu> dezell: When I use one of my cards, I get cash back.

<manu> dezell: So these aren't regulatory issues, they're contractual issues. We may have to make sure we're prepared to jump through the hoops where we have to.

<manu> dezell: It may be that one card vendor would provide a card that provides cash back at the point of sale.

<manu> dezell: Burden of regulatory compliance is taken by merchant and payment provider.

<manu> dezell: When the customer is in control, the situation changes - we need to be aware of that.

pat: what's interesting is that if I pay with cash, I'm still implicitly using a payment processor.
... where do "taxes" fall in "regulatory requirements"?
... "apply rewards", "apply discounts", etc. have to be handled properly.

<hjeuer> ... time is over - I will call people on the queue to make short statements - and hope you all can stay a few more minutes.

pat: and peer-to-peer payments open new regulatory channels

manu: I'm concerned - we have to talk about it, we have to put something about it in the document.
... not mentioning it will cause people to think we didn't consider it.

<hjeuer> +1 to mention how we handle regulation/ legal/ contract

<manu> dezell: When I read our charter at a recent event I said "We will not knowingly violate any laws"... not "we will not violate all regulations". It's a complex area.

Next Steps

joerg: Pat, what are you prepared to do?

pat: we need to figure out how to tie the various representations together..

s/\.\./\.

joerg: another thing is to take into account Manu's work. Should we switch from the Wiki to the Document?

manu: the google doc is was a POC - I suggest we move it back into the Wiki.

<manu> pat: We should also talk about the Roadmap document, maybe we can integrate some of what Manu has put together.

joerg: should we meet more often? Every week?

pat: yes.

joerg: so we have calls on 16 and 23 January?

<Jean-Yves> +1

- DRAFT -

Payment Agent TF meeting
09 Jan 2015

Attendees

Contents

recap of Use Case TF

Agenda bash

Transaction phase-based approach to Payment Agent

Next Steps

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Payment Agent TF meeting 09 Jan 2015

Attendees

Contents

recap of Use Case TF

Agenda bash

Transaction phase-based approach to Payment Agent

Next Steps

Summary of Action Items

Scribe.perl diagnostic output

Payment Agent TF meeting
09 Jan 2015