Use Cases

Approve a booking, collect payment, then confirm it

Review a request first, send the approved customer to a payment form, and confirm the booking only when payment arrives on time.

Some bookings should not take payment immediately. A class may have limited places, a rental may need an availability check, or a custom service may need a person to approve the request first. This workflow approves the request, waits for its payment, and keeps fulfillment blocked until the money arrives.

Good for: Classes, events, rentals, memberships, and fixed-price services
Level: Advanced

What you’ll build

The request and payment live on separate forms. Approval sends the customer a payment-form link carrying this run’s key. The workflow waits for the matching payment entry, then waits for the gateway to mark that entry paid. Payment confirms the original booking; a missed deadline marks it overdue for staff review instead.

flowchart TD
    A[Booking request submitted] --> B[Wait for Approval]
    B -->|Approved| C[Send Email:<br/>payment-form link]
    B -->|Rejected| D[Email the customer]
    B -->|Expired| E[Escalate the request]
    C --> F[Wait for Form Submission:<br/>matching payment form]
    F -->|Submitted| G[Wait for Payment]
    F -->|Expired| H[Set booking status:<br/>Payment overdue]
    G -->|Paid| I[Set booking status:<br/>Confirmed]
    G -->|Overdue| H
    I --> J[GF Feed:<br/>start fulfillment]
    J --> K[Send confirmation]
    H --> L[Notify the customer<br/>and booking team]

Booking workflow with approval, matching payment-form wait, and separate Paid and Overdue paths

Before you build

Create separate booking-request and payment forms.
Configure the payment form’s Gravity Forms payment feed and test it in the gateway’s sandbox.
Decide how long customers have to submit the payment form and how long a submitted payment may remain pending.
Choose the booking and escalation inboxes before adding approval nodes.

Build it step by step

Build a Booking request form with the details your team needs to approve. Add an administrative-only Booking status field with a default such as Pending review, so only staff and the workflow control it.
Create a separate Booking payment form with the fixed price and your payment add-on. Add a hidden field for the workflow key, turn on Allow field to be populated dynamically, and use key as its parameter name.
Open the Booking request form and click Workflows in the form toolbar. Click New Workflow, then Add Trigger and choose Form Submitted.
Add Wait for Approval. Include the request details in the email, choose the approvers, and set reminders and an expiry. On Rejected, email the customer. On Expired, alert the booking team.
On Approved, add Send Email with a link to the payment form, such as https://your-site.test/pay/?key={{run.key}}; replace the domain and path with the real payment page.
Add Wait for Form Submission. Choose the Booking payment form and match its hidden key field to {{run.key}}. Set its expiry to the time the customer has to open and submit the payment form. Connect Expired to the overdue path.
On Submitted, add Wait for Payment. Set Form source to the Booking payment form and Entry source to {{ "Wait for Form Submission".entry_id }}. Set Overdue in (hours) to a window that fits the payment method: card payments may need hours, while bank transfers may need several days.
On Paid, add Update Entry Field targeting {{ "Form Submitted".id }} on the Booking request form, and set Booking status to Confirmed.
Add GF Feed after the status update when an existing feed should register the attendee, create the membership, or hand the booking to another service. Point it at the original booking entry, then send the customer a confirmation.
Join the payment form’s Expired path and Wait for Payment’s Overdue path at an Update Entry Field node that sets the original booking status to Payment overdue. Follow it with an email to the customer and booking team so someone can check the gateway before cancelling the request or releasing the place.

Keep in mind

Keep the price out of the link: Use a fixed price on the payment form or load the approved amount from trusted server-side data. Do not put an editable amount such as ?amount=500 in the payment URL — a customer could change it before paying.
Overdue does not disable the payment form: Overdue means Flowcrafter stopped waiting after the configured window. It does not cancel a gateway session, disable the payment form, or prevent a late payment. Keep fulfillment blocked and have staff check the gateway before cancelling the booking or releasing limited inventory. A gateway-specific API step can close the payment opportunity when the provider supports it.

Data passed between nodes

From	Data used later	Where it goes
Run context	`run.key`	Payment-form URL and Wait for Form Submission match
Wait for Form Submission	Payment form `entry_id`	Wait for Payment entry source
Wait for Payment	`payment_status`, `transaction_id`, `payment_amount`	Customer confirmation, staff messages, and run history
Form Submitted	Original booking `id`	Booking status update and fulfillment feed

Test and activate safely

New workflows start Inactive. Use builder tests for rejection and approval first. Paid and Overdue require a real parked run, so temporarily activate the workflow on staging, or use test recipients and the gateway’s sandbox during a controlled live test. Complete one successful payment, then use a short Overdue in (hours) value for a second run. Restore the real deadline before production activation. The field defaults to 168 hours; clearing it waits indefinitely, which is rarely appropriate for limited inventory.

Before going live, confirm the payment add-on does not independently run the same fulfillment action, activate the workflow, and monitor the first paid and overdue runs. If a run is already parked on an older Wait for Payment node, changing the setting does not rewrite that frozen run.

What Flowcrafter adds

Gravity Forms can collect payment and run supported feeds afterward. It does not hold a request for approval, connect an approved request to a second payment form, update the original booking, and take a separate overdue path when payment misses the business deadline.

Flowcrafter keeps those moments in one run: approval decides whether payment should be requested, the run key connects the two forms, Wait for Payment blocks fulfillment, and the original booking records whether the outcome was confirmed or overdue.

Wait for Approval — decide whether the customer should be asked to pay
Wait for Form Submission — match the payment form to this booking
Wait for Payment — continue through Paid or Overdue
Update Entry Field — keep the booking status on the original request
GF Feed — start fulfillment only after payment
Pausing & Waiting — understand event-driven waits