The confirmation screen should match the receipt and record

A donation confirmation page should first prove the gift. Show the organization, amount, frequency, purpose, transaction reference, receipt expectation, and correction path. Only after those facts are clear should you ask the donor to share, subscribe, volunteer, or make another choice.

Treat the screen as the first gift record the donor can inspect. It should agree with the emailed receipt and the transaction stored in your fundraising system.

Confirm what completed

Do not use the same success message for every payment state. A completed card payment, a bank transfer awaiting settlement, and a failed attempt are different outcomes.

For a completed gift, show:

• your organization's name;
• the amount and currency;
• one-time or recurring frequency;
• the campaign or purpose the donor selected;
• a transaction or confirmation reference;
• where the receipt will be sent; and
• a real path for corrections or questions.

If the payment is still pending, say that directly and explain what the donor should expect next. The existing CharityStack guide to pending bank-transfer donations explains why submission and completion must remain separate states.

Do not display a success headline merely because the browser reached a return URL. The page needs the payment result from the system that processed the gift.

Make the screen match the gift

The confirmation page, emailed receipt, and stored gift are three views of one transaction. Test them together.

Choose one test gift and compare the amount, frequency, donor identity, campaign or designation, transaction reference, and timestamp across all three records. A mismatch is not a copy problem. It is a record or state problem that should be resolved before the page becomes a place for another ask.

Current donation-page guidance from GoodUnited recommends showing the amount, organization, receipt expectation, and next action after submission. FormsGuard's current guide similarly recommends an on-screen confirmation, amount and frequency, receipt timing, and a support path rather than relying only on email.

Use those elements as a starting checklist. Your actual pass condition is stricter: the visible values must come from the completed transaction, not from what the donor selected before payment.

Give recurring donors the schedule they accepted

A recurring confirmation needs more than “monthly gift received.” Show the amount, frequency, first successful charge or start date, the next expected charge when known, and where the donor can manage or cancel the plan.

The National Council of Nonprofits' current recurring-donation guidance recommends sending an electronic confirmation that restates the terms and gives clear cancellation instructions after signup. Keep that information beside the success state so the donor does not need to reconstruct the schedule from a later email.

If a future charge date is not final, label it as expected. If the first payment is pending, do not describe the recurring plan as active yet.

Set a receipt expectation without confusing the thank-you

Tell the donor which email address will receive the receipt and what to do if it does not arrive. Mask the address if displaying it in full would create a privacy risk on a shared device.

The receipt and thank-you still do different jobs. The receipt confirms the transaction while the thank-you carries the relationship message. The on-screen page can do both briefly, but it should not imply that a warm message replaces whatever acknowledgment your organization is required to provide.

Keep correction instructions close to the transaction facts. “Wrong email?” or “Something looks off?” is more useful than a generic contact link because it names the reason a donor may need help.

Put promotion after proof

Many confirmation-page guides suggest social sharing, volunteering, newsletter signup, or another donation. Qgiv's donation-form guidance lists several post-gift engagement options. Those can be useful, but they should never displace the transaction proof.

Use one optional next action, place it below the confirmed gift details, and make it visually secondary. Choose the action that belongs to the campaign. A ticket buyer may need event details. A new monthly donor may need account access. A one-time campaign donor may benefit from an update signup.

Test the state, not only the copy

Run the confirmation flow with at least four cases:

1. a successful one-time gift;
2. a successful recurring signup;
3. a payment that remains pending; and
4. a failed or abandoned payment that must not show success.

For each case, compare the screen, receipt event, and stored gift. Refresh the page and use the browser back button. Confirm that neither action creates a second gift or changes a failed state into a success message.

Include this post-submit check when you test the full donation form before launch. The form is not finished when the payment button works. It is finished when the donor can see what happened and your team can prove the same result in the record.