Email workspaceInternal wallet signup alert contract
Implementation: App\Mail\WalletCreatedMail. Baseline: resources/views/emails/WalletCreatedMail.blade.php. Usage: app/Http/Controllers/Wallet/WalletController.php:399 and WalletNGController.php:143. Static references are evidence, not proof of current production delivery.
Suggested subject: New wallet signup (existing). An HTML title does not set the mail header.
Suggested preheader: New wallet signup for {{business_name}}.
Placeholder contract
| Token | Existing source / derivation | Handling |
|---|---|---|
| {{logo_url}} | Original Built app_name PNG | Optional deployment override only; concrete public project HTTPS PNG is already present. Approved HTTPS or matching CID. |
| {{preheader}} | Suggested copy above; existing context only | Required escaped text; preserve the existing value. |
| {{business_name}} | $wallet->business_name mapped to business_name by the Mailable | Required escaped text; preserve the existing value. |
| {{admin_url}} | Existing https://xxxyydd234.builtaccounting.com/wallet-accounts/ + $wallet->id (legacy id view field) | Required server-built HTTPS URL on the approved Built super-admin host. Preserve the existing path and record ID, and validate before attribute escaping. |
Content and integration decisions
- Internal wallet operations audience; preserve the distinct existing routing in both controller paths. Both use send(); WalletCreatedMail does not implement ShouldQueue. Queueable trait alone does not queue it.
- Only business identity and wallet record destination are supplied. Do not add wallet balances, account numbers, KYC details, payment outcomes or approval claims. The draft explicitly says signup does not indicate approval.
- States: standard and long business/record reference. The button opens the current super-admin wallet record, not a customer wallet dashboard. Wallet provider involvement does not change ownership of this API-authored operational email.
Safe integration
Portable {{placeholder_name}} tokens are not automatically Laravel Blade variables. Prefer an explicitly mapped Blade view within the existing Mailable during later authorized integration; retain the current data, subject/header choices, queue behavior and recipients. No new templating framework is needed. ready/wallet-signup-alert.html and .txt are the standalone extracts; every fixture has HTML and text alternatives. No existing plain-text source was found for these five Markdown views; the supplied text alternatives are proposed equivalents.
Escape all dynamic text and attribute values. Validate each URL separately against the exact intended HTTPS host/path, then escape it. A contact email is text, not raw markup. Build admin URLs on the server from existing IDs; do not accept arbitrary externally supplied admin destinations. The shared logo defaults to https://built-storage.ams3.cdn.digitaloceanspaces.com/Built/app_name.png; for deployment host that original PNG over absolute HTTPS or attach it with a matching CID and preserve its aspect ratio. Retain assets/built-logo.png as the original source. Remote-image blocking is still possible.
Button and visible fallback share the same URL where a fallback exists; no legacy duplicate URL field is added. Apart from the explicitly marked accountant-pairing notice and optional contact fallback, all documented values are required. No optional block may leak unresolved tokens. Use one-pass replacement only if retaining portable tokens; do not evaluate inserted text or treat it as raw HTML.
Previews use fictional identities, reserved example.com contacts and inert local action explanations. No signup, booking, form submission or mail send happens in this workspace. Native dark-mode styles are progressive enhancement; browser QA does not establish Gmail, Outlook or iOS Mail compatibility.