Membership dues payments

Collect dues online without buying heavyweight membership software first

Flint gives organizations a cleaner payment layer for annual dues, recurring memberships, assessments, and member fees. Use hosted payment links when the charge is one-time. Use subscription plans and hosted signup when renewal should be automatic.

Annual dues
Recurring memberships
Hosted payment pages
Cleaner payment records

Collection models

Match the billing shape to the dues workflow

2026 Annual Dues

One-time link

Hosted payment page for renewal season, fixed amount, member email, and organization-specific fields.

Monthly Member Plan

Recurring plan

Hosted signup backed by a subscription plan instead of reminder emails and manual renewal tracking.

ACTIVE
PAST DUE
PAUSED

Hosted page

Member email required
Member number field
Success redirect

Renewal lifecycle

Retry failed renewals
Pause or cancel on dunning end
Webhook events for ops

The actual problem

Membership collection gets messy long before organizations need a full suite

A lot of teams searching for membership software are actually trying to solve a narrower issue: publish a payment page, collect dues cleanly, stop chasing renewals by hand, and give admins a better payment trail.

The old way

Annual renewals are chased through email, checks, and manual reminders
Monthly memberships live in a separate billing tool from events or donations
Treasurers and admins cannot easily tell who paid dues versus who paid for something else
The team buys heavyweight membership software before the payment workflow is even proven

With Flint

Use hosted payment links for one-time dues, assessments, and simple renewals
Use subscription plans and hosted signup for recurring memberships and auto-renewals
Keep member payment records closer to one payment layer across dues, events, and other fees
Add broader membership tooling later if the organization truly needs it

Choose the right billing motion

This use case is really two different payment problems

Searchers often collapse annual dues and recurring memberships into one category. Flint works better when those are separated clearly because the correct implementation path is different.

One-time dues

Annual dues, assessments, and fixed member fees

Use a hosted payment link when the member owes a one-time amount and the main job is collecting it quickly from email, text, or the website.

Good fit for annual renewals, family dues, special assessments, and chapter fees.
Built on Flint payment links with line items, custom fields, redirects, and buyer email collection.
The fastest path when you do not need recurring billing behavior yet.
View Payment Links API

Recurring memberships

Monthly or auto-renewing member billing

Use subscription plans when the organization wants predictable renewals instead of sending reminders every cycle and manually marking members current.

Create a reusable plan, attach it to a hosted payment link, and let Flint handle signup.
Billing lifecycle already includes active, paused, past-due, and canceled states.
Failed-payment retries and dunning settings matter more here than in a one-time dues flow.
View Subscription Payment Links

How it works

Launch the dues workflow before you overbuy the stack

The cleanest path is usually simple: pick the correct collection model, publish the hosted page, share it, and operate from payment data that is no longer scattered across tools.

1

Decide whether the member fee is one-time or recurring

This is the key product decision. Annual or occasional dues fit hosted payment links well. Monthly, quarterly, or rolling memberships fit subscription plans and recurring signup.

2

Create the hosted page members actually use

Publish a shareable Flint payment page with your organization name, the amount due, required member fields, redirects, and any policy links you need.

3

Share one link wherever members already respond

Send the page through email, text, QR codes, newsletters, or your website instead of asking members to mail checks or navigate a fragmented portal.

4

Operate renewals and support from cleaner payment records

Track who paid, what they paid for, and what billing state they are in. Refunds, retries, and lifecycle events stop becoming separate spreadsheet work.

Built from real product surfaces

Why this maps cleanly to Flint's dashboard, APIs, and billing model

This page should describe product that already exists, not an imaginary membership platform. Flint already exposes the hosted pages, subscription plan primitives, and renewal lifecycle behavior this workflow actually needs.

Hosted payment links for member-facing checkout

Flint already has the hosted surface this use case depends on: reusable payment pages for one-time dues and plan-backed hosted signup for recurring memberships.

Use `line_items` for one-time dues and fixed assessments
Use `plan_id` for hosted recurring membership signup
Collect member details with checkout custom fields and required email

Recurring billing primitives instead of reminders and manual follow-up

Subscription plans and subscriptions model the ongoing relationship once dues become a repeatable program rather than a one-time charge.

Monthly, yearly, and other billing cadences
Lifecycle states including active, paused, past due, and canceled
Hosted signup or direct subscription creation when you already know the customer

Dunning, retries, and lifecycle events for real renewal operations

The difficult part of memberships is not the first signup. It is what happens when cards fail, renewals drift, or support needs to see the billing trail.

Configurable subscription retry behavior and dunning end action
Webhook events like `subscription.created`, `subscription.payment_succeeded`, and `subscription.past_due`
A better operational path than exporting billing failures into side workflows

One payment layer across dues, events, donations, and other fees

Most organizations collecting dues also run tickets, sponsorships, merchandise, or optional contributions. Flint fits well when those flows should not live in isolated tools.

Use the same payment surface across dues, registrations, and one-off collections
Keep payment history more coherent for admins and treasurers
Add a broader membership stack later only if the rest of the organization truly needs it

Common organizations

The payment shape shows up across the rest of Flint's site

Membership dues are not one isolated category. The same pattern appears across associations, alumni groups, HOAs, pools, clubs, and other member-funded organizations already represented in Flint's landing-page cluster.

Associations and chambers

Member-funded groups with annual dues, sponsorships, lunches, and occasional assessments often need cleaner payment infrastructure before they need full association software.

HOAs and community organizations

Recurring neighborhood fees and special assessments share the same shape: predictable collections, member identity, and a cleaner record of who has paid.

Alumni groups and school communities

Annual memberships, reunion payments, scholarship donations, and chapter fees work better when they sit near one another instead of in unrelated systems.

Clubs, pools, and member-run organizations

Car clubs, community pools, and local organizations often want the simplest possible member-payment flow without long contracts or category-specific software overhead.

Honest fit

Use Flint when the immediate need is cleaner payment infrastructure

The right positioning here is narrower than “all membership software.” Flint is strongest when the organization wants to fix collection, renewals, and payment records first.

Flint is the right fit when

You want to collect dues and member fees online before committing to a full membership-management suite.
You need hosted checkout, recurring billing, and cleaner payment records more than CRM, committee, or content-management features.
Your organization also collects tickets, donations, assessments, or merchandise and wants those to live near the same payment layer.

Broader membership software is justified when

You need a complete member portal, chapter workflows, rosters, committees, and broad association-management tooling on day one.
Your buying decision is really about CRM and member operations, not just payment collection and renewals.
You need complex entitlement, credentialing, or access-control workflows that go far beyond hosted payments and recurring billing.

API shape

The public API already supports the membership payment path

For recurring dues, the implementation path is direct: create a subscription plan, attach it to a payment link with `plan_id`, and listen for lifecycle events when renewals succeed or go past due.

membership-dues-flow.txt
POST /v1/subscription-plans
{
  "name": "Annual Family Membership",
  "billing_interval": "yearly",
  "currency": "USD",
  "line_items": [
    {
      "name": "2026 Family Membership",
      "quantity": 1,
      "unit_price_money": { "amount": 18500, "currency": "USD" }
    }
  ]
}

POST /v1/payment-links
{
  "name": "2026 Membership Renewal",
  "plan_id": "plan_xxx",
  "customer": {
    "require_email": true,
    "enable_address_autocomplete": true
  },
  "custom_fields": [
    { "key": "member_number", "label": "Member Number", "type": "text", "is_required": true }
  ]
}

Webhook events:
subscription.created
subscription.payment_succeeded
subscription.past_due

Keep exploring

Follow the rest of the dues and membership path

The best next step depends on whether the team needs recurring billing, a vertical-specific workflow, or a broader solution surface.

Launch the payment workflow first

Start with hosted dues collection and recurring renewals you can actually operate. If the organization later needs a broader member platform, that becomes a clearer and more informed decision.