Troubleshooting member payment problems

Symptom-first guide for the payment, autopay, and refund questions members raise. For the admin-side mechanics and console steps behind each of these, see Autopay and saved payment methods and Refunding a payment.

What happened: paying by card adds a disclosed processing fee (configured in Settings), calculated so the club still nets the full invoice total after Stripe's own fees. This applies the same way regardless of whether the card is credit or debit.

Say to the member: "That's the card processing fee, shown before you confirmed checkout — the pool doesn't keep it. Paying by bank transfer (ACH) avoids it entirely and is the default option at checkout."

What happened: this is normal. ACH is the default payment rail and takes several business days to settle. The invoice sits in processing until Stripe confirms the transfer actually cleared, then flips to paid.

Say to the member: "Bank transfers typically take a few business days to fully clear — your invoice will show 'processing' until then, then flip to paid. No action needed on your end."

What happened: with the "bank transfer — you send the money" option, checkout ends by showing the member transfer instructions, and the invoice sits in processing until their bank actually sends the funds. Until money arrives there is nothing for the club to hold, so the member can end that attempt themselves.

Say to the member: "Open the invoice in the portal — under the 'Awaiting your bank transfer' notice there's Cancel and choose a different method. That ends the transfer attempt and puts the payment options back, so you can pay by bank debit or card instead. Don't send the transfer after canceling."

If the button isn't there: either the page hasn't caught up with checkout yet (refresh in a minute), or part of the transfer has already arrived — a partially funded transfer can't be canceled from the portal; the member should send the remainder, or escalate so staff can sort out the balance. A transfer nobody ever sends is unwound automatically after the stale window configured in Settings (default 14 days), which reopens the invoice and resumes reminders.

What happened: the platform writes a claim row before it asks Stripe to open checkout, so two tabs or two clicks can never create two charges on one invoice. While that claim is unresolved every pay control on the invoice is hidden — deliberately. Almost always it clears within seconds. If Stripe never opened the checkout page (an outage, a network blip, a browser closed mid-request), the claim can be left standing with nothing behind it.

Say to the member: "Nothing was charged and your invoice hasn't changed. Reload the invoice page — after a few minutes you'll see Try again on the notice. That clears the stuck attempt and puts the payment options back."

If they don't want to wait: the platform also sweeps stuck attempts once a day, so the invoice becomes payable again on its own by the next morning at the latest. Both routes check with Stripe first and will leave the attempt in place if Stripe says a checkout page really does exist for it — in that case the member is offered Resume checkout instead, which is the same payment, not a second one. Never mark the invoice paid by hand: payment truth comes only from Stripe.

What happened: with "bank transfer — you send the money", Stripe matches the incoming transfer to the invoice's payment request and applies exactly the amount requested; the invoice is paid and shows one payment for that amount. Anything over that stays in the member's cash balance at Stripe — it does not land on the invoice, it is not booked in the platform, and it is not lost. The platform raises an ops alert naming the household and the amount left over; if nothing is done, Stripe automatically returns unclaimed funds to the member's bank after about 75 days. (The other way a transfer can "overpay" — the invoice balance dropped while the transfer was in transit, for example a check arrived first — is handled automatically: the difference becomes account credit on the household and is applied to any other open invoice; see Invoices, payments, and credits.)

Say to the member: "Your invoice is paid. The extra amount is held at our payment processor — we can apply it to your next charge or return it to your bank; let us know which you'd prefer."

Staff action: open the household's customer in the Stripe dashboard, find Cash balance, and either apply the funds to an open payment request or return them. A return needs nothing recorded in the platform; funds applied to another invoice's payment request are recorded by that invoice's own webhook.

What happened: common causes are a closed account, insufficient funds, or a mistyped account/routing number.

Resolution: have the member update their saved bank account and retry payment. Never manually mark the invoice paid — payment truth comes only from Stripe, and a manual override would be wrong the moment the real charge does or doesn't land.

What happened: this is a genuine bank return or a chargeback/dispute — the bank reversed a settled payment. The platform reacts automatically: the payment is marked failed, the invoice reopens, and if a bond claim had been made against that payment, it's clawed back. An internal alert is raised for staff.

Resolution: escalate to admin rather than re-charging the household by hand — a chargeback needs to be tracked as a dispute, not treated as a simple failed payment.

What happened: three possible reasons — (1) the household never completed the mandate step that makes a saved bank account chargeable off-session (Stripe's setup flow, or checking "remember this account" during a checkout), so the account shows as saved but autopay can't use it; (2) autopay auto-disabled after two consecutive failed charges on the household; or (3) an admin engaged the platform-wide "Pause autopay charges" control at Admin › Ops — a rare incident-response lever that stops charges and notices for every club, not just this one, until an admin disengages it.

Resolution: for (1) and (2) — there's no admin view of a household's saved payment methods or mandate status today, so ask the member to open the portal's Payment methods page themselves; a method that's saved but not offered for autopay never completed mandate consent. Have them re-add it through Add a bank account. If autopay was auto-disabled (check the household's Activity tab for the disable notice), the member needs to re-enable it after fixing the payment method. For (3) — check Admin › Ops; an engaged pause is expected to affect every household at every club, not just the one asking, until it's disengaged.

What happened: autopay always sends a notice email/text before charging — roughly a day ahead of the charge. The charge date itself defaults to 10 days before the dues deadline (configured in Settings) unless the household picked a different date.

Resolution: check when the notice went out relative to the charge — it should be roughly a day prior. If the member says they never got a notice, check their email/SMS delivery status; a bounced notice delays the charge to a later pass rather than skipping the warning; if a charge did fire without a preceding notice reaching them, that's worth escalating.

What happened: saved payment methods mirror Stripe — they aren't stored independently. Removing a method at checkout, removing it directly with their bank/card issuer, or a card simply expiring can all cause it to disappear here too.

Resolution: have the member re-save a payment method through the portal.

What happened: it depends on the invoice kind, and the platform enforces this — staff can't override it:

• Camp, merch, event, facility, misc, refunded back to the original card/bank via Stripe.

• Dues, issued as account credit, not cash back to a card or account.

• Initiation / bond: always a mailed check (a refund payable), never a Stripe refund.

Say to the member: for camp/merch/event/facility/misc: "That refund goes back to the card or bank you paid with — it can take a few business days to show up once it's issued." For dues: "That comes back as account credit toward a future invoice, not a refund to your card." For bond/initiation: "Bond refunds are always mailed as a check, not returned to a card — check with the office on where it is in the check run."

Point the member (or yourself, for status) to Relinquishment for bond check-run status.

• Disputed chargebacks or anything that smells like fraud.

• A refund request that doesn't match the invoice-kind rules above (e.g., a member insisting a bond be refunded to their card).

• Autopay charging without any notice having gone out at all.

• Waitlist offer-expired emails did not send before 2026-08-19 (#268, since fixed). If a member's offer expired before then and they say they never heard, that gap is why; expirations after the fix are emailed.

• Card surcharge is applied the same way to debit and credit cards today. There is no debit-specific exemption.