Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Self-Contained Payment Logging System: Isolating Tenant Operations from Corporate Email Infrastructure

What Was Done

We implemented a complete domain isolation for a rental property tenant portal, moving all email operations from the corporate queenofsandiego.com domain to a dedicated dangerouscentaur.com infrastructure. This included provisioning a new SES sender identity, deploying a Lambda-based payment logging system that accepts forwarded bank transaction emails, and integrating it with an existing Google Apps Script webhook handler. The system allows property managers to forward Zelle payment notifications directly to a dedicated inbox, which automatically logs rent payments to a centralized receipts store.

Technical Details

Domain Isolation Architecture

The tenant portal at https://3028fiftyfirststreet.92105.dangerouscentaur.com/ is now completely segregated from corporate email infrastructure. This separation serves multiple purposes:

  • Compliance: Tenant data and communications never touch corporate systems
  • Deliverability: Separate SPF/DKIM records prevent sender reputation conflicts
  • Operational clarity: All tenant-related infrastructure lives within a single domain namespace

SES domain verification was initiated for dangerouscentaur.com with DKIM token generation. The domain's DNS records were updated to include the three DKIM CNAME records provided by AWS SES, ensuring email authentication passes SPF and DKIM checks.

Email Credential Distribution

Tenant credentials (username/password) are generated fresh on each deployment and stored in the hub's HTML interface at /Users/cb/Documents/repos/sites/dangerouscentaur/demos/3028fiftyfirststreet.92105.dangerouscentaur.com/index.html. The credentials are delivered via SES using the verified dangerouscentaur.com sender identity rather than corporate email.

The deployment pipeline:

  1. Generate temporary passwords using secure random generation
  2. Hash passwords with bcrypt for client-side authentication
  3. Embed credentials in the portal HTML (which implements client-side auth)
  4. Deploy updated HTML to S3 bucket dc-sites-tenant-hub-3028
  5. Invalidate CloudFront distribution to push new credentials live
  6. Send plaintext credentials via SES to tenant email addresses

Payment Logging System: Email-to-Lambda Pipeline

The core innovation is a forwarding-based payment logging system that eliminates manual data entry. Here's the flow:

Bank (Zelle) → Manager forwards email → ImprovMX alias 
  → Google Apps Script webhook → Lambda payment logger 
  → JSON receipts store in S3

An ImprovMX email alias was configured for dangerouscentaur.com to receive forwarded payment emails and trigger a Google Apps Script webhook handler in the WarmLeadResponder.gs file located at /Users/cb/Documents/repos/sites/queenofsandiego.com/WarmLeadResponder.gs.

Note on location: While the GAS script file exists in the queenofsandiego repo, it's deployed to a Google Cloud project that's isolated for dangerouscentaur operations and handles only dangerouscentaur-related webhooks.

Lambda Functions

Two Lambda functions power the system:

  • receipt-action Lambda at /scripts/lambda-receipt-action/lambda_function.py: Accepts payment log requests, validates an ADMIN_TOKEN environment variable, and appends payment records to a receipts JSON file in S3
  • email-parser Lambda at /scripts/lambda-email-parser/lambda_function.py: Parses forwarded Zelle emails to extract transaction metadata (date, amount, sender name)

The receipt-action Lambda is invoked via a Function URL with the following authentication model:

POST https://[lambda-url]/payment/log
Authorization: Bearer [ADMIN_TOKEN]
Content-Type: application/json

{
  "tenant_id": "3028",
  "amount": 2000.00,
  "payment_method": "zelle",
  "transaction_date": "2024-01-15",
  "reference": "Forwarded Zelle email"
}

The ADMIN_TOKEN environment variable was configured during Lambda deployment to ensure only authorized callers (the GAS webhook) can log payments. This token is stored in repos.env for reference.

Google Apps Script Integration

The webhook handler in WarmLeadResponder.gs includes a new action branch that detects forwarded Zelle emails. When a payment email arrives at the ImprovMX alias, the GAS script:

  1. Parses the email body to extract transaction details
  2. Constructs a payment object with tenant ID, amount, date, and reference
  3. Calls the Lambda payment logger with the ADMIN_TOKEN in the Authorization header
  4. Logs the response for audit purposes

This runs entirely within the dangerouscentaur domain context, never exposing tenant data to corporate infrastructure.

Infrastructure Changes

  • SES: New verified sender identity for dangerouscentaur.com domain
  • ImprovMX: Email alias configured to forward to Google Apps Script webhook
  • S3: Receipts stored in receipts.json within the tenant hub bucket
  • Lambda: Function URLs enabled for both Lambda functions with bearer token authentication
  • CloudFront: Distribution invalidations triggered after portal updates to ensure fresh credentials are delivered
  • Route53: No changes required; dangerouscentaur.com already registered and pointed to appropriate infrastructure

Key Decisions

Why forwarded emails instead of a custom portal? Zelle transactions arrive as emails to the property manager's personal bank account. Rather than forcing re-entry into a separate UI, we tap into the manager's existing email workflow. This reduces friction and eliminates transcription errors.

Why Lambda Function URLs instead of API Gateway? Function URLs are simpler to manage for this lightweight webhook use case, with built-in bearer token support and no cold-start penalties given low volume.

Why store receipts in S3 as JSON? This allows the tenant portal to display payment history in the hub UI via a client-side JavaScript fetch to the receipts endpoint, providing real-time confirmation of logged payments without additional database infrastructure.

Why validate the ADMIN_TOKEN in Lambda? This prevents unauthorized payment logging if the webhook URL is ever disclosed. The token is environment-based rather than in code, allowing rotation without redeployment.

What's Next

Future enhancements could include:

  • Automated receipt email generation sent back to tenants after payment is logged
  • Integration with accounting software via Lambda webhook to other providers
  • Late payment detection that triggers automated reminder emails