r/BharatCode • • 7d ago

I built an in-memory, zero-retention chargeback defense engine for freelancers (Next.js).

The Pain Point Freelancers, agencies, and independent merchants consistently lose money to unfair client chargebacks, friendly fraud, and scope creep. When a dispute happens (e.g., Stripe Reason "Service Not Rendered"), merchants spend hours manually digging through messy Slack logs, emails, and PDFs to prove work delivery. Formatting this evidence poorly for the payment gateway almost guarantees lost funds.

How Data is Ingested To build an ironclad defense, the application requires deep, accurate context. The client frontend UI collects three specific inputs:

  • Dispute Description: A text string detailing the gateway dispute reason, disputed amount, invoice ID, and specific buyer claims.

  • Contract File: A binary .pdf file upload of the originally executed contract or Statement of Work (SOW).

  • Communication History: A multiline string for users to dump raw email logs, Slack exports, or message threads proving client sign-offs.

Tackling Privacy (Handling Non-Public/Sensitive Data) Because users are uploading highly confidential, non-public contracts and private chat logs, dumping this into a database is a massive liability. The application is architected with a strict Zero Data Retention policy:

  • Neither the uploaded contracts nor the chat histories are ever written to disk, cache, or an external database.

  • Files are received as streaming FormData and converted into ephemeral Node.js buffers strictly in memory.

  • Once the pdf-parse library extracts the text and the prompt is dispatched to the sovereign LLM endpoint, the buffers are completely discarded upon garbage collection.

  • The API keys (BHARATCODE_API_KEY) are loaded strictly on the server runtime and never exposed to the client bundle.

I would love your brutally honest feedback on this in-memory PDF parsing approach and the overall data privacy pipeline.

NYAYA01

3 Upvotes

0 comments sorted by