Privacy API: Programmable Payments
developer.privacy.com
developer.privacy.com
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)
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.
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.
So it is not free.
Also note that Citi has virtual account numbers already. It's kind of clunky but it works.
(a) Citi lets you opt out [1]
(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.
[1] https://www.citicards.com/cards/wv/JRS/ACQ/img/Generic_AO_ve...
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
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.
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!
You have absolutely delighted this user, and your API is just the icing on the cake. Keep up the great work.
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".)
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?
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?
Issuer doesn't get a say but can charge back after the fact. Seems like a flaw to me.
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.
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?
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.
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.
* 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.
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.
I have unique/monthly limit cards:
* 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
* 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
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.
Side note for Privacy's front-end people-minor scrolling issue: https://imgur.com/ic5I3hz
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.
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.
Do they somehow get part of the merchant fee?
We don’t monetize by selling your data.