Live data from Hacker News

Launch HN: Didit (YC W26) – Stripe for Identity Verification

news.ycombinator.com

11–20 of 76 posts

Re: Launch HN: Didit (YC W26) – Stripe for Identity Verification

#11
post #6

Earlier quoted context omitted.

Stripe Identity is good, especially if you already use Stripe. The main difference is that Stripe built identity mostly for their payments ecosystem, while Didit is a standalone identity infrastructure that works across any platform and any identity flow. We also optimized heavily on fraud detection, speed, and much better pricing.

Isn't it useful to pair identity with common reasons to identify? Why else would you ask? Are you saying your fraud detection and speed beats Stripe, or just your price?

Yes, we mog on speed, onboarding rate, fraud detection, and price.

Re: Launch HN: Didit (YC W26) – Stripe for Identity Verification

#14
post #9

Here's a better idea: Eradicate requirement of the most personal details of someone to do basic tasks...such as using a web application. Unless it's a government organisation, no private provider should have the ability to use or process people's identities. It's too much power in one entity's hands. I wish someone would actually solve this instead of yet another ID solutions. We all saw how a literal job seeking app…

Id say this is a valid criticism of the b2c market (esp. for social networks). but there still is a viable b2b market where kyb/c is not as intrusive - and sometimes a regulatory requirement (finance, health, etc.).

Re: Launch HN: Didit (YC W26) – Stripe for Identity Verification

#15
post #9

Here's a better idea: Eradicate requirement of the most personal details of someone to do basic tasks...such as using a web application. Unless it's a government organisation, no private provider should have the ability to use or process people's identities. It's too much power in one entity's hands. I wish someone would actually solve this instead of yet another ID solutions. We all saw how a literal job seeking app…

We actually agree with the core concern.

Right now the internet has a terrible model where every company asks for your ID and stores it themselves. That means your identity data ends up scattered across dozens of databases.

We think the future is privacy-preserving identity and reusability: verify once, keep your identity in your own wallet, and only share minimal proofs (e.g. “over 18” or “real human”) instead of your full identity every time.

That’s the direction we’re building toward with SSI / identity wallets and reusable verification.

Re: Launch HN: Didit (YC W26) – Stripe for Identity Verification

#16
post #9

Here's a better idea: Eradicate requirement of the most personal details of someone to do basic tasks...such as using a web application. Unless it's a government organisation, no private provider should have the ability to use or process people's identities. It's too much power in one entity's hands. I wish someone would actually solve this instead of yet another ID solutions. We all saw how a literal job seeking app…

These 'identity verification' companies end up becoming a main enemy of this pursuit. Their own revenue relies on legislation that assures their existence.

Re: Launch HN: Didit (YC W26) – Stripe for Identity Verification

#19
Great to see innovation in this space!

If I could make one giant request, it's around giving (properly authorized) humans the ability to override the system when needed. When you make a simple API, it's all too common for a company integrating the solution to rely entirely on the identity service's yes-no outcome. But all too commonly, there's no way to override a decision, or bypass the need for identification.

In the travel space, I've seen situations, especially with luxury and celebrity clients, where there's human levels of trust across the board, all parties are agreed at senior levels that they'd like to fulfill with a one-off exception to identity verification... but the technology refuses to let them proceed without going through the full verification flow, and if they're integrated in the simplest way, there's no "escape hatch" on the integration's side.

And similarly, if a person happens to trigger false negatives on video matches (say, due to medical reasons) giving support teams an ability to build exceptions is key. Having a way to tell the system "for this transaction/account ID, when they get to this node in the flow, let them through as if checks proceeded, or treat them as pre-authorized" would set you apart.

(Obviously, for things involving KYC, there's a lot of considerations around permissioning - but for many use cases, you want to empower senior support teams.)

Post reply on HN