h a l f b a k e r yIt's the thought that counts.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
PayWindow
Bank supplied Java widget allows direct transaction with merchant bank. | |
You are wanting to shop or pay bills online? Don't use PayPal! using PayWindow you don't need lengthy log-in sessions with kludgy online banking facilities and you don't need to expose your private information.
For those reading more than the first paragraph: sites provide their bank# and account
info publicly. You use this to ask your bank to direct funds to that account. The merchant holds your order in memory until the transaction goes through and they get notified through your PayWindow widget r from their bank.
OK, you find some cool shoes at Zappo's and want to pay for them. At the checkout, there is a small icon that launches a java widget or small explorer like window.
This widget sends the banking info (SWIFT code) for the MERCHANT to YOUR bank/credit card co. via secure and encrypted connection.
Benefit: You need to log in only once with a trusted source (your bank) and everyone who wants to sell you something just has to place the code with their bank access information available.
A new standard in safe transactions that bypasses the middleware and costly merchant services by becoming the de-facto standard for interaction.
The point is to go through a SINGLE payment source which falls back to your personal bank as the lowest common denominator.
[link]
|
| |
Yes, pay like Paypal, but PayPal is an intermediary. |
|
| |
What I propose is a means to connect the banks of the merchant and customer directly with an interface. |
|
| |
Development/implementation would be funded by banks as a service to the customer, and the merchant pays the normal transaction fee. |
|
| |
Only, fees would be reduced because there aren't three layers of profit taking in the process. |
|
| |
//Banks foot the bill ... would be funded by banks//
Banks don't pay for anything except with their customers' money.
How is this functionally different from normal debit card payment? |
|
| |
Banks get paid from transaction fees that merchants now pay to an intermediary. |
|
| |
The difference is that to take orders online you need an expensive merchant account, but you have a bank account already. Electronic Fund Transfers are overpriced and the customer is getting the bill. But they aren't difficult in reality. PayPal is unreliable and has a lot of problems. People aready trust their bank, so why spread the digits out in the websphere? |
|
| |
The original text of your idea did not mention online orders. |
|
| |
Didn't Microsoft try to do something like this? How did that go? |
|
| |
I liked your idea for an instant, but then I began to see some issues. |
|
| |
My first concern would be the security of this. Any client software is just ripe for abuse by scammers, phishers, hackers. Home users systems are just not going to be as "hardened" as those of an online merchant. |
|
| |
There would be a risk, for instance, that I could send you a mail which would bounce a charge of $100 off your widget to my bank account. |
|
| |
Or I could send you a mail to kill your widget and launch my own lookalike. |
|
| |
What happens on the day yuor widget doesn't work? Do you contact your bank? The retailer? The widget programming co? |
|
| |
No merchant will rely on my widget to tell them I have paid for the goods. It would be too vulnerable to me (or someone else) reqrting my widget so that it gives the retailer the "thumbs up" even if no cash will ever go to them. |
|
| |
Trading online is risky enough for any retailer. To control some element of this risk, the retailer will insist that the payment goes through their gateway, not yours. |
|
| |
I doubt if any business will publish its bank account details so publicly. |
|
| |
Good to see someone trying to come up with new solutions to this. I just don't think this is the one, sorry. |
|
| |
Discover has a card with a different number than your account# |
|
| |
I was sort of imagining what PGP did for encryption with private and public keys. |
|
| |
It has to be bank based in a way that the merchant's bank gets to interact directly with customer fund source (bank) to do a direct transaction, so it seemed easiest if the merchant published their info rather than asking the customer to do it. |
|
| |
This wouldn't be triggered by an email and a look alike wouldn't be recognized by the customer's bank. |
|
| |
Could be as simple as a clipboard that recorded the details of the purchases including merchant info, then payents could be made all at once in a session with the bank directly. |
|
| |
PGP encoded email to the bank requesting payment to the merchant? |
|
| |