---
title: Didion Golf Sponsorship — Gravity Forms E-Commerce Redesign
type: article
created: '2026-04-05'
updated: '2026-04-05'
source_docs:
- raw/2026-01-22-didion-meet-116503456.md
tags:
- wordpress
- gravity-forms
- paypal
- php
- ecommerce
- sponsorship
- didion
- gravity-whiz
- webhook
layer: 2
client_source: null
industry_context: null
transferable: true
---

# Didion Golf Sponsorship — Gravity Forms E-Commerce Redesign

## Overview

Didion's annual golf tournament previously used 25+ individual Gravity Forms — one per sponsorship level. This article documents the decision to consolidate into a single e-commerce-style form, the technical challenges encountered, and the resolution of a blocking PayPal webhook misconfiguration.

**Client:** [[wiki/clients/didion/_index|Didion]]
**Key Contact:** Diana Henry (dhenry@didioninc.com)
**Team:** Isahaque Mahmud, Melissa Cusumano

---

## The Problem with the Old Approach

- 25+ separate forms, one per sponsorship level, created maintenance overhead and a fragmented user experience.
- Payment processing was previously handled by Square; the switch to PayPal introduced a webhook misconfiguration that blocked transactions.
- No centralized quantity tracking existed across sponsorship types.

---

## New Form Architecture

### Core Concept

Replace all individual forms with **one Gravity Forms e-commerce flow** that behaves like a shopping cart:

1. User selects a sponsorship level from a product dropdown.
2. The associated price auto-populates into a running cart total.
3. Optional add-ons (e.g., golf ball toss) can be added to the same transaction.
4. User checks out via PayPal in a single payment.
5. Form captures required attendee/golfer information in the same submission.

### Required Fields & Behaviors

| Feature | Notes |
|---|---|
| Sponsorship level selector | Product dropdown with label + price per option |
| Dynamic cart total | Updates as selections are made |
| Quantity tracking | "X of Y remaining" per sponsorship level; "Sold Out" when exhausted |
| Unlimited quantity support | Some levels have no cap |
| PayPal checkout | Live (not sandbox) connection via Gravity Forms PayPal add-on |
| 2.9% fee pass-through | Optional: pass PayPal transaction fee to purchaser, as was done previously with Square |

---

## Technical Implementation Notes

### Product Field vs. Standard Dropdown

Gravity Forms requires a **Product field** (not a standard dropdown) to associate prices with selections and feed them into a payment total. The field type should be set to **Dropdown** within the Product field options.

- Label and price can be set per choice within the product field editor.
- A standard dropdown cannot drive payment calculations natively.

### Quantity Tracking — The Core Challenge

> "The native Gravity Forms quantity field is for a single product, not for tracking multiple, distinct sponsorship options within a dropdown." — Isahaque Mahmud

The built-in Gravity Forms **Quantity field** (found under Pricing Fields) maps to a single product. It does not support per-option inventory tracking across a multi-choice product dropdown.

**Two paths under evaluation:**

1. **Custom PHP code** — Write logic that tracks submission counts per sponsorship choice against a defined maximum, then dynamically marks options as sold out or appends remaining count to the label.
2. **Gravity Whiz add-on** — Diana installed this plugin based on research suggesting it may offer a no-code or low-code alternative for quantity limiting. Isahaque to evaluate whether it covers the multi-option use case.

**Status:** Under active research. Isahaque committed to a status update within one business day of the meeting.

### Sponsorship Quantity Reference (Sample)

Some levels have a quantity of 1, others up to 18, and some are unlimited. The implementation must handle all three cases gracefully.

---

## PayPal Webhook — Problem & Resolution

### Root Cause

The PayPal webhook registered in Gravity Forms settings was a **sandbox webhook URL**, not a live one. This was copied over from a sandbox testing session and never replaced, causing payment processing to fail on the live site.

### Fix Applied (During This Meeting)

1. Diana navigated to **Gravity Forms → Settings → PayPal**.
2. Disconnected the existing PayPal connection.
3. Reconnected using the **live** PayPal account credentials (not sandbox/developer mode).
4. The new live webhook was automatically registered.

**Result:** Webhook status now shows **Active**. Payment processing is unblocked.

> "Maybe the roadblock was happening when I was trying to add the sandbox webhook instead." — Diana Henry

### Lesson

When switching from sandbox to production in Gravity Forms PayPal add-on, a full **disconnect → reconnect** cycle is required to replace the webhook URL. Manually editing the webhook ID in settings does not work.

---

## Action Items

| Owner | Task | Due |
|---|---|---|
| Isahaque | Research quantity tracking: evaluate Gravity Whiz vs. custom PHP | Next day |
| Melissa | Text Diana with Isahaque's update (email delivery unreliable) | Upon receiving update |
| Isahaque | Confirm live PayPal webhook is functioning end-to-end | Next day |

---

## Related

- [[wiki/clients/didion/_index|Didion Client Overview]]
- [[wiki/knowledge/wordpress/gravity-forms-paypal-webhook-sandbox-live|Gravity Forms PayPal: Sandbox vs. Live Webhook]]