Cash-advance application notice — provider

Source: App\Mail\RequestFunds, app/Mail/RequestFunds.php; resources/views/emails/requestfunds.blade.php, using mail::message and mail::button. Subject: Request For Cash Advance (unchanged). Suggested preheader: Loan/cash-advance application from {{business_name}}.

Required portable values

Token	Existing source / derivation	Handling
{{provider_name}}	service['name'] from OfferService	Escaped provider greeting, not applicant name.
{{business_name}}	request.business_details['business_name']	Escaped submitted business identity, also the native From display. Not automatically current Business.name.
{{request_url}}	'https://partner.built.africa/requests/' . FundRequest.id	Complete original request URL. Preserve ID as text and validate approved HTTPS partner host/path separately. Do not substitute request UUID, an approval URL or another record.
{{app_name}}	config('app.name')	Escaped original Thanks sign-off.
{{preheader}}	Suggested source-derived summary above	Escaped text; no approval/disbursement claim.

Default logo/optional {{logo_url}} and footer CID/approved HTTPS requirements: [shared-footer](../shared-footer.md). No optional body section or legacy duplicate link field exists. The button and visible fallback share one request_url. All values remain required; missing request/provider/business data needs an explicit adapter decision rather than a fabricated link or identity.

Trigger, recipient and headers

OffersController::register, app/Http/Controllers/FinancialServices/OffersController.php:register, route POST requestfunds (routes/api.php:1449), validates the application, uploads an optional business certificate, saves FundRequest and creates PartnerBusinessReference. It constructs data business/service/request and queues this email at :177. To = service_provider.business_email, CC = service_provider.email, with the existing internal BCC. Preserve all native recipient/header policy; do not move CC/BCC addresses into body or sample data.

From is config(mail.from.address) with request.business_details.business_name. There is no Mailable Reply-To override. Preserve queue(), subject, the submission/record ordering and existing error handling. Queueable alone is not the usage evidence; the explicit caller is. Underlying transport/outbox remains separate from Laravel queue behavior. No business PDF or attachment is configured.

The provider receives a short notification and partner-portal action, not all personal/guarantor/application details stored in FundRequest. Those remain behind the source request link. The data object has nested casts for personal_info/business_details/request_details/guarantor_details; do not scrape application views or expose additional financial/personal fields in this email. An application notice is not approval or funding.

Native integration and safety

Use the existing Mailable with a complete HTML Blade view and proposed plain-text alternative. Portable {{placeholder_name}} tokens are not automatically Blade variables; do not nest the document in mail::message or add a framework. Escape all dynamic text/attributes; validate request/logo URLs separately and use one pass if replacing tokens. The source destination is the Built partner portal, not the applicant's external Fido app. There are no legacy duplicate URL values to reconcile.

Three fictional states cover submitted, supplied ID 0 as a mapping/rendering check and long values. ID 0 does not claim a valid persisted application exists. Files: public/ready/financing-provider-request.html/.txt and previews/financing-provider-request-*.html/.txt. No separate project-owned plain-text source found. Previews have inert local links; no real record/provider action, email or portal request is made. Browser rendering does not verify portal authorization, Gmail/Outlook/iOS Mail, actual CID delivery or current production sending.