Privacy is awesome - one of the few services I highly recommend to anyone who makes purchases or pays bills online. Slick interface, product just works (except once when I pre-ordered something from Best Buy and that's because Best Buy had a very weird authorization flow that did two charges, instead of an auth + charge) -- and the benefits are great. Best of all, merchants cover the costs, so it's totally free as a consumer (edit: meaning, no monthly fees, etc -- of course merchants have to cover their card processing costs still). Their support is great, too.
I do wish their referral or spending perks were a little more enticing but the privacy benefits are still great overall.
Will be thinking about how I can effectively use the API...
EDIT: Woah, this is REALLY cool:
> Similar to the transaction event, auth stream decisioning will allow your system to dynamically approve and decline authorizations.
Unfortunately I don't think that'll be possible. The docs say that there's a 2000ms cap on the auth stream response time. I don't think that's likely to be raised significantly, since I'm pretty sure their card network backend has a similar requirement.
Darn -- I saw that but was hoping that's just a limit imposed by Privacy that could be lifted, perhaps in 2FA scenarios -- but if it's network-enforced, I guess that rules that out.
No, it isn't. A hidden cost is not the same thing is a non-existent cost. One way or another, you are paying for this service. Having the money only show up on the merchant's statement does make it a little easier to bury your head in the sand about it, but at the end of the day that money is coming out of your pocket one way or another.
A merchant has to cover card processing fees whether I use Privacy or not: my costs are exactly the same whether I use Privacy or a physical credit card.
You lose credit card protections, cashbacks (at least 1% or miles) - so it is basically a debit card purchase.
I lose at least 1% everytime I use privacy (all my creditcards are at least 1% CB). But I like the convenience of not having to get up and reach my wallet from the bedroom.
How so? The loss of rewards is the same reason I don't use Simple, even though from the outside looking in it appears to be one of the best modern banks.
We're rolling out straight cashback (up to 5% at select partners) - simple and no hoops to jump through. It's still in the works, but you can join the waitlist at cashback.privacy.com.
Does the Citi privacy policy promise not to sell your transaction history to 3rd parties? If no, then Privacy's service offering is still attractive from that perspective.
(b) Privacy.com still shares data that they don't deem "personally identifiable" [2]
(c) Privacy.com may share your data during a merger/sale of company stock etc. and I don't think they limit what can happen to it [2]
(d) Privacy.com may share your data "with financial institutions, processors, payment card associations and other entities that are involved in the payment process" (notice they don't limit the usage to actually processing your payment, or the storage to the duration of your membership... they just say "we may retain data about you for a period of time consistent with applicable law" which I assume could be quite a while)
(e) I'm not sure why I should trust a company named privacy.com themselves with my unique device IDs and location data, whatever the situation with third parties is.
The opt-out that Citi provides is extremely similar if not the same to the one that I receive annually from basically all financial companies I have an account with. They allow you to limit the sharing only as mandated by federal law.
Regarding (e) I can only say that I'm quite happy using Privacy's website to manage my account. Of course I disallow location sharing there, so the best location they have is via IP address which is a granularity I'm comfortable with (and which could be further obscured with VPN if you're really worried about it).
Overall it's a nice service. I completely agree with you on (d) being less than optimal and wish they would issue some stronger language on that point. Nothing is perfect I suppose.
I'm one of the founders. Just wanted to hop in here and clarify our current practices.
We do not sell any data to third parties (anonymized or not). We’re never going to do it for direct marketing purposes or anything like that.
The intent behind the non-personally identified information sharing clause is to potentially provide breach notification warnings to merchants:
Example: if a large number of locked cards were used at merchant X, and then subsequently stolen from merchant X, and used at other merchants, we could notify merchant X and our customers that shopped at merchant X (likely before anyone else in the ecosystem knew).
This is not a service we're planning to provide in the near term. Any other information we collect is solely for the purposes of fraud prevention, not marketing.
I definitely hear you on the language in the policy though, and it is something we intend to tighten up
The forms are all the same for opting out, but what exactly they let you put out of is different. In Citi's case it seems to include sharing information with their affiliated for direct marketing, which is what we're concerned about. (I'm not sure what the law is regarding sharing for other purposes though.)
That doesn't mean that Privacy is free. It just means that the system is rigged to hide its cost from you, and possibly to make you pay that cost whether you use it or not. But one way or another, that cost is not zero, and you will end up paying for it whether or not you are aware of it. There simply are no other possibilities.
Hey HN! One of the founders here. We're really excited to share this today. It's just a start, but this is something we’ve wanted to release for a long time now :).
We believe that data portability and an open ecosystem will be table stakes for all fintech companies. You should have granular, differential control of your data. You should be able to grant access to specific functions or aspects of your financial account without wholesale sharing your account login information. You should be able to verify your identity without sharing other personal information.
We ultimately intend for this API to be full read / write capable, including the ability to read transaction data, set rules programmatically, verify identity, create & manage virtual numbers, and transfer funds.
That said, security is core to what we do at Privacy.com and this extends to our API. We want to empower people to build applications on top of our API that delight users, without compromising their privacy or security. We would really value your feedback as a user, developer, or information security professional!
This is wildly cool. I signed up when I saw your original post here on HN and have used it occasionally. In the last week or so I have started using it religiously for every online purchase. Now I'm in the process of moving all my recurring charges to Privacy.
You have absolutely delighted this user, and your API is just the icing on the cake. Keep up the great work.
I used privacy but had issues after transactions were let through when cards were closed /paused. When I tried disputing them, my account was closed and disputes denied.
Why does your marketing claim falsely that transactions cannot happen on a closed card? Why did I never get emails when the disputes were closed, having to reach out to support to find out what happened?
I still have yet to receive any documentation for why the disputes were closed despite requesting that multiple times. Your disputes process is badly broken (at one time, I was told I couldn't dispute because there was "maintenance on the dispute process".)
Hey there! I'm really sorry to hear about the negative experience.
I can't speak to a specific case on a public forum. However, you are correct that in very rare cases, merchants can push through transactions without prior authorization - it's against card network rules, and it’s typically a simple chargeback to win. Even in cases where we don’t win, we typically cover out of pocket.
I’m happy to look into this. Can you shoot me a note at bo@privacy.com?
> merchants can push through transactions without prior authorization
Why was the transaction not denied? What entity was responsible for the authorization? Trying to understand if your network was involved at any point during that transaction, and if so why a charge was allowed to go through. I'm aware that pre-auth for automatic billing can get pass closed accounts at traditional CCs, but if Privacy.com follows that same practice than doesn't that sorta defeat the purpose of disposable numbers?
Force post transactions are literally when a merchant takes the money of the account without requesting authorization, so there is no opportunity to decline the transaction.
This very rarely happens. You won't see any big merchants like Spotify or Netflix doing this because you closed a card to cancel a subscription.
Speaking broadly, there is often some type of fraud, suspicious activity, or a serious loss potential for merchants to resort to this.
Examples - if you rent a car and don't return it, borrow books and don't return them, or abuse generous return policies (return items that are clearly not what you purchased).
All that said, even if we don't win the chargeback, we still often credit the user out of pocket in the interest of giving the user the benefit of the doubt.
I'll look up the emails and forward to you. I think I was covered for some, then I stopped getting responses. Wasn't all force post, but the disputes process wasn't great on the other ones either (had to write a long reason for disputing, minimum word length enforced, when "didn't authorize charge" or the like wasn't enough).
It looks like Privacy.com is build on top of Plaid.com for handling the backend ACH processing. Plaid.com exposes a ton of personal information to its customers like Income, Assets, and Employment Verification. What is the scope of your engagement with Plaid?
Do you recommend that users should protect themselves from Plaid.com personal data harvesting by setting up a secondary checking account to use with Privacy.com that is trickle-fed from a primary checking account?
Hi there! We use Plaid for instant bank account verification and for balance information (to ensure we don't accidentally trigger an overdraft). We don't utilize the Income / Assets / Employment APIs. We don't use them for ACH - We build our own NACHA files in house.
Plaid itself takes user privacy really seriously (part of the reason why we're working with them). They don't resell any of your sensitive data.
A secondary checking account is A-Ok with us. Many of our users do this. The only thing I would say is to be careful to use a bank that doesn't assess overdraft fees. We also are allowing micro-deposits for our more security conscious users on a limited basis (drop me a line bo@privacy.com and I'll set you up). Lastly, card top ups is something we're also looking hard at.
As you can tell, unfortunately there isn't a perfect solution yet - we're trying to be a part of that solution.
Thanks for the details. This service is very interesting. Are these cards funded on a prepaid basis (micro-deposits?), or are the ACH withdrawals performed after the fact?
Hey! Co-founder of Plaid (plaid.com) here. We take privacy extremely seriously, I'm actually an early privacy.com user and major fanboy. Privacy only has access to the information needed to authenticate your bank account and make sure you don't get over-drafted. They don't use any of our income or assets products.
Hi, we have a fair few US users of our accounting app (https://usebx.com) - would you consider providing early API access to our devs so that we can integrate with your service?
This seems to be consumer oriented but I can see some definite business use cases.
Giving employees card numbers for instance and limiting what they can use it for. I know plenty of CEOs of small business that have their credit card copied down by at least a half dozen employees. Then if there is an unexpected charge there is no way to see who it was.
I can also see using this to automatically fill out my expense reports for me. Or make sure I don't forget to fill it out.
* My kid's swim class has a unique card.
* Wife's phone (setup before Google started rejecting their cards)
* Cable bill
* Netflix
* Personal AWS bill
* Gymboree
* Monthly self-storage
Recently closed one-time cards:
* Online grocery order
* Delivery food order (leave some padding for tip)
* Online clothing retailers
* Charitable donations paid via CC
* Tickets to DisneyWorld
* Every penny that goes through PayPal because I don't trust them for a second
Literally, anything that we pay for over the phone or online.
One place I'm especially happy to have it is my vet. They're really bad at billing. They've double billed me twice. Now I keep a dead card on file (they want a card) and give them a new one with a hard limit every time I have to pay a bill. No more double billing and I can see when they're screwing up.
Do you have any information on why Google would block these CC numbers? I know Google, and many others block VOIP phone numbers for example, to discourage rampant account verification, but I can't think of why they would reject a financial reference number.
I imagine it's to stop people from connecting stolen cards to the service and then generating a bunch of other card numbers that are essentially all stolen. It could potentially allow them to use the stolen card more before it was detected.
Not the parent, but I can give some uses of my own.
* All kinds of recurring payments. I pay for email, Dropbox, Patreon, and my VPS with cards that have monthly or yearly spending limits.
* One time payments everywhere I don't have an account and don't want an account. I had to pay dues for a university club recently and I went through a super sketchy university website and payed with a burner card. 3 months later I get a "rejected transaction" email from Privacy telling me that someone tried to use my card at a Walmart. This isn't a common occurrence for me but it was nice to not have to cancel my real credit card.
1. If I want to subscribe to something that could have a recurring payment, I use a burner card to make sure that the recurring payment won't go through.
2. Less often, I use it if there's a trial that catches my eye but I don't want to give them my actual info. I use a single use card in this case.
3. On perhaps less reputable sites where I certainly don't want to give my info. Again, I use a single use card in this case.
4. I use it across all my subscriptions because I can easily see how much I'm spending in a given month (specific to subscriptions).
The cap and single use is the one of their best features; you can assign it any value you want and if it hits that, it won't allow other transactions.
While I'm not familiar with it, I've heard that Citi cards also have the same Virtual Accounts, so you could use that as well.
Sounds like it could also be a cool way of giving your kids access to a credit card (and experience with it), without having to open a bank account for them.
My most common use-case is SaaS trials that require a credit card upfront – I set the limit at $1, so I don't have to worry about cancelling my trial before they autocharge me.
Allows you to have a cap on any card you create, so you have protection against getting overcharged or if you want to help someone out with purchasing something, you won't give them your original card right? Create a privacy credit card, have a cap on it and give it...etc
I use it frequently too (the chrome extension is great). Best use case is using temporary cards for subscriptions or sites you don't use frequently and don't want to give out your actual credit/debit card.
This looks pretty cool. Does Privacy have any services besides the browser plugins? That idea is similar to a couple past projects that didn't last, but this looks very promising regardless.
I used it for several months. I closed cards and they let transactions through anyway. When I disputed them, they first ignored, claimed disputes wasn't working when I asked for status updates, denied disputes, then closed my accounts, and refused to refund the invalid charges.
I would not recommend them. Their marketing is dishonest, claiming that transactions cannot go through if the card is closed, while in truth merchants are able to "force post" debit transactions even when closed.
Weird. That's the exact opposite of my experience. I've had a number of odd rejections that led me to reach out to a couple vendors (hey Amazon, I'm looking at you!) because there were small transactions attempted against closed cards. I've had a few hiccups for things like creating multiple cards to use with PayPal (there's an avenue for fraud there, apparently) but I've been able to get those resolved quickly every time. I have nothing but good things to say about their offering and it's nice to see they're opening a read API (I'm hesitant about write keys).
My only complaint right now is that some vendors (Google specifically) reject their card numbers because they're pre-paid and they've made a decision in the last year or so to stop accepting them. I know for a fact this is a new thing because I'm paying for a Fi account and a Google Music account using privacy numbers. When they finally expire, I'll stop giving Google money altogether.
I'm really sorry to hear about the negative experience. This is surprising to me, and I’d be happy to look into the specific case - can you drop me a note at bo@privacy.com?
I've been looking for a good alternative in Australia and haven't found one yet. If anyone knows one that works in Australia, I'd appreciate it if you let me know.
I do wish their referral or spending perks were a little more enticing but the privacy benefits are still great overall.
Will be thinking about how I can effectively use the API...
EDIT: Woah, this is REALLY cool:
> Similar to the transaction event, auth stream decisioning will allow your system to dynamically approve and decline authorizations.
https://developer.privacy.com/docs#auth-stream
I smell a two-factor purchase flow in my future... (edit again: maybe not)