Alan, > It's a nice idea, and yes, an individual bank could just make > it work for their customers as payees. Quite nice indeed and > perhaps a good and innovative customer service thing.
You got it. Maybe Anders has a different perspective, but that and the lack of critical mass requirement are the primary advantages of this architecture IMHO. > However, unlike Paypal etc the transaction always has to be > initiated by the payee. (Payee sends a message to the payer > with the URL.) Is there a way for a payer to initiate a > transaction? I can't see how without some form of > communication from the payee to the payer telling the payer > where to go on the web... As David Benson mentioned, PURL can be on web pages and it doesn't have to be entirely static. Dynamic components of the PURL including amount (with privacy protection applied) can be generated by the bank automatically via web services or manually via web pages. In simple implementations, static PURLs will do just fine. > Also, if you are a Bank that issues *and* acquires, it might > be a difficult sell as you would be allowing customers to > become merchants. However I think this could probably be > overcome with appropriate controls and T&Cs. Good point. Merchant banks will likely restrict this service to 'online merchant account' and personal accounts only. > Lastly, it might be a difficult sell in this country since > most Banks here already allow one-off direct payments to any > other New Zealand account, so long as the payer knows the > payee's Bank Account number. So the P2P market is already > catered for in many cases. Same in Korea. However, such services cannot be used easily for international transactions. Best, Don Park Docuverse
