India Readiness Checklist (Work Package E)¶
Engineering/compliance gap checklist for an India-wide Vayzo launch - not final legal advice. Legal/regulatory wording and final compliance sign-off must come from India-qualified legal/CA review, per the tranche brief.
SMS DLT (Distributed Ledger Technology) - TRAI requirement¶
India's telecom regulator (TRAI) requires every commercial SMS sender to register on a DLT platform (one of the licensed DLT operators) before sending any SMS, transactional or promotional:
- Entity registration: Vayzo (the business entity) registers once with a DLT operator.
- Header registration: a 6-character sender ID (e.g.
VAYZOM) registered and approved. - Template registration: every SMS template (not just its category) must be pre-registered and approved, with variable placeholders in fixed positions - an SMS provider will reject (or India's carriers will block) any message that doesn't exactly match a registered template's shape.
- Gap: nothing in this codebase has a template-identifier concept for SMS yet -
SmsNotificationChannelis still a bare no-op with no template model at all. A real SMS integration needs a per-type template-ID mapping (mirroringEmailTemplateCatalog.IsEmailWorthy's allowlist shape, but storing provider template IDs, not rendering free-form HTML).
WhatsApp customer opt-in¶
Meta's WhatsApp Business Platform requires explicit, verifiable opt-in before a business can message a customer - silently starting to send WhatsApp because a customer placed an order is not sufficient; opt-in must be a distinct, recorded action (e.g. a checkbox at signup/checkout, not pre-checked).
- Gap:
Userhas no opt-in/consent field for any channel. This must exist and be checked before any WhatsApp send, not just as a UI checkbox but as enforced application state.
Template-based outbound WhatsApp¶
Outside a 24-hour customer-service window, WhatsApp Business messages must use a pre-approved
message template (submitted to Meta for review, category-classified as UTILITY/MARKETING/
AUTHENTICATION). A transactional order-shipped notification would be UTILITY; free-form text is
not usable for proactive business-initiated messages.
- Gap: same template-ID concept as SMS above - needs its own catalog, its own review/approval lifecycle tracking (a template can be rejected or later disabled by Meta), separate from Email's free-form HTML.
Notification consent/preferences¶
Neither channel-level (email/SMS/WhatsApp on-off) nor type-level (which notification types) user preferences exist today - see Production Communications "Deferred work". Every enabled channel currently applies uniformly to every recipient. This is acceptable for Email (implemented behind two independently-off-by-default flags in this tranche) but is a hard blocker for WhatsApp specifically (opt-in above) and a compliance expectation for SMS/marketing more broadly.
English-first localization, future language support¶
- Every existing notification
Title/Messageis English-only, generated as fixed strings in the triggering command handler - no locale parameter exists anywhere in the notification pipeline. Userhas no locale/preferred-language field.- For India specifically, a future localization pass would need at minimum Hindi and the languages of Vayzo's actual seller/customer base - not attempted in this tranche (English-first is the stated decision).
Unsubscribe / marketing vs transactional distinction¶
- Every notification wired in this tranche is transactional (order/return/shipment/settlement state changes a customer/seller directly caused or is owed information about) - none is marketing/promotional. The email templates say so explicitly ("This is a transactional email about your Vayzo account activity").
- Indian law (and CAN-SPAM/most jurisdictions generally) distinguishes transactional mail - which
does not legally require an unsubscribe mechanism the way marketing mail does - from promotional/
marketing mail, which does. This distinction must be preserved going forward: if a future
marketing/promotional notification type is ever added, it needs its own opt-out mechanism and
must never be silently folded into the transactional
EmailNotificationChannel/EmailTemplateCatalog.IsEmailWorthyallowlist used in this tranche. - No unsubscribe link exists in this tranche's templates - correct, given everything sent is transactional; would become a legal gap the moment a marketing notification type is introduced without one.
Summary table¶
| Requirement | Status | Blocking for |
|---|---|---|
| SMS DLT entity/header/template registration | Not started - no SMS vendor selected yet | Any real SMS send |
| WhatsApp explicit opt-in (application-enforced) | Not implemented (User has no consent field) |
Any real WhatsApp send |
| WhatsApp/SMS template-ID catalog + lifecycle tracking | Not implemented | Any real WhatsApp/SMS send |
| Notification consent/preferences (per-channel, per-type) | Not implemented (pre-existing gap) | WhatsApp (hard blocker); best-practice for SMS |
| English-first localization | Current state - matches stated decision | N/A for this tranche |
| Transactional vs marketing distinction preserved | Correct today (everything wired is transactional) | Must be maintained by every future addition |