What happens to your Aadhaar after you upload it

There is a moment in every verification flow where a reasonable person stops and thinks: who exactly is on the other end of this upload?

Usually you get no answer. A spinner, a green tick, and a vague sense that your Aadhaar is now in a folder somewhere with a name like `uploads/`. So here is the answer for us, in more detail than is strictly comfortable.

Why we ask at all

We do not need your identity to let you take bookings. We need it to send you money. Payouts are where a booking platform becomes a target: the fraud is not fake appointments, it is a real-looking account collecting real money into a stranger's bank. Verification is the gate on the payout, and nothing else.

This is why withdrawal is blocked until verification is approved, and why nothing else is.

Where the numbers go

Your PAN, Aadhaar and account number are encrypted before they are stored, with AES-256-GCM, under a key that lives only in the server environment. What sits in the database is ciphertext. Somebody with a copy of the database and no key has a column of noise.

The GCM part matters more than the 256. It authenticates as well as encrypts, so tampered ciphertext fails to decrypt instead of quietly producing a different number. You want that property on a bank account field.

Where the documents go

Not in the same place as your profile photo. Images on Book A Sloth live in a public bucket, because they are meant to be looked at. Your Aadhaar goes into a separate private bucket with no public access and no policies granting any browser-side role a single byte of it.

The only way a document leaves that bucket is a short-lived signed URL, minted server-side, for an admin who is reviewing your submission. There is no permanent link. There is nothing to leak into a referrer header or a screenshot of a URL bar.

What our own staff can see

This is the part most platforms skip.

Our admins cannot read your Aadhaar number. Not "should not" — the review screen shows it masked, the same as it shows you. Verification is done by looking at the document image and checking it against the masked digits, which is enough to confirm a person is who they say they are, and is not enough to reconstruct the number from a support desk.

Reviewing a submission requires a specific permission that most admin roles do not carry, and every decision is attributed to the admin who made it.

The test of a data-handling promise is not what your policy says. It is what your own support team physically cannot do.

The bit we care about

What we chose not to build

No re-upload diffing on rejection — if a submission is rejected you send the whole thing again, which is worse for you and simpler for us, and simpler is the thing we can keep correct. And no admin can approve a payout to an account that was not verified against the document, because the two are the same record.

None of this is impressive. Encryption at rest, a private bucket, masked reads, scoped permissions. It is the boring floor, not a ceiling. The reason it is worth a post is that the floor is where most of the failures actually happen, and nobody writes about the floor.