Approvals & workflow

How to approve membership applications before taking payment

Most membership tools are built to take the money at sign-up. Clubs, associations, co-operatives and professional bodies that vet applicants need the steps in a different order: apply, review, approve, then pay. Here is how to set that up, the ways to build it, and what to automate once it works.

By the Faldaro team · Published September 25, 2026

Why the order matters

Charging at the moment of application is the default in most sign-up flows, and for open memberships it is right. When applications are reviewed, it creates three problems:

Refunds for everyone you decline. Card processors generally keep their fee on a refunded payment, so each decline costs you money as well as an awkward email.
Pressure on the reviewer. Declining someone who has already paid feels like a bigger decision than declining an application, and reviews get softer.
A worse first impression. A declined applicant who paid and waited for a refund is the one most likely to complain publicly.

Asking for payment after approval removes all three: money is only requested from people you have accepted.

The workflow, step by step

Application. A public form collects who the applicant is, the tier they want, and what the committee needs to decide — references, qualifications, a short statement. Compute the fee on the form from the tier, so the amount is settled before anyone reviews it.
Review. The application lands in a queue as Applied. A reviewer approves, declines, or waitlists it — or sends it to the committee when the rules require more than one approver.
Approval. The approving decision moves the record to Approved and, in the same step, emails the applicant a payment link for the fee computed at application.
Payment. When the payment is confirmed, the record moves to Active — and only then.
Welcome. The move to Active sends the welcome email, generates the certificate or card, and records the renewal date.
Decline and waitlist. Each has its own considerate email, and a waitlisted application can be promoted later without the applicant starting again.

Three ways to build it

Membership management software

Dedicated membership platforms handle directories, events, renewals and dues, and many offer an application approval setting. If you need the whole membership back office, start there — and check two things: whether payment can wait until after approval, and whether reviewers need a paid admin seat to decide.

A form, a spreadsheet and invoices

The low-cost version: a form collects applications into a sheet, a reviewer marks each row, and approved applicants are sent an invoice by hand. It works at a few applications a month. Past that, the gaps show: nothing tells an applicant where they stand, an invoice can go to someone who was never approved, and a payment is matched to its application by hand.

A form platform with workflow and payments

The middle path: one tool where the application, the review, the payment request and the welcome are steps of the same record. It suits organizations whose membership back office is simple but whose vetting matters.

Building it in Faldaro

Each step of the workflow above maps to something Faldaro does as standard:

The application is a public form on a revocable link. The membership application template computes the fee from the tier on the server, so no applicant can submit a price of their own.
The review is a workflow: Applied, Approved, Waitlisted, Declined, Active — with each move naming who may take it. For a committee, a Request an approval action emails each member a personal approve/decline link with no account; the approval takes effect once everyone has said yes, and a deadline can escalate an application nobody has looked at.
The payment is a Request a payment action on the approving move. It prices the fee at that moment, freezes the amount, and emails the applicant a Stripe checkout link — money goes to your own Stripe account.
Activation waits for the money. The move to Active can require `payment_status` = "succeeded", a value the server records from Stripe’s signed confirmation, so no one can activate a membership that has not been paid.
The welcome is a set of actions on that move: the email, a certificate generated as a PDF from your own template, and anything else the membership triggers.
The applicant can follow along on a status link — the current step and reference number, never the committee’s notes.

Approvals, payments and documents are on every plan, including Free. The approval workflow guide covers designing the review itself, whichever tool you use.

Questions

Should we charge the membership fee when someone applies, or after approval?

If you approve applications, ask for payment after approval. Charging at application means refunding everyone you decline — which costs processing fees you usually do not get back — and applicants who were declined after paying are the ones most likely to complain. Charging after approval asks for money only from people you have already said yes to.

How many people should approve an application?

As few as the organization’s rules require. Many clubs and associations need one reviewer for most applications and a committee only for exceptions. Where the bylaws require several approvers, set a deadline for the decision, so an application does not wait on the one committee member who is away.

Do approvers need an account in our membership system?

Not necessarily. Tools that send approvers a personal approve/decline link let volunteer committee members decide from their inbox without a login, which is often the difference between a decision this week and next month.

What should happen after the member pays?

The welcome: a confirmation email, a membership certificate or card, access to whatever the membership unlocks, and a renewal date recorded. Automate it on the payment confirmation rather than on someone noticing the payment arrived.