Membership

The Downtown Alliance has a tiered membership model with automation that keeps access, receipts, and payment records in sync. Card payments settle through Stripe; cash, checks, and payment-app payments use a staff-recorded chain of custody so the board can always tell who received the money and where it went.

The three tiers

Tier	How you join	What you get
Verified	Create a free account at faydta.com	Vote on surveys, RSVP for meetings, comment on bulletins. On Discord: the @DTA Verified role unlocks most public channels.
Member	Pay dues via Stripe	All Verified benefits + member-only bulletins, the member referral network, member meetings, the #members-chat Discord channel for shoutouts and referrals.
Board	Appointed by the existing board	All Member benefits + board governance, the private #meeting-plans channel, the #to-dta-board inbox channel.

Board membership is governance, not a perk. Board members serve terms and have specific committee responsibilities.

How membership automation works

When someone pays for membership via Stripe:

1. Stripe fires a customer.subscription.created webhook to FAYDTA
2. FAYDTA records the membership in its database (the canonical record)
3. FAYDTA sends a welcome email with login + Discord linking instructions
4. If the member has already linked their Discord account, the @DTA Member role is assigned automatically within seconds
5. The member’s Discord nickname is set to "Name — Business" if their Discord nickname was blank (we never overwrite a nickname they set themselves)
6. The bot sends a welcome DM with a 3-channel tour

When a membership lapses:

1. Stripe fires customer.subscription.deleted after the grace period
2. FAYDTA marks the membership as cancelled
3. The @DTA Member Discord role is removed
4. The member keeps @DTA Verified — they still have a FAYDTA account; just no longer a paying member

Linking Discord to FAYDTA

A member runs /link on Discord. The bot:

1. DMs them a single-use link valid for 10 minutes (the link is never posted in a channel — it goes only to their DM to avoid the wrong person clicking on a shared screen)
2. They click the link → land on faydta.com/account/link-discord → log in → confirm

We then:

1. Write the Discord ↔ FAYDTA mapping to our database
2. Apply roles based on their current tier
3. Set nickname if blank
4. Send the welcome DM
5. Show a success page with their assigned role badge

If they later lose their membership and rejoin, the cycle repeats automatically.

What the board sees

The /account page on faydta.com shows whether a member has linked their Discord, with an “Unlink” button if they want to disconnect. The board can also see, in the admin portal:

• Total active members
• New members in the last 7/30/90 days
• Members who lapsed
• Which members are linked to Discord vs not
• Each member’s payment history, receipt, exact payment method, and custody timeline

Recording a non-card membership payment

Only the Treasurer or an Administrator can record a payment or change its custody state. Other board members can view the member’s payment and custody history.

1. Sign in at admin.faydta.com.
2. Open Members, then select the individual member or business.
3. Under Quick Actions, choose Mark Payment Received. If the member previously said a check was coming, Record Check Received opens the same workflow with Check selected.
4. Choose how the member paid: Cash, Check, Venmo, Zelle, Cash App, Bank transfer, or Other.
5. Confirm the payment date and add the useful reference:
   • Check: check number or payer name
   • Venmo, Zelle, or Cash App: transaction reference or payer handle
   • Bank transfer: confirmation or trace reference
   • Cash: a short identifying note if needed
6. Select the person who first received or controlled the funds. Choose a listed staff member, yourself, or Someone else and enter their full name.
7. Add any note the treasurer will need, then choose Record Payment & Custody.

This creates the $112 membership ledger entry, records the original receiver, activates the membership for the current cycle, and makes the paid receipt available. Email delivery is attempted after the payment is safely recorded, so an email problem does not lose the payment record.

For a payment app, “receiver” means the person or account that initially controlled the incoming funds. If an ACH or app payment went directly into the DTA bank account, record the receiver and then record the bank deposit on the same date.

What not to enter

• Do not enter a full bank-account or card number.
• Do not put passwords, PINs, or login details in a reference or note.
• Use a bank nickname such as “DTA operating account,” not the account number.
• Do not create a second payment to correct a note or custody mistake.

Transferring money to the treasurer or bank

Open the member’s Payment History and find the payment. Its Money custody section shows one of three states:

Status	Meaning	Next action
Needs receiver	A legacy non-card payment exists, but its original receiver was never recorded.	Choose Record Original Receiver before doing anything else.
In custody	The named person currently holds or controls the funds.	Choose Record Handoff or Record Bank Deposit.
At bank	The funds were deposited or transferred to the named DTA account.	No custody action is required; clarification notes are still allowed.

To hand money to another person:

1. Choose Record Handoff.
2. Confirm the handoff date.
3. Select the person taking custody. The Treasurer is selected by default when available.
4. Add a reference or note if useful, then choose Record Handoff.

To close the chain at the bank:

1. Choose Record Bank Deposit.
2. Confirm the deposit or transfer date.
3. Enter the bank or account nickname, not a full account number.
4. Add the deposit slip, transfer, or confirmation reference if available.
5. Choose Record Deposit.

The page immediately updates the current custodian or bank destination. A handoff or deposit date cannot be earlier than the preceding custody event.

Custody and activity logs

Every payment keeps its own chronological custody timeline showing:

• Who originally received the payment
• Every handoff, including both people
• The bank or account destination
• References and operational notes
• Who recorded each event and when

Custody events are append-only. They cannot be edited or deleted after recording, and a deposit closes the custody chain. If an earlier entry needs clarification, use Add Custody Note so the original record and the correction remain visible together.

Payment recording and custody actions also appear in Treasurer Handover → Recent financial activity. Administrators can additionally review them in the full Audit Log. These organization-wide entries identify the staff actor and action, while the member page remains the detailed source for the payment’s full custody chain.

If the wrong member or amount was recorded, stop and contact an Administrator rather than creating a duplicate payment. The system deliberately prevents a second current-cycle membership payment for the same member.

Daily reconcile

Once a day at 6 AM ET, a background job re-checks every linked Discord user against their FAYDTA tier and applies any drift:

• Member who was promoted to board → @DTA Board added
• Member whose subscription lapsed → @DTA Member removed
• Discord user who left the server → marked unlinked in our database (so we stop trying to sync them)

This is the safety net. If any single sync misfires (Discord API blip, network glitch), the next day’s reconcile catches it. The system stays in eventual consistency even if individual events fail.

For other boards

Membership automation is the most common place small non-profits hand-roll. Common patterns we’ve seen elsewhere:

• A spreadsheet of paid members, manually updated, maintained by one volunteer who burns out
• A CRM (Salesforce / HubSpot) for tracking, but disconnected from where the community lives
• Email lists managed in Mailchimp that drift out of sync with actual paying members

The pattern that’s worked for us:

• One database of record. Stripe → our database → everywhere else flows out.
• Tier == access. Role assignment is automatic and downstream of payment status. No board member is granting role-based access by hand.
• Daily reconcile. Eventual consistency is fine. Real-time isn’t worth the engineering complexity.
• Audit trail of who’s linked. When a Discord-side problem happens, we know which FAYDTA user it maps to.

What we deliberately avoid:

• Charging different prices for different tiers within “Member” (it adds complexity for marginal value)
• Making Discord required (some board members in their 60s+ never use Discord; they still need their @DTA Member role to mean something even if they’re not in the server)
• Marketing-style “tier upsell” prompts on the dashboard (we’re a non-profit, not a SaaS)

What we don’t share publicly

Per-member data — payment amounts, contact info, exact join date, address — is private. Aggregate counts (total active members, average tenure) are board-visible. Identifying information about specific members appears in public records only when the member themselves chose to (e.g., their business name on the public directory).