Re: Interledger Architecture: OWPS architecture

I agree with Roger about "routing payments to a *receiver* which may be 
an invoice rather than a payee"

A payment is a transfer of assets between 2 accounts. In most cases, 
its purpose is to fulfill one or more payment obligations and in some 
cases, a payment obligation is materialized by an invoice.
An invoice is a unique representation of a payment obligation but it be 
can fulfilled by one or more payments (or credit notes).
Finally, the money needs to go to an account. Is the idea that the 
account number will be retrieved from the invoice number ?

Stephane


On Thu, 24 Mar 2016 19:18:04 +0100, Melvin Carvalho wrote:
> On 24 March 2016 at 18:06, Roger Bass  wrote:
>
>> Stefan,
>>
>> Kudos again to you, Evan and the team on the architecture doc - a
>> great start.
>>
>> The payments layer piece is a really interesting addition, even
>> though its obviously quite early. I had a couple of comments on the
>> architectural content, as a prelude to some thoughts on perhaps
>> renaming it, as you were suggesting. Ill put those in a separate
>> email, for easier readability.
>>
>> Firstly, it seems to me there may be a trade-off here between
>> maintaining simplicity, focusing on a narrow payment use case, and
>> extensibility - both to a wider variety of payments use cases, and
>> perhaps even to other transactional interactions between payer and
>> payee (e.g. in a B2B context). The more important that extensibility
>> seems to be, the stronger the case for leveraging standards
>> frameworks that have already been built (and deployed) elsewhere.
>> Perhaps we should clarify what the goal is with this Architecture
>> document? More specifically...
>>
>> 1. Discovery. Webfinger, although it uses a URI, seems more focused
>> on converting a (payee) email address. (And despite the name, doesnt
>> really seem like a Web protocol). That seems potentially problematic
>> for payments to organizations in particular. Theres an IETF RFC
>> specified framework for federated directory / discovery applications
>> on top of DNS: DDDS [1]. Theres also been some work on using this
>> for discovery of organizations / entities, and Metadata Services
>> that describe transaction endpoints for them (OASIS doc linked here
>> [2]), a generalization of a model thats live in a pan-European
>> government procurement system, PEPPOL. It seems to me that an
>> Interledger / Payments Discovery model needs to explicitly address
>> the federation of existing payee directories, based on a range of
>> potential identifiers (email, cellphone, domain, organizational ids
>> etc).
>
> Good spot.
>
> I cant think why webfinger would be used for discovery, rather than,
> linked data + JSON LD.
>
> Certainly I would want to replace that portion of the arch with a
> version that uses w3c standards.
>
>  
>
>> 2. Query. The notion of routing payments to a *receiver* which may
>> be an invoice rather than a payee is interesting. However, its
>> unclear how well this lines up with real world processes, especially
>> B2B, where a single payment is associated with remittance detail for
>> applying that payment to multiple invoices, sometimes with
>> deductions or other adjustments.
>>
>> Roger
>
>
>
> Links:
> ------
> [1] https://en.wikipedia.org/wiki/Dynamic_Delegation_Discovery_System
> [2]
> 
> http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/cs01/BDX-Location-v1.0-cs01.html
> [3] mailto:roger@traxiant.com

Received on Friday, 25 March 2016 10:07:34 UTC