Code Reference
Visualforce Reference#
The only Visualforce in the package. Everything else is Enhanced LWR; these exist only because Stripe.js needs a real page to redirect back to after an off-platform 3DS/bank-auth step.
Generated file
Don't hand-edit this page — add a <!-- doc: ... --> comment inside the .page markup and rerun the generator.
Stripe Payment#
stripePayment.page
API 67.0 · controller StripePaymentPageController
The Stripe Elements host, loaded inside an iframe embedded by dfForm (the public donation form LWC) and by publicDonorDashboard (wallet "add card" flow). Nothing here talks to Apex directly beyond the controller's allowedOrigin fallback — the payment flow is entirely postMessage-driven: the parent posts INIT_STRIPE (mount Elements from a clientSecret already created server-side), then CONFIRM_PAYMENT or CONFIRM_SETUP to trigger the charge/save. CONFIRM_PAYMENT carries an isRecurring flag: dfForm always sends CONFIRM_PAYMENT (the donation flow only ever mints a PaymentIntent, never a SetupIntent, even for recurring — see DonationService.createDonorAndIntent's setupFutureUsage=off_session), and on success this page replies SETUP_SUCCESS+paymentMethodId for a recurring signup or PAYMENT_SUCCESS for a one-time gift. CONFIRM_SETUP is for the donor-dashboard's genuine SetupIntent ("add a new card" without charging) flow only. This page never sees raw card data — Stripe.js tokenizes inside its own nested iframe, so only paymentMethod.id-shaped results ever leave this page, satisfying the PCI rule documented in AGENTS.md.
reportHeight()/ResizeObserver exist because the parent LWC has no visibility into this iframe's content height and Stripe's Payment Element resizes itself as the donor picks a payment method (card vs bank vs wallet); without this the iframe would either clip the form or leave dead whitespace. buildReturnUrl() derives the sibling stripePaymentReturn.page URL from window.location.href rather than a hardcoded path so it keeps working whether this page is served from the org domain or an Experience Cloud site's VF page prefix.
Stripe Link is switched off on the Payment Element (wallets.link='never'), so donors never see the "Save my information for faster checkout" enrolment box or Link's bank-funded payment path. Link is a wallet rather than a PaymentIntent payment method, so it cannot be excluded server-side the way ACH is (StripeGateway pins every intent to payment_method_types[]=card) — this Element option is the only place it can be turned off in code, short of disabling Link for the whole account in the Stripe Dashboard.
Stripe Payment Return#
stripePaymentReturn.page
API 67.0 · controller StripePaymentReturnController
Stripe's own redirect target after an off-platform step (3DS challenge, bank-auth redirect) that stripePayment.page's confirmPayment/confirmSetup calls can trigger even with redirect: 'if_required' — most flows resolve inline and never hit this page at all. Because the browser top-level navigation (not the iframe) is what Stripe redirects, this page has to work in two different contexts: reloaded top-level after a full-page bank redirect (shows the status card + a View Receipt link) or reloaded inside the original iframe if the donor's browser preserved it (posts the result back to the parent LWC via PARENT_ORIGIN, same postMessage contract as stripePayment.page).
The 'processing' PaymentIntent/SetupIntent status is intentionally treated as success in the UI copy — this package has no Stripe webhook endpoint (see specs/06-stripe-integration.md), so an async bank payment is actually finalized later by StagingReconciliationBatch/StripePaymentSweep polling Donation_Staging__c, not by this page. Telling the donor "processing" would be accurate but confusing right after they just completed checkout.