---
title: Gravity Forms + PayPal Integration with Conditional Logic
type: article
created: '2026-04-05'
updated: '2026-04-05'
source_docs:
- raw/2025-12-04-didion-marketing-call-106355051.md
tags:
- gravity-forms
- paypal
- wordpress
- payment-forms
- conditional-logic
- integrations
layer: 2
client_source: null
industry_context: null
transferable: true
---

# Gravity Forms + PayPal Integration with Conditional Logic

## Overview

When a WordPress site needs to collect user information *and* process variable-amount payments through PayPal, the cleanest approach is a **single Gravity Form with conditional logic** that routes to the appropriate PayPal payment based on the user's selection. This avoids adding new plugins, centralizes data collection, and keeps the backend manageable.

This pattern emerged from work with [[clients/didion/index|Didion]], where the existing Square/WP EasyPay setup could not integrate with PayPal, and standalone PayPal buttons failed to capture the contact and purchase information needed for fulfillment.

---

## The Problem This Solves

Payment workflows for events or partnerships often have two competing needs:

1. **Information capture** — who is paying, what they're buying, contact details for invoicing and follow-up
2. **Payment processing** — routing the correct dollar amount to the payment processor based on what was selected

A naive approach splits these into two separate steps (a form, then a payment button), or creates one form per product/tier. Both create friction and data fragmentation.

**WP EasyPay** does not support PayPal as a payment gateway, so sites using it cannot simply swap in a PayPal button without rebuilding the forms. Standalone PayPal buttons (generated from the PayPal dashboard) handle payment but capture no structured contact data on the WordPress side.

---

## Recommended Pattern

### Single Form, Conditional Payment Routing

Build **one Gravity Form** that:

1. Collects all required contact/company information (name, company, email, etc.)
2. Presents a dropdown or radio selection for the product/partnership tier
3. Uses **conditional logic** to show the correct PayPal payment field or redirect based on the selection

```
User fills out contact fields
    ↓
User selects partnership tier (e.g., Birdie, Eagle, Title Sponsor)
    ↓
Conditional logic fires:
    - If "Birdie" → trigger PayPal payment for $X
    - If "Eagle"  → trigger PayPal payment for $Y
    - If "Title"  → trigger PayPal payment for $Z
    ↓
Submission captured in Gravity Forms entries
PayPal payment initiated
```

### Why Gravity Forms (Not WP Forms Premium)

- If Gravity Forms is already installed on the site, use it — avoid adding a new plugin
- Gravity Forms supports PayPal Add-On for payment routing
- All submissions are stored in the Gravity Forms entries view, giving a single place to export contact + purchase data
- Conditional logic is a native Gravity Forms feature, no custom code required

---

## Implementation Notes

### Prerequisites

- Gravity Forms with the **PayPal Add-On** (check license tier — PayPal Standard is included in most)
- PayPal business account with payment buttons or API credentials configured
- Existing WP EasyPay forms should be **deprecated and removed** after migration to reduce plugin bloat

### Form Structure

| Field | Type | Notes |
|---|---|---|
| First / Last Name | Text | Required |
| Company Name | Text | Required for invoicing |
| Email | Email | Required |
| Phone | Phone | Optional |
| Partnership / Item Selection | Dropdown or Radio | Drives conditional logic |
| Payment | Gravity Forms PayPal field | Shown/hidden by conditional logic |

### Conditional Logic Setup

In Gravity Forms, use **Pricing Fields** with conditional visibility rules tied to the selection field. Each pricing field corresponds to one product tier and is shown only when that tier is selected.

Alternatively, use the **PayPal Add-On feed** with conditional logic at the feed level to route different amounts based on form field values.

### PayPal Processing Fee Consideration

> **Known limitation:** PayPal does not support passing processing fees to the buyer at checkout. Square (and some other processors) allow adding a surcharge to the customer's total. If absorbing processing fees is a business concern, this must be accounted for in pricing or communicated to stakeholders before migrating away from Square.

---

## What Doesn't Work

| Approach | Problem |
|---|---|
| Standalone PayPal button on a page | No contact data captured; no WordPress-side record |
| WP EasyPay + PayPal | WP EasyPay does not support PayPal gateway |
| Custom code to bridge EasyPay + PayPal | Fragile, hard for non-developers to maintain |
| One form per product/tier | Scales poorly; data scattered across many entries |
| WP Forms Premium | Adds a new plugin when Gravity Forms already exists |

---

## Client Example

**Didion** runs an annual golf outing with multiple partnership tiers (Birdie, Eagle, Title Sponsor, etc.) and add-on silent auction items. Previously, Square/WP EasyPay handled payments but could not be migrated to PayPal. A standalone PayPal button test failed — clicking it returned a "thank you" confirmation without redirecting to PayPal or capturing any user data.

The proposed resolution: one Gravity Form with conditional logic to capture contact info and trigger the correct PayPal payment per tier. This eliminates the need for 60+ individual payment forms and keeps all submission data in one place.

See also: [[clients/didion/meetings/2025-12-04-website-slider-fix-payment-form-strategy|Didion — Website Slider Fix & Payment Form Strategy]]

---

## Related

- [[knowledge/integrations/wordpress-divi-custom-code-limitations|WordPress Divi Custom Code Limitations]]
- [[knowledge/tools/gravity-forms|Gravity Forms]]
- [[clients/didion/index|Didion Client Index]]