A bank-transfer donation is not complete when it is submitted

When a donor submits a bank-transfer donation, create the gift record immediately but keep its payment state pending. Treat a pending ACH donation as a payment attempt, not completed cash: mark it complete only when the processor reports success. Until then, let the status decide whether the payment system, the donor, or your team owns the next action.

This prevents one delayed payment from becoming a premature receipt, a missing gift, or cash that finance expects but cannot find.

Give four events separate jobs

A card payment can look complete within seconds. A bank debit may need account verification and delayed confirmation. Stripe describes ACH Direct Debit as a delayed-notification method that can take up to four business days to confirm success or failure.

Your record should preserve four events instead of compressing them into one date:

1. Submitted: the donor completed the form and authorized an attempt.
2. Action required or processing: the bank account still needs verification, or the payment network is working.
3. Succeeded or failed: the processor has reported the result.
4. Paid out: the successful payment has reached a processor payout and, later, the bank.

Exact labels vary. GoFundMe Pro, for example, documents `Pending` for a bank transfer being processed and `Successful` for a completed transaction (GoFundMe Pro transaction statuses). Use the state your platform actually exposes. Do not create a generic “received” status that hides whether it means form submission, payment success, or bank arrival.

Send a submission message, then a success receipt

The donor needs confirmation that the form worked. Your team needs to avoid saying the money cleared before it did. Those are compatible goals.

At submission, send a short processing message:

We received your bank-transfer request for [amount]. Your payment is processing. We will send a receipt when it is complete. If another step is required, you will receive instructions at [email].

This is a status message, not the final gift receipt. It should include the attempted amount, date, organization, and a reference your team can find.

Send the success receipt only after the platform reports a successful payment. That rule is visible in current provider behavior: GoFundMe Pro waits for an ACH transaction to settle and clear before sending its receipt.

Do not promise one universal delivery time. Tell the donor where the payment stands and what will happen next.

Let the status decide who acts

Most pending payments need patience, not staff intervention. Give each state one owner:

• Ordinary processing: the payment system owns the next move. Record the expected check date and wait.
• Verification required: the donor owns the next move. Send the platform's secure verification route once.
• Failed: one staff owner reviews the stated reason and decides whether a new attempt is appropriate.
• Succeeded, not paid out: finance monitors the payout; donor services does not ask the donor to pay again.

Do not assume every pending state needs a reminder. In one current workflow, GiveCampus uses `pending_authorization` when microdeposit verification is incomplete. That state needs donor action. A payment already processing through the bank may need none.

Likewise, do not refund or recreate a payment merely because it is slow. GoFundMe Pro blocks refunds while a transaction is pending. Your platform may behave differently, but the operating rule holds: check the live state before starting a second money movement.

Preserve failed attempts

A failed bank payment should stop fundraising totals from treating the gift as complete. It should not erase the donor's attempt.

Keep the original submission date, attempted amount, payment method, processor identifier, final status, and failure reason when the platform provides one. If the donor tries again, create or retain a second payment attempt linked to the same donor and campaign. Do not change the first failed attempt to “successful” just because a later payment worked.

This distinction also protects downstream systems. Give Lively documents a Stripe ACH workflow that waits for the payment to clear before sending it to Salesforce. That is one platform-specific example of a broader handoff question: which state is allowed to create the completed gift in your CRM, receipt queue, campaign total, and payout report?

Your accountant should define how pending and failed amounts appear in financial records. The fundraising workflow's job is to preserve the source state and prevent an unsettled attempt from masquerading as completed cash.

Test five cases before launch

Run the full handoff with test or controlled records that expose different owners:

1. A bank account verifies and the payment succeeds.
2. Verification remains incomplete and requires donor action.
3. Processing ends in failure.
4. The donor asks to cancel or refund while the payment is pending.
5. The payment succeeds, but its payout has not reached the bank.

For each case, confirm that your team can answer:

• What did the donor see?
• What is the current payment state?
• Who owns the next action?
• Was a success receipt sent?
• Can finance trace the payment into a payout or a named exception?

The workflow fails if a pending attempt appears as settled revenue, two staff members send different instructions, a retry overwrites the first attempt, or finance must search email to learn why cash is missing.

Keep the payment state attached to the gift

CharityStack's fundraising checkout supports bank transfers, and its operations workspace keeps contacts, payments, receipts, and payouts connected. When you evaluate any system, follow one pending bank gift across those records. The useful test is not whether ACH appears in the payment-method list. It is whether everyone can see what happened and who acts next.