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 [email protected]?
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 [email protected] 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.
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!