Handling Stripe Identity OCR name mismatches in Bubble – real-world approaches?

I am currently building a user-verification-heavy application entirely in Bubble. For real-name validation we’re using the official Stripe Identity plugin (via VerificationSession + report retrieval).

Like many others here, I’ve run into the well-documented reality that Stripe Identity’s OCR (and all OCR tech) occasionally misreads or misses characters on ID documents. Independent research commonly estimates this happens in 1–5 % of cases for name fields. In my own controlled test of ~50 varied international IDs I hit exactly one mismatch, which matches the lower end of that range.

My current production flow is straightforward and user-friendly:

  • After the Stripe verification completes, the user is shown the extracted name and asked to type it exactly as it appears on their physical ID.
  • Exact match → user is verified.
  • Mismatch → user is asked to re-enter the name as written on the ID.
  • If they confirm the second entry is correct but still doesn’t match Stripe’s output → we automatically create a fresh VerificationSession (I absorb the extra cost).

The flow works reliably, but I’m looking for more scalable or lower-cost patterns as volume grows.

A few specific questions for the community:

  1. How are you handling OCR-induced name mismatches in Bubble today? (fuzzy matching via JavaScript, custom elements, option sets, or external services?)
  2. Any tips or gotchas when working with the Stripe Identity report data inside Bubble workflows or repeating groups?
  3. Have you implemented a lightweight manual-review queue for the 1–5 % edge cases that doesn’t require leaving Bubble?

I’m happy to share screenshots of the current flow or the exact workflow JSON if it helps the discussion.

Looking forward to your thoughts

Yeah, you could send the JSON