Hacker News new | past | comments | ask | show | jobs | submit login




The part where you have to give your banking user/pass to PaidEZ kinda makes me nervous. I really wish banks would start picking up the trendy features of today like oauth, API keys, user-defined daily limits & callback URLs like webhooks in github(this would be awesome).

At least my Patelco Credit Union doesn't have any of this =/

The bank that starts doing this kind of power-user/geeky stuff will be very successful. Maybe some start-up should play as the middle-man to your bank and add all these features. Like say you give PaidEZ your routing/acct info so it can ACH withdraw and deposit, then you carry around a PaidEZ debit/credit card with all the cool features.


First of all, that comment is very exciting to me: you totally get what we're doing, you just didn't know you got it. That's awesome. Two things I'd like to clarify:

1. We DO oAuth (or whatever protocol they provide us) into your bank - we don't ever "know" your username or password, the system just goes into your online banking and gets the info it needs to make the payment. We're Regulation E compliant, so we can't do anything you didn't authorize us to do and if you have a disputed payment, we can reverse it.

2. The "middle man" thing you're talking about is what we are. The demo you're seeing is of our consumer facing payments brand, but at our core we're building this as a bank neutral OS/API for good-funds ACH payments. This means merchants or apps won't have to do all this integration with banks, they won't have to pay fees on payments (we don't charge fees on payments), and they won't have to deal with Credit Card BS.


Follow-up on the question I asked in a recent thread (thanks for answering): looking at your video, it seems I have to type the username/password for my bank account into your website. That would qualify as "knowing" them? I realize that doesn't give you full access since most banks now require a card reader and/or 2nd password for any transaction, but it does worry me about additional vulnerabilities.


Great question - and as a side note, sorry to the people on HN I'm going to be bothering about this for the next 6 months. We're building this for Hackers and this is where they live - should be a mutually beneficial relationship though.

Anyway, you don't have to put your username/password into PaidEZ's site - the API can be integrated anywhere. But that said, I don't think that was your point - you're right that the client (browser, app, whatever) KNOWS the username and password while it's oAuthing into the bank, but that's always the case when you login to your online banking. Short of that, we do not know it.

But you're right, that is another layer of vulnerability. No two ways around that, and one that we take very seriously. It's not, however, an added layer of vulnerability compared to entering a Credit Card number - that has the exact same problem, and it's a larger problem because canceling or changing a Credit Card when it's stolen is a BITCH of a process. Changing your password and reversing payments with PaidEZ and your online banking is a breeze.

I should add, nobody has ever had a security issue with PaidEZ up to this point, and we've processed thousands of transactions. I understand that doesn't mean much right now (if it means anything at all), but I don't want to give the impression we've had any security breaches up to this point. We have not.


Wow, well PaidEZ is awesome then!


Haha well there we go! We'll be launching our APIs at least publicly around late February, so stay tuned! Also going to change the name FYI, but haven't settled on what.


the relevant technical solutions have all been deployed in Europe for decades, the problem is not technical.


Agreed, but they are technical in that right now they're really hard to use. We're fixing that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: