Gravity Forms documents that marking an entry Not Spam does not automatically process payment feeds. A valid order, registration, or donation can therefore reappear in the entry list while its payment remains absent, failed, authorized, captured elsewhere, or already retried by the customer. Manual recovery must reconcile external transaction state before any charge action.
Use this for Gravity Forms entries tied to Stripe, PayPal, Authorize.Net, Square, subscriptions, deposits, or custom payment feeds. The payment owner, not a general support user, should approve any action that can create, capture, refund, cancel, or duplicate a transaction.
Quick answer
Freeze automated replay for the restored entry, preserve its notes and feed state, and search the payment provider by stable identifiers, customer context, amount, currency, and time. Classify the transaction as absent, failed, authorized, captured, refunded, disputed, or ambiguous. Choose a provider-safe recovery path, create current customer links if needed, and record deduplication and approval before changing the entry payment status.
What to check first
- Capture entry ID, form ID, spam reason, created time, payment feed, feed condition, expected amount and currency, customer-facing confirmation, and every prior recovery attempt.
- Search the provider using transaction ID, metadata entry ID, idempotency key, customer reference, amount, currency, and a narrow time window without exposing payment credentials in the report.
- Compare Gravity Forms payment status, provider status, webhook deliveries, order or CRM record, email history, and whether the customer already submitted again.
- Classify the safe next action as no charge, new hosted payment link, capture existing authorization, provider retry, manual reconciliation, refund, or specialist review.
- After action, update entry notes with provider reference, approver, UTC time, amount, result, downstream feeds handled, customer communication, and monitoring owner.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Preserve entry and feed evidence | Capture entry ID, form ID, spam reason, created time, payment feed, feed condition, expected amount and currency, customer-facing confirmation, and every prior recovery attempt. | Exactly one intended successful financial outcome is tied to the entry or replacement record. |
| Reconcile the provider before any charge | Search the provider using transaction ID, metadata entry ID, idempotency key, customer reference, amount, currency, and a narrow time window without exposing payment credentials in the report. | Provider, Gravity Forms, CRM or order record, and customer communication agree. |
| Check customer retries and downstream records | Compare Gravity Forms payment status, provider status, webhook deliveries, order or CRM record, email history, and whether the customer already submitted again. | No payment feed, webhook, notification, or manual action remains queued to duplicate the recovery. |
| Obtain payment-owner approval | Classify the safe next action as no charge, new hosted payment link, capture existing authorization, provider retry, manual reconciliation, refund, or specialist review. | Entry notes identify the approver, provider reference, action, time, and final verification. |
Why this usually happens
- Spam handling can stop feed execution before a payment add-on creates or confirms a transaction.
- A customer may retry while support is reviewing the spam entry.
- Webhooks can update the provider without updating the restored entry.
- An authorization can exist without a capture, and a failed status can coexist with a later successful attempt.
- Manual status edits can make the entry look paid without creating financial evidence.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
recovery_id: GF-PAY-20260723-118
entry_id: 11842
feed: stripe_registration
expected_minor: 12500
currency: USD
provider_search: completed
provider_state: absent
customer_retry_found: false
action: issue_new_hosted_payment_link
approver: payments-owner
idempotency_key: gf-11842-recovery-1
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Preserve entry and feed evidence
- Reconcile the provider before any charge
- Check customer retries and downstream records
- Obtain payment-owner approval
- Execute one deduplicated recovery and verify
Decision rule
Never create or capture a new payment while provider state is ambiguous. If a matching successful transaction exists, reconcile records rather than charging again. If no transaction exists, use the provider's supported customer payment flow and a stable recovery identifier.
What to tell the client or owner
Give the payment owner an evidence packet with expected amount, provider search, matching transactions, customer retries, proposed action, duplicate risk, customer communication, and approval field. Redact payment credentials and personal fields.
Production verification checklist
- Exactly one intended successful financial outcome is tied to the entry or replacement record.
- Provider, Gravity Forms, CRM or order record, and customer communication agree.
- No payment feed, webhook, notification, or manual action remains queued to duplicate the recovery.
- Entry notes identify the approver, provider reference, action, time, and final verification.
Mistakes to avoid
- Do not change the Gravity Forms payment status to Paid as a substitute for provider evidence.
- Do not replay a payment feed before searching for customer retries.
- Do not send an old or expired payment link.
- Do not put API keys, full card data, or personal entry fields in incident notes.
Questions teams ask during testing
Will Mark Not Spam run the original payment feed?
Gravity Forms documents that payment feeds are not automatically processed when an entry is marked Not Spam. Reconcile and recover deliberately.
What if the provider search is inconclusive?
Stop financial action, widen evidence using approved provider tools, and escalate to the payment owner rather than risking a duplicate charge.
When HandL WP should help
Bring in HandL WP when the issue affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, recover a Gravity Forms payment safely.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references