Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Self-Contained Payment Logging System: Isolating Tenant Operations from Primary Domain Infrastructure

Overview

This session involved a critical architectural decision: complete domain isolation for a rental property management system. The tenant hub at 3028fiftyfirststreet.92105.dangerouscentaur.com needed to operate entirely within the dangerouscentaur.com domain namespace, with its own credential delivery, payment logging, and email infrastructure—completely divorced from the primary queenofsandiego.com domain.

The Problem: Cross-Domain Contamination

Initial implementation made a critical mistake: tenant credential emails were sent from the queenofsandiego.com domain. This violated several architectural principles:

  • Mixed concerns: a commercial real estate brand (queenofsandiego.com) was managing a specific property's tenant operations
  • Authentication risk: credentials in emails from an unexpected domain increases phishing skepticism
  • Operational clarity: tenants shouldn't see infrastructure plumbing details about how their property management works
  • Future scalability: property-specific operations need to scale independently without domain entanglement

Technical Implementation

1. Email Domain Isolation via SES and ImprovMX

The solution required setting up proper email infrastructure within the dangerouscentaur.com namespace:

AWS SES verified domain: dangerouscentaur.com
ImprovMX alias configuration for receive/forward capability
Sender email: noreply@dangerouscentaur.com (or property-specific alias)

This involved:

  • Initiating SES domain verification for dangerouscentaur.com
  • Retrieving DKIM tokens from AWS and configuring them in the domain's DNS records
  • Setting up ImprovMX aliases to handle inbound email forwarding (critical for the Zelle payment logging system)
  • Testing SES sender authentication before deploying credential emails

The why here is crucial: SES requires domain verification to prevent spoofing. ImprovMX acts as a lightweight mail relay, allowing us to forward incoming payment notifications to Lambda functions without managing a full mail server.

2. Tenant Credential Regeneration and Secure Distribution

Files modified:

  • /repos/sites/dangerouscentaur/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html – Updated with fresh temporary passwords and hash storage
  • S3 upload to CloudFront-backed bucket serving the tenant portal

Process:

# Generate temporary credentials with cryptographic randomness
# Hash passwords using bcrypt (client-side validation)
# Update tenant hub HTML with new access tokens
# Deploy to S3 and invalidate CloudFront distribution cache
# Send credentials via SES from dangerouscentaur.com domain

CloudFront distribution invalidation was critical here—we needed /* path invalidation to ensure all users received the updated credentials immediately, preventing cache poisoning where old credentials remained accessible.

3. Payment Logging Pipeline: From Email to Database

This is where the architecture gets sophisticated. The requirement was to create an "sexy" payment logging system that doesn't require manual data entry.

Components:

  • ImprovMX forwarding: Incoming Zelle notifications forwarded to a dedicated email address
  • Lambda email parser: /repos/sites/dangerouscentaur/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/scripts/lambda-email-parser/lambda_function.py – Parses incoming email, extracts payment metadata
  • Receipt action Lambda: /repos/sites/dangerouscentaur/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/scripts/lambda-receipt-action/lambda_function.py – Handles authenticated payment logging via REST API
  • Google Apps Script: WarmLeadResponder.gs – Command router for payment events, triggers Lambda calls
  • S3 receipts storage: receipts.json maintained as the source of truth for payment records

4. Admin Token Security Pattern

A critical security decision: the log_payment action in the receipt-action Lambda requires an admin token passed via environment variable:

Lambda environment variable: ADMIN_TOKEN (randomly generated, 32-char minimum)
Token validated before processing payment log requests
Token stored in repos.env (local development) and Lambda configuration (production)

This prevents unauthorized payment logging while allowing the GAS script to authenticate admin actions. The token was added to production Lambda configuration and referenced from a secure environment file, never committed to version control.

5. Google Apps Script Command Handler Integration

The GAS script was updated to detect forwarded Zelle emails and trigger payment logging:

// In WarmLeadResponder.gs
// Detect Zelle/payment email content
// Extract sender, amount, timestamp
// Call log_payment Lambda with ADMIN_TOKEN
// Update receipts.json via Lambda response
// Send confirmation to tenant portal

Why GAS instead of direct Lambda-to-S3? GAS provides a consistent command router across the queenofsandiego.com and dangerouscentaur.com infrastructure. By routing through GAS, we maintain a single audit log of administrative actions while keeping domain boundaries clean.

Infrastructure Architecture

dangerouscentaur.com
├── SES verified domain (DKIM/SPF configured)
├── ImprovMX aliases
│   └── payments@dangerouscentaur.com → Lambda email parser
├── S3 bucket
│   ├── /3028fiftyfirststreet.92105/index.html (tenant hub)
│   └── /3028fiftyfirststreet.92105/receipts.json (payment log)
├── CloudFront distribution
│   └── Custom domain: 3028fiftyfirststreet.92105.dangerouscentaur.com
├── Lambda functions
│   ├── lambda-email-parser (triggered by SES → SNS)
│   └── lambda-receipt-action (REST endpoint with function URL)
└── Route53 hosted zone
    └── DNS records for domain verification

Key Decisions and Rationale

  • Complete domain isolation: Rather than sharing queenofsandiego.com infrastructure, each property gets its own subdomain. This scales to multiple properties without cross-contamination.
  • Email forwarding over direct integration: Using ImprovMX instead of polling an inbox reduces operational complexity and gives us a standard webhook pattern (SES → SNS → Lambda).
  • S3 receipts.json as source of truth: Rather than a database, receipts are stored as JSON in S3. This is query-friendly, version-controlled via git, and auditable through S3 versioning.
  • Admin token for Lambda actions: Prevents unauthorized payment modifications while keeping the Lambda URL public-facing (required for GAS invocation from Google's infrastructure).
  • CloudFront cache invalidation on credential updates