You want “submitted the form” AND “not paid yet.” Build that as two filters on the object that actually holds payment status.
Typical pattern:
-
Start an Active list / segment on Contacts (or the object that owns the payment field if it is Deal/Order).
-
Filter: Form submission → that form → is known / has submitted (or Marketing → Form submissions includes [form]).
-
AND payment status → is any of → Open / Unpaid / No payment (use the exact option labels from your property).
-
If payment lives on a Deal or Order, do not guess on Contact. Either:
-
filter Contacts with Associated deal → Payment status = unpaid, or
-
build the segment on Deals first, then use “associated contacts” if you need a contact list for email.
-
Common gotchas:
- “Submitted form” alone will keep including people who paid later unless you also exclude paid statuses (is none of Paid / Completed).
- If the screenshot field is a custom property, filter that property name, not Lifecycle stage.
- For one-off export: same filters in a Contacts view → Export. For ongoing nurture: Active list so membership drops when status flips to paid.
If you can say whether payment status is a Contact property, a Deal property, or Commerce/Payments, the exact click path is one step cleaner.
This is a common use case. You can create an active list under Contacts or Deals and use the Payment Status property as a filter.
If Payment Status is a custom property, I’d first check that it’s being populated correctly, especially if the data is coming from an integration.
Also, if the payment status changes frequently, an active list can be useful because it updates automatically when the status changes. With a static list, you’d need to update it manually.
If you’re using a specific payment gateway, the setup may depend on how the integration is sending the payment data.
This is a useful question. Creating a segment based on payment status makes sense when you need to separate paid, pending, and unpaid contacts for follow-ups or reporting. The key is making sure the payment status property is consistently populated so the segment updates correctly.
I’ve used a similar setup for tracking form submissions that hadn’t converted yet. I’d build the segment with two conditions: the specific form submission is known, AND Payment Status is Open/Unpaid. If the payment status lives on a Deal rather than the Contact, make sure you’re filtering through the associated Deal property; otherwise the segment can return misleading results.
Hi @rhence
The easiest way is to build two segments. First, find everyone who paid, then create a second segment that excludes them.
Filtering directly on “payment status is not Succeeded” misses some people. Contacts marked “No payment” never started a payment, so they have no payment record for the filter to check.
For the first segment, create a contact-based segment and add a filter for contacts who submitted your Friday Night Clinics form. Then add a second filter on the associated Payment object where the payment status is Succeeded. Save it as something like “Friday Night Clinic – Paid.”
For the second segment, add the same form submission filter. Then add a filter for segment membership where the contact is not a member of the “Paid” segment. Save this one as “Friday Night Clinic – Did Not Pay.”
This gives you everyone who filled out the form but didn’t pay, whether their status is Open, Expired, or No payment. Make it an active segment so it updates on its own: once someone pays, they drop off the list automatically, which is handy for sending payment reminders.
I hope this helps you out. Please mark it as Solution Accepted and Like to help another Community member.
This post was created with the assistance of AI tools
Thanks!