The specific failure that brings most developers here: a customer completes a Stripe payment, the charge appears in the Stripe dashboard, but Gravity Forms either does not create an entry at all, creates the entry with a “Payment Pending” status that never updates, or creates the entry but does not trigger the form’s configured notifications and confirmations. Each symptom has a different root cause.
How Gravity Forms and Stripe Work Together
Understanding the flow explains why each failure happens where it does. When a visitor submits a form with Stripe payment, Gravity Forms creates a payment intent with Stripe and redirects the visitor through Stripe’s payment flow. After payment, Stripe redirects the visitor back to your site. Gravity Forms marks the entry as active and triggers notifications based on this return redirect. Separately, Stripe sends a webhook to your site confirming the payment succeeded – Gravity Forms uses this webhook to update the payment status from pending to approved.
Two things can go wrong independently: the return redirect (which triggers the entry and immediate notifications) and the webhook (which updates payment status and triggers payment-confirmed notifications). These are different code paths with different failure modes.
Diagnosing the Failure Type
The first question is whether the entry is being created at all. Go to Gravity Forms -> Entries and look for the submission. If you see an entry with “Payment Pending” status, the entry was created (redirect worked) but the webhook did not fire or failed. If there is no entry at all, the redirect back from Stripe failed before Gravity Forms processed the submission.
For webhook failures, Stripe’s dashboard shows exactly what happened. Go to Stripe Dashboard -> Developers -> Webhooks -> your endpoint. Click on your Gravity Forms webhook endpoint and review the “Attempted events” log. Failed webhooks show the HTTP status code returned by your server and the full response body. This is the most useful diagnostic tool available.
Fixing Webhook Configuration
Go to Gravity Forms -> Settings -> Stripe -> Webhooks. Copy the webhook URL shown there. In your Stripe Dashboard -> Developers -> Webhooks, check whether this exact URL is registered as an endpoint. If not, add it. If it is registered, verify the URL matches exactly – including trailing slash, HTTPS vs HTTP, and whether your site uses a non-standard port.
The events Gravity Forms needs Stripe to send: payment_intent.succeeded, payment_intent.payment_failed, checkout.session.completed, and customer.subscription.* events if you use subscriptions. When adding or editing the webhook endpoint in Stripe, select “All events” initially for testing, then narrow to required events once everything is working.
Still stuck after trying these steps? Describe the exact issue and get a free estimate from a developer who has seen this before.
SSL and HTTPS Issues
Stripe webhooks require HTTPS. If your site is configured with HTTP, or if your SSL certificate is expired, invalid, or uses a self-signed certificate, Stripe refuses to deliver webhooks. This causes every Stripe payment to create a “Payment Pending” entry that never resolves.
Verify your SSL in Stripe’s webhook dashboard: when a webhook delivery fails with an SSL error, it shows in the event log as a connection error rather than an HTTP error code. Fix the SSL issue on your server, then use Stripe’s “Resend” option on failed events to deliver them to your now-working endpoint.
Firewall and Security Plugin Interference
Security plugins like Wordfence or server-level firewalls sometimes block Stripe’s webhook delivery because the requests come from Stripe’s IP addresses without a browser session. The webhook request looks like a bot to overly aggressive security rules.
If webhooks are failing with a 403 status code in Stripe’s dashboard, a security rule is blocking them. Whitelist Stripe’s IP ranges in your security plugin. Stripe publishes its current IP ranges at stripe.com/files/ips/ips_webhooks.txt. Add these to Wordfence -> Firewall -> Allowlisted IPs, or equivalent in your security plugin.
An alternative approach: use Stripe’s official IP ranges to create a server-level whitelist rule in .htaccess or your Nginx configuration that bypasses security checks for requests from those IPs to your webhook URL specifically.
Webhook Signature Verification Failures
Gravity Forms verifies that webhook requests genuinely come from Stripe using a webhook signing secret. If the signing secret in Gravity Forms does not match what Stripe expects, every webhook is rejected as invalid. This appears as a 400 error in Stripe’s webhook log with a message about signature verification failing.
Fix: in Stripe Dashboard -> Developers -> Webhooks -> your endpoint, find the “Signing secret” section and reveal the secret. Copy it. In Gravity Forms -> Settings -> Stripe, update the webhook signing secret field with the exact value from Stripe. Save and test with Stripe’s “Send test webhook” button.
Entry Created But Notifications Not Firing
If the entry exists and payment status is correct but notification emails are not sending, the issue is in Gravity Forms notification configuration rather than Stripe. Go to the form’s Notifications settings. For payment-related notifications, verify the notification is configured to send “On Payment” rather than “On Submission”. A notification set to fire on submission fires before payment completes; a payment-triggered notification fires after the webhook confirms payment. Using the wrong trigger means notifications either fire before payment or never fire at all.