Payment Patterns — Staff Fee Collection

Last updated: March 3, 2026

---

Overview

GovAssist supports two patterns for collecting fees after an initial application is submitted. Both patterns are designed to be configured per permit type based on your jurisdiction's fee structure.

Pattern 1 — Manual Fee Entry: Staff determines and enters the fee amount directly on the record.

Pattern 2 — Fee Definition with Staff Confirmation: Fees are auto-calculated from rate structures after staff verifies input variables.

Both patterns can coexist with filing fees collected at initial submission (filing fees use a separate payment configuration).

---

Prerequisites — Payment Form & Automation Setup

Both patterns require a dedicated payment form and automation to deliver the payment link to the applicant.

Step 1: Create a Payment Form

1. Create a new form (or edit an existing payment form)
2. Add at least one required field on Step 1 (e.g., applicant name, contact info)
3. Add a Payment field on Step 2 or later
   • Configure the payment provider (e.g., Govolution, Stripe)
   • Set amount_type to DYNAMIC (Pattern 1) or CALCULATION (Pattern 2)
4. Save the payment field

Step 2: Get the Citizen Form Link

1. On the form configuration view find the Share Form button
2. Click the Share Form button
3. Copy the Citizen Form Link — this is the public URL applicants will use to access the form

Example link:

https://yourjurisdiction.govassist.app/forms/public/abc123def456

Step 3: Build the Automation

Create an automation on the permit entity to send the payment link when triggered:

Trigger:

• When a record is updated on the permit entity
• Condition: Fee field is not empty (Pattern 1), OR Confirmation checkbox is true (Pattern 2)

Action: Send Email

1. Add a Send Email action node
2. Configure recipient: Use the applicant email field from the permit record
3. Compose the email body with the payment link:

Message body template:

Payment is required for your permit application.

Please complete payment here:
[Citizen Form Link]?record_id=[Record ID]

Dynamic field substitution:

• Replace [Citizen Form Link] with the static URL you copied in Step 2
• Replace [Record ID] with the dynamic Record ID field from the permit record

Example (with dynamic fields):

Payment is required for your permit application.

Please complete payment here:
https://yourjurisdiction.govassist.app/forms/public/abc123def456?record_id={{record.id}}

1. Save and publish the automation

Why This Workflow Matters

• Form + Automation are required — Payments cannot be triggered without this setup
• The Citizen Form Link is static — it's the same for all applicants using this payment form
• The Record ID is dynamic — it changes per permit and ties the payment submission to the correct record
• The automation must append the Record ID to the form URL, not just send the base link

---

Pattern 1 — Manual Fee Entry

When to Use

Use this pattern when the fee amount cannot be calculated from a rate structure:

• Flat fees determined by staff review
• Penalty amounts
• Case-by-case fees without defined rates
• Discretionary fees requiring staff judgment

How It Works

Configuration Requirements

Entity Setup:

Payment Configuration:

Automation (Required):

See Prerequisites — Payment Form & Automation Setup above for the complete automation workflow.

Summary:

• Trigger: Fee amount field is updated (not empty)
• Action: Send email with [Citizen Form Link]?record_id={{record.id}}

Example Workflow

Scenario: Building permit with post-review fee

1. Applicant submits application and pays $50 filing fee
2. Staff reviews plans and calculates permit fee: $1,200
3. Staff enters 1200 in the manual_fee_amount field and saves
4. Automation emails applicant: "Payment of $1,200 is required. [Pay Now Link]"
5. Applicant clicks link, payment form loads with $1,200 pre-filled
6. Applicant pays via credit card through payment provider
7. Payment status updates on permit record

Notes

• Staff has full control over the amount — no automated calculation occurs
• If the amount needs to change, staff updates the field; the automation can re-fire with the new amount
• Filing fees and post-review fees are separate payment configurations

---

Pattern 2 — Fee Definition with Staff Confirmation

When to Use

Use this pattern when fees are calculated from a rate structure, but the input variable must be verified by staff before billing:

• Per-acre or per-square-foot fees
• Tiered fees based on construction value
• Formula-based fees with staff-confirmed inputs
• Any scenario where applicant-submitted values need official verification

How It Works

Configuration Requirements

Entity Setup:

Fee Definitions:

Payment Configuration:

Automation (Required):

See Prerequisites — Payment Form & Automation Setup above for the complete automation workflow.

Summary:

• Trigger: Confirmation checkbox field changes to true
• Action: Send email with [Citizen Form Link]?record_id={{record.id}}

Example Workflow

Scenario: Grading permit with acreage-based fee

1. Applicant submits application, enters 3 acres (estimated)
2. Staff pays $100 filing fee (separate config)
3. Staff reviews and verifies actual acreage from parcel records: 3.5 acres
4. Staff updates acreage field to 3.5
5. Staff checks "Fee Values Confirmed" checkbox and saves
6. Automation emails applicant: "Payment is required. [Pay Now Link]"
7. Payment form calculates: 3.5 acres × $200/acre = $700
8. Applicant pays $700
9. Payment status updates on permit record

Fee Calculation Methods

The calculation_method in a fee definition determines how the fee is calculated:

Notes

• Staff must not check the confirmation box until all input fields are finalized — it's the point of no return for that billing cycle
• Multiple fee definitions can be applied in the same payment configuration (e.g., base fee + per-unit fee + technology fee)
• If input values change post-confirmation, coordinate with your jurisdiction's refund/adjustment policy

---

Comparison Summary

---

Filing Fees at Submission

Both patterns are compatible with collecting a filing fee at initial application submission. This is configured as a separate payment configuration on the submission form, independent of the post-review payment step.

Filing fee configuration:

• amount_type: STATIC (fixed amount) or CALCULATION (if filing fee varies by permit type)
• Collected at Step 1 or during the application form submission
• Does not require staff review or confirmation

---

Payment Field Configuration

For details on creating the payment form and automation, see Prerequisites — Payment Form & Automation Setup above.

Payment field settings by pattern:

---

Refunds and Adjustments

Payment providers (e.g., Govolution) do not process refunds automatically. Refunds must be coordinated with your finance department externally.

Recommended workflow:

1. Add a payment_status field to the entity (dropdown: Pending, Paid, Refund Needed, Refunded)
2. Staff updates status to Refund Needed when applicable
3. Finance processes refund externally
4. Staff updates status to Refunded once complete

---

Troubleshooting

Common Issues

---

Related Documentation

• Fee Definitions Configuration — Setting up fee structures and calculation methods
• Payment Provider Integration — Connecting payment processors
• Automation Builder — Creating payment request automations
• Form Builder — Configuring payment forms

---

Questions? Contact your system administrator or AutoBridge support.