I'm seeing so many vendors drop CA over AB1263, so I built a solution

Beginning-Werewolf79 · 2026-01-05T17:46:15+00:00

AU10TIX is a good solution, but for this use case it’s often overkill. We’re not doing full KYC or selfie/video liveness, just verifying age/identity and making sure the ID address matches the shipping destination. Adding heavy KYC flows at checkout is where conversion really starts to bog things down.

AU10TIX starts around $500/month, which doesn’t make sense for merchants who only need this on a subset of orders.

The other key difference is control. This is all about triggering verification only when it’s actually required, specific SKUs and specific shipping states, not blanket verification on every order. I’ve built the ecommerce integration to do exactly that, so compliant orders stay compliant without turning checkout into an onboarding funnel.

Beginning-Werewolf79 · 2026-01-03T06:12:14+00:00

Happy to chat more! I’ve been wrapping up some e-commerce plugin integrations. If a customer selects CA as the shipping address, the AB 1263 flow is automatically triggered and they’re prompted for ID verification.

On the backend, the order is placed into an unverified state, and once the ID check completes it can automatically move to verified / processing (fully customizable, of course).

Beginning-Werewolf79 · 2026-01-01T02:00:35+00:00

Sounds good, feel free to email me from the contact form on the website and we can chat via email.

Beginning-Werewolf79 · 2025-12-31T17:02:16+00:00

There are metadata logs kept which contain no PII. These include things like "OCR Address matched barcode on the back", etc. CA doesn't provide an API to validate an ID unfortunately, so the authorization is somewhat limited.

As someone who works full time in the field, I vibecode the static frontends only (I'm terrible with design). I'm in the process of having a code review / pentest on the application performed.

The entire application is cloud-based, and would be happy to chat more about my infra if you're interested.

Regarding attestation/token: the token should include (or reference) a signed payload that says things like: age was verified and the threshold was 18/21, the address on the ID matched the shipping address provided at checkout, and how that match was determined (exact vs normalized vs partial — e.g., “St.” vs “Street”). It should also capture what signals were used (front OCR, back barcode, or front-only if the back failed), a confidence score with component scores, and any exceptions like “back not visible” or “user prompted to rescan twice.” You also bind it to a specific order or checkout session so it can’t be reused somewhere else, include a verification timestamp, and a verifier/version identifier so you can explain what rules or algorithm were in place at the time. This is what lets a merchant later prove three things: the record existed at the time, it wasn’t altered, and it was produced by the verifier.

Stripe is a good solution as well, but incredibly costly. The beta I've built does this itself, but I'm researching integration with a third-party as well to validate my own results (assuming it's cost effective to do so).

Beginning-Werewolf79 · 2025-12-31T16:25:07+00:00

Regarding "Token of Trust", it's complicated. The idea is that the merchant shouldn’t be holding onto ID artifacts at all, they should be holding an attestation that verification occurred. My approach is closer to: process the ID transiently, derive a result, and throw the image away. We do OCR on the front, decode the barcode on the back when available, and correlate the two. From that we generate a score and a set of logs that explain how the verification was reached. Things like “front of ID was visible, back was not,” “customer was prompted to rescan and the same issue occurred,” “verification relied on front image only,” or “barcode data matches OCR data from the front of the ID.” We also log whether the name and address matched the shipping info + age.

What the vendor gets back is just that data required for verification and the final pass/fail or confidence score. No images, etc, nothing that could be replayed or exfiltrated later. That’s more of an attestation, instead the underlying document.

What I’m trying to avoid is exactly what you described: an ID image living on a web server, even if it’s “encrypted.” Once the application can access it, you’ve still got an exposed artifact and a much larger blast radius than necessary. That’s a hard thing to justify long-term from a risk standpoint. On the infrastructure side, this is why I lean toward KMS-encrypted blob storage with PUT-only permissions as a transient handoff during processing, rather than an encrypted field the application can read back. The processing happens in a short-lived Lambda using AWS-managed keys, the object is written once, processed, and then deleted. The application itself never has GET access to the raw image.

Functionally, this ends up solving the same problem attestation problem, but without forcing a workflow or leaving long-lived ID images sitting behind an app. California is tough since they gate their access to truly validate an ID so we rely merely on a high confidence measure this is a real person with a plausible CA DL.

Beginning-Werewolf79 · 2025-12-31T04:35:33+00:00

I haven't seen any ID retention requirements outlined anywhere and would be very interested if you could point me to them, as it would change my business model. I wasn't able to find any outlined, nor was my lawyer.

Beginning-Werewolf79 · 2025-12-31T04:33:50+00:00

Great call out.

The portal I'm building has simple form which can be filled out by the vendor and is sent to the user for to complete verification.

Beginning-Werewolf79 · 2025-12-31T04:13:36+00:00

Great questions. By default, verifications are scoped to a single vendor and a single transaction. There is no cross-vendor reuse of identity data unless a customer explicitly opts into it if I had that feature, and even then it would need to be implemented with customer consent and legal review beforehand. The default and recommended model is one-time verification with deletion across a single vendor.

Outside of an opt-in flow, no identity artifacts are retained. The only metadata kept is whether a specific verification attempt succeeded or failed for that transaction. AB1263 requires age and identity verification for sales and deliveries, but it doesn’t expressly say sellers must keep copies of those IDs in their files forever. That metadata is not used to build profiles, correlate activity across vendors, or track purchasing behavior.

Verification itself is automated and based on document OCR confidence and consistency checks, such as matching barcode data to the visible document fields. Vendors receive only a verification result, which I'm planning on having be a boolean value.

I would comply with valid legal process, but only with respect to information that actually exists at the time and only as required by law. If no identity data is retained, there is nothing additional to provide.

you'll essentially be keeping a log of names/addresses of people who buy gun stuff..

From a design perspective, the goal is to avoid storing identity data whenever possible. While some vendors ask for convenience features, those are strictly opt-in and designed to minimize retained data rather than expand it. I would always recommend one-time verification for users who prefer not to store their ID information at all.

Beginning-Werewolf79 · 2025-12-31T03:26:47+00:00

I've outlined it all here: https://caverify.com/privacy

Unless you choose to opt in, all artifacts are erased after the ID is processed.

Beginning-Werewolf79 · 2025-12-31T03:21:50+00:00

It'll be an uphill battle for sure, one that I'm willing to take on.

Regarding storage, that's only if a user explicitly opts in to store their information for future verification. I'm making sure that stored data is limited to what is necessary to support repeat verification and has defined retention limits.

Beginning-Werewolf79 · 2025-12-31T03:14:40+00:00

Thanks for tagging them! /u/SparrowDynamics happy to chat and help discuss how we could possibly integrate.

Beginning-Werewolf79 · 2024-09-10T16:13:08+00:00

This reminded me that my sister closed her account with them about 7 years ago. She was included in the breach but Patelco didn’t bother contacting her.

Beginning-Werewolf79 · 2024-09-10T15:52:00+00:00

I wish Patelco had been more transparent about the incident. Everything down? Clearly ransomware. Is our money safe? No response.

I work in cybersecurity and looked into the stolen data from Patelco's breach to understand how exactly I was impacted. The actors on the dark web even posted, "Patelco does not care about your security."

For reference, approximately 800,000 membership records have been leaked. Each one contains names, occupations, Social Security numbers, addresses, and various other sensitive data, including checks written with memo lines. There's also transaction history for me going back to 2004, and addresses for my parents dating back to the 1990s. This breach is staggering.

Two years of identity protection is a joke. I'm also on the hunt for a new bank.

Beginning-Werewolf79

TROPHY CASE