Skip to main content

March 4, 2026 — Redemption Strategy & RBAC

Date: Wednesday, March 4, 2026 Attendees: Dhruv, Ajay, Amitosh, Siddharth, Suraj, Mahima


Summary

Team confirmed Option A (code-based redemption) as the MVP approach. Introduced a new POS Operator RBAC role for cashier-level redemption verification. Deferred QR code scanning and direct POS discount API integration to later phases. Ajay to show a mini demo within one week.


Action Items

  • Dhruv to add RBAC layer documentation for POS Operator role
  • Ajay to provide mini demo within one week showing progress
  • Ajay to start development work on redemption feature
  • Mahima to send meeting invites immediately after calls to the correct email addresses
  • Mahima to prepare project plan tracker with all line items, timelines, and action items (with Ajay's help)
  • Mahima to post meeting links on WhatsApp for visibility
  • Ajay to share Figma design for team review and feedback
  • Suraj to ensure project tracker is created and maintained
  • Mahima to send test invite to new Outlook email address and confirm receipt via WhatsApp
  • Suraj to grant Amitosh and Dhruv access to Bitbucket repository
  • Mahima to share project plan on WhatsApp/Basecamp before next meeting
  • Team to reschedule future meetings to 10 PM EST / 8:30 AM India time

Key Decisions

Redemption Strategy — Option A Confirmed ✅

Team unanimously agreed to implement code-based redemption for the MVP phase:

  1. Customer generates a 6-character alphanumeric code (15-minute TTL) in the SalesArck app
  2. Customer shows the code to the merchant (on screen or verbally)
  3. Merchant/POS Operator enters the code on a simple verification page
  4. System displays customer name + discount amount
  5. Operator confirms and manually applies the equivalent discount at the POS register

Estimated verification time: ~30 seconds per transaction — deemed acceptable by the team.

Option B (POS Discount API) — Deferred

  • Direct POS integration would require developer access for each POS system
  • Estimated additional effort: 1–2 weeks per POS provider
  • Toast is expected to block the discount API approach
  • Square and Clover discount APIs exist but need more research
  • Option A is platform-agnostic, unlike closed loyalty systems (e.g., Lightspeed)

QR Code Scanning — Deferred

  • Web-based QR scanning is impractical — most merchants use laptops at register, which lack cameras
  • Mobile scanning possible but not aligned with current web-only approach
  • Will revisit when/if native applications are introduced

New RBAC Role: POS Operator

Amitosh identified the need for a limited-permission role for cashiers/associates:

  • Access: Redemption Verification Page only — no analytics, rules, POS settings, or other merchant portal features
  • UI: Simple search box → enter code → see customer name + discount amount → confirm
  • Redeem button: Grayed out if business rules not met (e.g., minimum point threshold)
  • Provisioned by: Client (merchant owner/manager) — designed for high employee turnover

Business Rules Enforced at Code Generation

All eligibility checks happen when the consumer requests the code, not at the merchant verification step:

  • If a consumer doesn't meet criteria (e.g., < 100 points), they cannot generate a code at all
  • If a code exists and is not expired, it is valid — POS Operator just confirms
  • This keeps the merchant-side flow fast and simple

POS Integration Challenges Discussed

  • POS systems restrict updating existing transactions — cannot reverse-post discounts
  • Canadian Tire analogy (raised by Siddharth): You can earn points at partner locations but can only redeem at Canadian Tire stores — similar to SalesArck's model where redemption lives within the SalesArck platform, not inside the POS
  • Each POS vendor has proprietary loyalty programs built into their platforms — SalesArck's approach must remain platform-agnostic
  • Deeper POS integration (Option B) would require white-glove service for each onboarding

Toast POS

Toast's API does not support programmatic discount creation on open orders. If Toast is a target integration, Option B will not work for Toast merchants. This reinforces Option A as the universal baseline.

Lightspeed

Lightspeed has a formal onboarding process — form submission → internal investigation → API access granted. Even with this deeper integration, they would not necessarily allow external redemption hooks. Closed system approach still applies.


Technical Updates

  • OAuth confirmed available on all major POS platforms (Square, Clover, Shopify, Lightspeed, Toast)
  • Documentation updated with code-based redemption approach and all four options documented
  • DocuSaurus documentation site now has search functionality
  • MCP server access discussed — Ajay's team doesn't currently have access; Dhruv suggested using it to load documentation context into code editors

Project Management & Communication

  • Immediate communication: Team to use WhatsApp for questions/roadblocks — don't wait for meetings
  • Project tracker requested: Excel-based project plan with all tasks, timelines, roadblocks, and risks
  • Current gap: No visibility into what has been completed — everything is verbal
  • Meeting invites: Mahima's invites not appearing in Outlook calendars — new email address shared; will test with WhatsApp confirmation
  • Meeting time change: Moving to 10 PM EST / 8:30 AM India time starting next week
  • Daylight saving time change expected in ~1 week, which will shift the offset

Development Status

  • Ajay confirmed no immediate roadblockers to start development
  • Design and integration work already in progress (Figma)
  • Architecture, multi-tenant approach, token storage, and integration details all understood
  • Two additional developers being added alongside Ajay
  • One-week demo target agreed upon
Written byDhruv Doshi