W3C home > Mailing lists > Public > public-webpayments@w3.org > June 2014

Re: P2P Payment technologies & info (WAS Re: Is payment "timeliness" addressed in our work yet?)

From: Joseph Potvin <jpotvin@opman.ca>
Date: Wed, 4 Jun 2014 06:58:00 -0400
Message-ID: <CAKcXiSoDQ4uq05_uyiJ0jMP=QrR5Rj84vkcuZ0OBiAYdfdVP6Q@mail.gmail.com>
To: Dave Lampton <dave.lampton@gmail.com>
Cc: Web Payments CG <public-webpayments@w3.org>
During the period of the payment, surely.

And then... what's the expected persistence of the information in a digital
wallet?

Joseph


On Wed, Jun 4, 2014 at 6:47 AM, Dave Lampton <dave.lampton@gmail.com> wrote:

> Intentionally NOT keeping track of any accumulated "quantified
> entitlements & obligations" over time.
>
>
> Dave Lampton
> * @dave_lampton <https://twitter.com/dave_lampton>*
>
> * DaveLampton <https://www.facebook.com/DaveLampton>  +DaveLampton
> <https://www.google.com/+DaveLampton>*
> www.linkedin.com/in/davelampton/
>
>
>
>
> On Wed, Jun 4, 2014 at 3:45 AM, Joseph Potvin <jpotvin@opman.ca> wrote:
>
>> Dave,  Define "simple".
>>
>> Joseph
>>
>>
>>
>>
>> On Wed, Jun 4, 2014 at 6:34 AM, Dave Lampton <dave.lampton@gmail.com>
>> wrote:
>>
>>> Thanks Joseph, lots of good stuff to read.
>>>
>>> In the case of my little proof of concepts system... I just want to keep
>>> things literally as simple as possible so I'm ignoring the concept of
>>> "quantified entitlements & obligations", and only dealing with the
>>> real-time transfer of already possessed "digital cash" between any two
>>> parties that have control of compliant "wallets"/"accounts".
>>>
>>>
>>> Dave Lampton
>>> * @dave_lampton <https://twitter.com/dave_lampton>*
>>>
>>> * DaveLampton <https://www.facebook.com/DaveLampton>  +DaveLampton
>>> <https://www.google.com/+DaveLampton>*
>>> www.linkedin.com/in/davelampton/
>>>
>>>
>>>
>>>
>>> On Wed, Jun 4, 2014 at 2:45 AM, Joseph Potvin <jpotvin@opman.ca> wrote:
>>>
>>>> Dave,
>>>>
>>>> For further reflection, see work by Geoffrey Ingham, since it matters
>>>> "what" we're speaking about sending around when discussing a payments
>>>> system.
>>>>
>>>> http://ca.wiley.com/WileyCDA/WileyTitle/productCd-074560997X,subjectCd-EC06.html
>>>>
>>>> http://cas.umkc.edu/econ/economics/faculty/wray/601wray/Ingham_ontology%20of%20Money.pdf
>>>> http://www.twill.info/the-ontology-of-money/
>>>> http://www.palgraveconnect.com/pc/doifinder/10.1057/9781137302953.0007
>>>> Sample chapter http://www.palgrave.com/PDFs/9781137302946.pdf (The
>>>> book was edited by my former thesis supervisor Geoff Harcourt. After the
>>>> Paris workshop in April I travelled over to Cambridge UK to discuss some of
>>>> the issues of payment with Ingham.
>>>>
>>>> The link I provided in another thread to an UNCITRAL document is well
>>>> worth reading, to consider the significance of registry-based versus
>>>> token-based ways of sending around the quantified entitlements and
>>>> obligations that Ingham speaks of:
>>>> http://www.uncitral.org/pdf/english/workinggroups/wg_4/wp_119_e.pdf
>>>>
>>>> For example, ACH (Automated Clearing House) is registry-based. BTC is
>>>> token-based. XRP is token-based.
>>>>
>>>> I came to the conclusion that the only legitimate "value" of 1 BTC is
>>>> zero. BTC is merely the message-bearing token, it's not an instantiation of
>>>> "the value". It's limited supply is meaningless. For this reason I agree
>>>> with the determination of courts in Finland, China and elsewhere that BTC
>>>> is a digital commodity, a sort of electronic vehicle to transport
>>>> information about the quantified entitlements and obligations that Ingham
>>>> speaks of. A unit of BTC is therefore properly worth no more than the
>>>> scanned image of a paper cheque. That scanned image is worth zero, and
>>>> cannot be logically conflated with the value being exchanged.
>>>>
>>>> Some consider these matters "too academic". My response is that if what
>>>> we were talking about was the development of standard specifications for
>>>> international shipping containers, it would not be "too academic" to
>>>> determine whether these containers had to be suitable to ship things like
>>>> fresh tomatoes as well as steel bars.  It matters just as much what this
>>>> "web payments" system is supposed to be shipping around.
>>>>
>>>> --
>>>> Joseph Potvin
>>>> Operations Manager | Gestionnaire des opérations
>>>> The Opman Company | La compagnie Opman
>>>> jpotvin@opman.ca
>>>> Mobile: 819-593-5983
>>>>
>>>>
>>>> On Wed, Jun 4, 2014 at 12:07 AM, Dave Lampton <dave.lampton@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Tim, the speech was the one Joseph had sent a link to previously:
>>>>> http://www.richmondfed.org/press_room/speeches/president_jeff_lacker/2011/lacker_speech_20110907.cfm
>>>>>
>>>>> I guess I am fundamentally dissatisfied with credits or IOUs. I want a
>>>>> real currency backed by a central bank that I can give to anyone I want to,
>>>>> instantly, without a third party - just like I can do with cash today.
>>>>>
>>>>> btw, for the record, the idea that nothing is 100% secure... well,
>>>>> that's the common thought, but when used properly there are some schemes
>>>>> that actually do guarantee secrecy. A One-Time Pad
>>>>> <http://en.wikipedia.org/wiki/Vernam_cipher> being an example.
>>>>>
>>>>> For the system of "digital money" I am putting together, however, I've
>>>>> turned things upside down to avoid the burden of keeping everything secret.
>>>>> I'm developing a simple security system that does NOT rely on encryption to
>>>>> provide secrecy, but instead uses it identify and report on data that will
>>>>> be widely shared public information instead.
>>>>>
>>>>>
>>>>> Dave Lampton
>>>>> * @dave_lampton <https://twitter.com/dave_lampton>*
>>>>>
>>>>> * DaveLampton <https://www.facebook.com/DaveLampton>  +DaveLampton
>>>>> <https://www.google.com/+DaveLampton>*
>>>>> www.linkedin.com/in/davelampton/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 3, 2014 at 8:28 PM, Tim Holborn <timothy.holborn@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Hi Dave,
>>>>>>
>>>>>> Do you have a Link to the speech you refer to?
>>>>>>
>>>>>>  (draft, i still have a great deal more to author, before editing… -
>>>>>> but link: http://webarts.mediaprophet.net/?page_id=39 )
>>>>>>
>>>>>> Personally; i agree that individuals should have their own domain
>>>>>> names; and that whilst this is not and should not be a mandatory
>>>>>> requirement for users, the ability to use existing WWW Systems (inc. DNS)
>>>>>> with a domain provides enormous benefits.  Perhaps the barrier is the
>>>>>> methodologies in which existing CPANEL (or similar) systems work; and
>>>>>> within that environment, webized [1] Cloud Storage [2] provides some of the
>>>>>> underlying building blocks needed to create cloud-based user-environments,
>>>>>> supporting an array of WWW applications…
>>>>>>
>>>>>> deiu wrote a paper [3] relating to his work on RWW.io / data.fm and
>>>>>> related Linked Data [4] projects (of which deiu is involved…).  Obviously,
>>>>>> members encourage others to develop solutions in an array of ways, from
>>>>>> use-case and standards; to working solutions.  I think the main effort
>>>>>> surrounds attempting to collaborate around the standards needed to support
>>>>>> interoperability, supporting users through web-standards as best as
>>>>>> possible.
>>>>>>
>>>>>> In your text, you’ve embedded a few economic models around how you
>>>>>> envisage your service to be commercialised.  Classical Web 2 models
>>>>>> centralise data to a branded domain where CDN’s and related infrastructure
>>>>>> then need to support user-growth.  revenue models in-turn are supported
>>>>>> often, by systems such as advertising and data-mining.   Due to the nature
>>>>>> of a centralised or funnel styled topology, the bulk of users are then
>>>>>> served by a centralised management system that can support sophisticated
>>>>>> internal business units, in-turn supporting commercial engagement with
>>>>>> vendors supporting functions such as advertising aggregation and
>>>>>> monitization.
>>>>>>
>>>>>> In distributed models - users would have their own accounts and their
>>>>>> own hosting space.  Perhaps some systems are sold / purchased / leased by
>>>>>> the user on the basis of an economic awareness surrounding the use of
>>>>>> advertising systems to make the cost to the user, of owning a service -
>>>>>> cheaper or free.  Ideally perhaps, these systems can be as cheap as is
>>>>>> possible whilst also being highly secure - so that more sensitive data such
>>>>>> as commercial objects, personal objects of a sensitive nature (medical
>>>>>> records, financial accounts, etc.) are entirely secure save exceptional
>>>>>> circumstances where a court-order may require disclosure on a specified
>>>>>> account, or similar…
>>>>>>
>>>>>> anything that is 100% secure - actually doesn’t exist, from thereon
>>>>>> its’ a slippery slope and i guess the gambit is to get close to that
>>>>>> rating, without engaging in a conversation with those who believe they can
>>>>>> obtain it.
>>>>>>
>>>>>> Another up-side of distributed applications, is that application
>>>>>> developers do not need to fund the traffic requirements for growth. This
>>>>>> in-turn democratises the capacity to build applications, and to
>>>>>> successfully commercialise them, similar to the old industry of
>>>>>> distributing open-source software on floppy disks / early internet systems.
>>>>>>
>>>>>>
>>>>>> IMHO, it gets down to a philosophical layer, which i think is best
>>>>>> described here [5].  If, as a community, we build standards and basic
>>>>>> systems that support the needs of a person (natural legal entity); then the
>>>>>> rest benefits, including our ability as persons to develop applications
>>>>>> that we believe have a role to play in life, in some practical sense.  It
>>>>>> seems sensible to consider that Web2 portals will develop technologies to
>>>>>> adapt their service to improve functionality, and support web3
>>>>>> capabilities.  meanwhile new applications will develop using web3
>>>>>> functionality, requiring some form of cloud-storage that may or may not be
>>>>>> hosted by a person on their own domain…
>>>>>>
>>>>>> I’m not sure how many people in future will store all their digital
>>>>>> transaction receipts in Facebook, or on a google, iCloud or similar service
>>>>>> - but i’m sure they’d all hope for millions…  Equally, i believe
>>>>>> individuals may benefit from the transparency and ease of understanding the
>>>>>> data-privacy related risks incumbent upon the alternative of storing all of
>>>>>> your personal data, on your own hosting system, connected to your own
>>>>>> domain, using your own run-time of software solutions that incorporate a
>>>>>> ‘data space’ as something that is owned by you legally, as it is connected
>>>>>> to that specified domain of which you are responsible for its operations;
>>>>>> or something along those lines…
>>>>>>
>>>>>> underlying that of course; is the need for security with regard to
>>>>>> fiduciary responsibilities.  AML, KYC are amongst the terms used in this
>>>>>> space.  I would argue that if a user has an institutionally approved Cloud
>>>>>> Storage service (as described, in-part, by the references in this doc);
>>>>>> then so long as a transaction is between two known entities; facilitated in
>>>>>> a manner that maintains integrity between WWW Points of distribution
>>>>>> (meaning, from one person to another person, without being intercepted,
>>>>>> copied, redirected, etc.) then in-turn institutional systems should be able
>>>>>> to honour those ‘IOU’s’.
>>>>>>
>>>>>> Whilst some may argue that users storing their own data is insecure;
>>>>>> i’m aware of local police departments in countries other than the USA
>>>>>> having difficulty accessing data from portals owned, operated &
>>>>>> incorporated in the USA for good purpose. Perhaps two imaginary examples
>>>>>> could be 1. like kids, publishing or promoting their suicide intentions,
>>>>>> being ‘missing’ from loved ones at the time or 2. person gets into car
>>>>>> accident and the emergency department has difficulty obtaining health data
>>>>>> / records from the individuals mobile-phone application package provider,
>>>>>> who delivers the application freely with advertising...
>>>>>>
>>>>>> I’ve started putting together documentation for my mid-year update; i
>>>>>> know a bunch of typo’s, issues exist - am still working on it..);
>>>>>> nonetheless,
>>>>>>
>>>>>> hopefully useful...
>>>>>>
>>>>>> What are WebCredits - http://webarts.mediaprophet.net/?page_id=39
>>>>>> GraphDB Technology vs. relational Databases -
>>>>>> http://webarts.mediaprophet.net/?page_id=52
>>>>>> Socio-economics and the evolution of relational database technology -
>>>>>> http://webarts.mediaprophet.net/?p=63
>>>>>> Don’t be afraid of ‘peer to peer’ -
>>>>>> http://webarts.mediaprophet.net/?p=61
>>>>>> (any suggestions on my works, always welcome ;) )
>>>>>>
>>>>>> [1] http://www.w3.org/DesignIssues/Webize.html
>>>>>> [2] http://www.w3.org/DesignIssues/CloudStorage.html
>>>>>> [3] http://myprofile-project.org/thesis/manuscript_en.pdf
>>>>>> [4] http://github.com/linkeddata/
>>>>>> [5] http://www.w3.org/2007/09/map/main.jpg
>>>>>> On 4 Jun 2014, at 1:54 am, Dave Lampton <dave.lampton@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Not sure exactly what to make of the Lacker speech. He's still
>>>>>> talking present day technologies with middle-men and discussing the
>>>>>> perceived usefulness of trying to minimize transaction times to reduce
>>>>>> float. I'm talking about negating the float altogether by allowing
>>>>>> individuals to trade real digital currency, just like we can trade real
>>>>>> physical currency without a middle man today.
>>>>>>
>>>>>> My concepts are akin to a peer-to-peer payment system with real-time
>>>>>> clearing from the central bank of that currency. Similar to the Web Credits
>>>>>> idea, having a "wallet" (or an "account" or a "generic money bag" etc.) at
>>>>>> a particular URI is part of my thinking as well, however I have the
>>>>>> software endpoints much more concretely defined to a standard. In my
>>>>>> imagined system we'd actually be trading REAL dollars (or yen or francs or
>>>>>> whatever that central bank issues) and the central bank clears transactions
>>>>>> on its own currency in real time. Every digital dollar will always have a
>>>>>> single "physical" home (an obfuscated URI) at any one time. Payers initiate
>>>>>> transactions. Cost would be on the order of $10 to run a server like this
>>>>>> for a whole year. There would be almost no cost to anyone who maintains
>>>>>> their own currency server (just electricity and an Internet connection).
>>>>>> The cost of maintaining a single server would be comparable to having an
>>>>>> email server, to the point that it's likely people would be giving away
>>>>>> these accounts as part of a loss-leader to upsell to some other service
>>>>>> perhaps.
>>>>>>
>>>>>> Anyway, I know, I'm still just the new guy here... :)
>>>>>> so I say it all with some humility...
>>>>>> ...but I feel like I have yet to see a proposed system that does
>>>>>> everything mine does. I guess I should try to find time to finish a working
>>>>>> demo of it. I'm about a third of the way there already.
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dave Lampton
>>>>>> * @dave_lampton <https://twitter.com/dave_lampton>*
>>>>>>
>>>>>> * DaveLampton <https://www.facebook.com/DaveLampton>  +DaveLampton
>>>>>> <https://www.google.com/+DaveLampton>*
>>>>>> www.linkedin.com/in/davelampton/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 3, 2014 at 8:21 AM, Timothy Holborn <
>>>>>> timothy.holborn@gmail.com> wrote:
>>>>>>
>>>>>>> Re: dave's post below...
>>>>>>>
>>>>>>> Webcredits is an alternative that seems to provide a functionally
>>>>>>> similar capability (although, using rww systems), with an array of other
>>>>>>> functional capabilities.
>>>>>>>
>>>>>>> See #webcredits in freenode, or
>>>>>>> http://www.w3.org/community/webpayments/wiki/Web_Credits
>>>>>>>
>>>>>>> If you get a rww.io or data.fm account, and put a Testnet address
>>>>>>> into your foaf document, I think melvster (in #webcredits, per above) has a
>>>>>>> bot running that can provide some basic demonstrations.
>>>>>>>
>>>>>>> His also a walking library of knowledge in that area specifically....
>>>>>>>
>>>>>>> Mind.  Accelerating, and diminishing costs for transfers is one
>>>>>>> thing.  I figure once a transaction hits a financial bank to be converted
>>>>>>> into traditional currency, it'll likely have requirements surrounding
>>>>>>> identifying where the funds are sourced, etc.
>>>>>>>
>>>>>>> Much like existing payee relationships, once one payment has been
>>>>>>> made between two accounts, additional transactions are easier.
>>>>>>>
>>>>>>> This is perhaps different for digital currencies, or IOU's /
>>>>>>> accountability capabilities, and other purposes of stuff like block-chains,
>>>>>>> and things that can be done with that geek...
>>>>>>>
>>>>>>> I don't think gold needed an identity, beyond being tested to ensure
>>>>>>> it was gold.  The ID has always lived with the accounts systems.  Perhaps
>>>>>>> also ensuring people don't taint the "gold" with a cheaper substitute, or
>>>>>>> otherwise breach the terms of trade.  More complex examples could be
>>>>>>> asserting a value for use of an image, beyond the scope of a Creative
>>>>>>> Commons license, perhaps all embedded in the image...   The semantic
>>>>>>> clipboard http://dig.csail.mit.edu/2009/Clipboard/ seems to
>>>>>>> consider the Creative Commons elements quite well...
>>>>>>>
>>>>>>> Webcredits is well worth a look IMO...  I'm really impressed with
>>>>>>> it, understanding of course, it's still early days...
>>>>>>>
>>>>>>> Timh.
>>>>>>>
>>>>>>> Sent from my iPad
>>>>>>>
>>>>>>> On 4 Jun 2014, at 1:00 am, Joseph Potvin <jpotvin@opman.ca> wrote:
>>>>>>>
>>>>>>> Dave,
>>>>>>>
>>>>>>> Take a look at "Immediate Funds Transfer: A Central Bank
>>>>>>> Perspective" from the Federal Reserve Bank of Richmond
>>>>>>>
>>>>>>> http://www.richmondfed.org/press_room/speeches/president_jeff_lacker/2011/lacker_speech_20110907.cfm
>>>>>>>
>>>>>>> http://www.chicagofed.org/webpages/publications/economic_perspectives/2011/summers_wells.cfm
>>>>>>>
>>>>>>> --
>>>>>>> Joseph Potvin
>>>>>>> Operations Manager | Gestionnaire des opérations
>>>>>>> The Opman Company | La compagnie Opman
>>>>>>> jpotvin@opman.ca
>>>>>>> Mobile: 819-593-5983
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 3, 2014 at 10:50 AM, Dave Lampton <
>>>>>>> dave.lampton@gmail.com> wrote:
>>>>>>>
>>>>>>>> Since its inception, PayPal has primarily made their money "on the
>>>>>>>> float" meaning that during those few days they have your money, they are
>>>>>>>> able to invest it in short-term money markets, etc. When you're dealing
>>>>>>>> with such a large number of transactions, these investments can be very
>>>>>>>> large and the returns quite handsome.
>>>>>>>>
>>>>>>>> I'm new to this group, but I have joined because I've been
>>>>>>>> developing my own solutions for "digital money" and wanted to see what else
>>>>>>>> is going on. So far, I am gathering that both the current WebPayments
>>>>>>>> (PaySwarm) platform as well as other proposed alternatives like
>>>>>>>> OpenTransact are still all based on email for the sending/receiving of
>>>>>>>> payments, is that right?
>>>>>>>>
>>>>>>>> There is STILL no way for me to send $5 directly to my brother, for
>>>>>>>> example. There is still always going to be at least one third party
>>>>>>>> involved, and often more than one, just for me to give my brother five
>>>>>>>> bucks. Or have I missed something?
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> Has anyone discussed the development of something entirely new like
>>>>>>>> a protocol especially used for nothing but financial transactions? My
>>>>>>>> feeling is that email servers don't know what a payment is and never will
>>>>>>>> be able to do anything with one. End users are still dependent on a
>>>>>>>> third-party to move money to/from their bank accounts.
>>>>>>>>
>>>>>>>> On the other hand, I have a much more complete system for digital
>>>>>>>> money developed in my mind if anyone is interested. If our money were held
>>>>>>>> by our own digital accounts, we could send money to one another just like
>>>>>>>> we can already hand one another cash without any third-party involvement.
>>>>>>>> (it would even put into question the need for banks!) A super brief
>>>>>>>> overview follows:
>>>>>>>>
>>>>>>>> First off, this idea would actually require governments/central
>>>>>>>> banks to issue the digital currency that could subsequently only live in my
>>>>>>>> proposed digital accounts. Yes, I realize that's a huge hurdle to expect
>>>>>>>> their involvement at any stage, but frankly, I think it is the only real
>>>>>>>> way to solve the larger problems permanently.
>>>>>>>>
>>>>>>>> So, what if every financial account in the world were assigned a
>>>>>>>> permanent URL (either a domain or subdomain that is owned by the account
>>>>>>>> holder). Every website already requires a domain, so it's not a big leap to
>>>>>>>> require every digital account to also have a domain or subdomain (and with
>>>>>>>> the advent of IPv6 we'll have so many IP addresses at our disposal, it's
>>>>>>>> absurd). Ownership of digital accounts and the transfer of their ownership
>>>>>>>> would all be handled using the same mechanisms we use today to manage
>>>>>>>> domains using registrars and DNS. In this case, every digital dollar must
>>>>>>>> have a home in a digital account somewhere. Each digital dollar knows its
>>>>>>>> issuing bank, its unique serial number, its current owner (holding account)
>>>>>>>> and
>>>>>>>>
>>>>>>>> Essentially, a digital account would be a new type of Internet
>>>>>>>> endpoint, one that is similar to the function of an email server, but only
>>>>>>>> processes financial transactions. It would be addressed in much the same
>>>>>>>> way that email servers have an MX record in DNS, the currency servers might
>>>>>>>> have a CX record. In my mind, the easiest way to implement something like
>>>>>>>> this would be with a Node.js server using secure WebSockets (wss://) and a
>>>>>>>> simple NoSQL document store, most likely a MongoDB instance. The software
>>>>>>>> itself could be so simple as to be mindless, not even needing
>>>>>>>> configuration, knowing only how to either send or receive currency, nothing
>>>>>>>> more.
>>>>>>>>
>>>>>>>> Lastly, my ideas to keep it all secure turn the traditional
>>>>>>>> cryptographic methods upside-down. Rather than make every financial
>>>>>>>> transaction in the world a big freakin' secret, I would instead make every
>>>>>>>> transaction completely public and recorded by a whole lot of people at
>>>>>>>> once. It would be impossible to fake because only the central banks will
>>>>>>>> transmit transaction confirmations, but everyone will be keeping copies of
>>>>>>>> them as they happen on their network segments, and records can be looked up
>>>>>>>> by anyone at any time. However, to be fair to everyone, money must have no
>>>>>>>> memory, and so only the current owner is known for a given piece of
>>>>>>>> currency, previous owners are purged from the records when a new
>>>>>>>> transaction is confirmed.
>>>>>>>>
>>>>>>>> There are lots more details to all of this if anyone is interested.
>>>>>>>>
>>>>>>>> Not sure if perhaps you're all more interested in forwarding the
>>>>>>>> established ideas, but I wanted to throw this out there since I still do
>>>>>>>> not yet see any proposals which would allow me to send that $5 directly to
>>>>>>>> my brother!!  :)
>>>>>>>>
>>>>>>>> thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>> Dave Lampton
>>>>>>>> * @dave_lampton <https://twitter.com/dave_lampton>*
>>>>>>>>
>>>>>>>> * DaveLampton <https://www.facebook.com/DaveLampton>  +DaveLampton
>>>>>>>> <https://www.google.com/+DaveLampton>*
>>>>>>>> www.linkedin.com/in/davelampton/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 3, 2014 at 4:40 AM, Joseph Potvin <jpotvin@opman.ca>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I don't recall seeing anything specific yet about basic timeliness
>>>>>>>>> of
>>>>>>>>> web payments.
>>>>>>>>>
>>>>>>>>> Here's an example. In the course of having some funds reimbursed
>>>>>>>>> to me
>>>>>>>>> by a business via PayPal, I then transferred the money from my
>>>>>>>>> PayPal
>>>>>>>>> account to my bank account. Once that transaction was processed via
>>>>>>>>> the PayPal site, I recieved the following emaIl message:
>>>>>>>>>
>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>> From: service@intl.paypal.com <service@intl.paypal.com>
>>>>>>>>> Date: Tue, Jun 3, 2014 at 7:03 AM
>>>>>>>>> Subject: We're transferring money to your bank
>>>>>>>>> To: Joseph Potvin <jpotvin@opman.ca>
>>>>>>>>>
>>>>>>>>> We're transferring money from PayPal to your bank
>>>>>>>>> Jun 3, 2014 07:03:36 GMT-04:00
>>>>>>>>> Hello Joseph Potvin,
>>>>>>>>> You asked us to transfer $XXX.XX CAD from PayPal to your bank
>>>>>>>>> account,
>>>>>>>>> and we're processing it now. It usually takes 3-5 business days for
>>>>>>>>> transfers like this to go through, so you should see the money in
>>>>>>>>> your
>>>>>>>>> bank account by Jun 10, 2014.
>>>>>>>>> -----------------------------------------------
>>>>>>>>>
>>>>>>>>> Huh?  3-5 business days?   But the ACH system clears at least
>>>>>>>>> every day.
>>>>>>>>>
>>>>>>>>> Does anyone here know in which organization's hands the money sits
>>>>>>>>> for
>>>>>>>>> 3-5 days? And why?
>>>>>>>>>
>>>>>>>>> Is this a delay due to some slow anti-launderiing verification
>>>>>>>>> processes mandated by government?
>>>>>>>>>
>>>>>>>>> Alternatively I can imagine there's a cloth bag tied with sisal
>>>>>>>>> containing my $XXX.XX CAD being loaded onto a side-bag of a donkey,
>>>>>>>>> getting ready to make the trek in this direction. I'm fine with
>>>>>>>>> that.
>>>>>>>>> Just need to know though.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joseph Potvin
>>>>>>>>> Operations Manager | Gestionnaire des opérations
>>>>>>>>> The Opman Company | La compagnie Opman
>>>>>>>>> jpotvin@opman.ca
>>>>>>>>> Mobile: 819-593-5983
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joseph Potvin
>>>>>>> Operations Manager | Gestionnaire des opérations
>>>>>>> The Opman Company | La compagnie Opman
>>>>>>> jpotvin@opman.ca
>>>>>>> Mobile: 819-593-5983
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> <819-593-5983>
>>>>
>>>
>>>
>>
>>
>> --
>> Joseph Potvin
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>
>


-- 
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983
Received on Wednesday, 4 June 2014 10:58:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:31 UTC