--- title: WI Masons Bonterra + Stripe Integration Roadmap type: article created: '2026-04-05' updated: '2026-04-05' source_docs: - raw/2025-12-11-wi-masonic-website-call-108177736.md tags: - client/wi-masons - crm-automation - stripe - bonterra - woocommerce - webhooks - grant-management - ach layer: 2 client_source: null industry_context: null transferable: true --- # WI Masons Bonterra + Stripe Integration Roadmap ## Overview The Wisconsin Masonic Foundation is building toward a fully automated grant purchase-to-fulfillment pipeline by connecting their Stripe payment account with Bonterra (their CRM/donor management platform). The near-term implementation uses a WooCommerce store with Stripe and a two-step capture flow; the longer-term goal is to have Bonterra consume Stripe transaction data directly, eliminating manual data entry and reducing the foundation's 1.5-person staff burden. This article documents the planned architecture, the constraints driving design decisions, and the open integration work remaining. --- ## Current State (Pre-Integration) - **Payment processor:** Square (no ACH support) - **Grant fulfillment:** Manual — lodges photograph a check, mail it in, staff deposits it and contacts FSS (the fulfillment supplier) separately - **CRM:** Bonterra (used for grant tracking and donor records) - **Email:** `wimasons.foundation` domain forwarded through Google → quarantined by Grand Lodge's Office 365 Pain points: - Square cannot process ACH payments, forcing lodges to use paper checks - No automated notification to FSS when a grant is approved - Every matching grant form submission arrives in Office 365 quarantine due to Google forwarding - Staff must manually reconcile grant applications with payments --- ## Target Architecture ``` Lodge fills out grant form (WooCommerce / existing grant form) └─> Stripe captures payment (reserves funds, does not charge) └─> Staff reviews grant eligibility └─> Staff completes charge in Stripe └─> Stripe webhook fires ├─> Email to FSS (Rick) → triggers product shipment ├─> Email to foundation staff (Adam, Erica, Christina) └─> [Future] Bonterra receives transaction via Stripe integration └─> Grant record auto-updated in CRM ``` --- ## Key Design Decisions ### Two-Step Stripe Capture Flow Rather than auto-charging on form submission, the store uses Stripe's **authorize-and-capture** pattern: 1. Lodge submits grant form and provides payment details 2. Stripe **captures** (authorizes/reserves) the funds — no money moves yet 3. Foundation staff reviews the grant for eligibility and budget compliance 4. Staff manually **completes** the charge in Stripe 5. Webhook fires, notifying FSS and sending confirmation emails **Rationale:** Grant rules are complex and frequently changing — medical grants cap at $3,000, all others at $1,000, and per-lodge annual maximums apply. Full automation would require encoding all these rules in code that would need constant maintenance. The two-step flow preserves human oversight while still automating the fulfillment notification step, saving significant staff time vs. the current all-manual process. > *"It's just somebody going through and clicking through the screen and making sure everything's okay is all it really is."* — Peter Tourville ### ACH via Stripe (replacing Square) Square does not support ACH payments, which is the preferred payment method for lodge-to-foundation transfers. Stripe supports ACH natively. Adam Rigden has already built Stripe payment links for the initial product set (AED, FST, Jump Bag) with ACH enabled. ### Webhook-Driven Fulfillment Notifications Adam identified the need for a **webhook endpoint URL** on the Stripe account to trigger outbound emails on payment completion. The webhook listener will fan out to: - FSS contact (Rick) — fulfillment trigger - Foundation staff (Adam, Erica, Christina) — internal record This replaces the current process where staff must manually contact FSS after verifying a check. ### Bonterra Integration (Planned, Not Yet Active) Bonterra Pay is planning a native Stripe integration. Once available, completed Stripe transactions will flow directly into the Bonterra CRM, automatically updating grant records without manual data entry. This is the primary long-term automation goal. > *"The purchases will go right into the CRM. So it's taking people out of the process."* — Adam Rigden --- ## Store Scope The WooCommerce store will be small by design: | Product | Notes | |---|---| | AED (Automated External Defibrillator) | Price pending board approval | | FST (First Aid/Safety Kit) | Pre-approved grant item | | Jump Bag | Pre-approved grant item | | Additional items | < 10 products total at launch | The store is **not** intended for general public purchase. Access control approach: grant form as a natural gate (general public will not complete a lodge grant application), plus lodge number as a required field. Full password-protected login was discussed but deferred given the operational overhead of managing lodge credentials. --- ## Open Work Items | Item | Owner | Status | |---|---|---| | Connect Adam's Stripe account to WooCommerce (requires joint call for 2FA) | Mark + Adam | Pending — Adam to schedule after knee surgery recovery | | Send Stripe payment links + product details (AED, FST, Jump Bag) to Mark | Adam | Pending | | Configure webhook endpoint URL in Stripe | Mark / Adam | Pending — depends on Stripe Connect call | | Build WooCommerce store ($2k setup) | Mark / assigned developer | Pending proposal acceptance | | Monitor Bonterra for Stripe integration GA release | Adam | Ongoing | --- ## Related Constraints & Context - **Staffing:** Foundation operates with ~1.5 FTE. Any solution must reduce, not add, manual steps once implemented. - **Grant rule complexity:** Rules change frequently (dollar caps, match ratios, eligible categories). Hard-coding them in automation logic is fragile; the two-step capture flow is the pragmatic alternative. - **Regulatory separation:** `wimasons.foundation` domain is intentionally separate from `wimasons.org` (Grand Lodge) to maintain IRS charitable status distinction. This affects email routing and branding decisions. - **Email quarantine (interim):** Until the MX record migration to Office 365 is complete, Peter will whitelist the website's sending address (`peter@wimasons.com`) in Office 365 Security settings to stop immediate quarantining of grant form submissions. --- ## Related Articles - [[clients/wi-masons/_index]] - [[meetings/2025-12-11-wi-masonic-website-call]] - [[knowledge/ecommerce/woocommerce-stripe-authorize-capture-pattern]] - [[knowledge/email/office365-mx-migration]]