A donation page should make three things clear: why to give, what the donor is authorizing, and whether the payment succeeded. Build the page around that sequence, with a usable form and clear terms at each step. Start with the donation task rather than a long feature list. The page needs enough context to support a decision, a way to choose and submit the gift, and a confirmation that explains what happened.
Explain the appeal before asking for payment
Use a short headline tied to the mission, followed by the purpose of the appeal. “Donate” is a clear button label, but the surrounding copy should explain what the organization will do with the funds.
An impact statement can help when it is supported by your own program data. If donations support general operations rather than a specific item, say so. Do not imply that every gift purchases an exact outcome unless that is how the program works.
Choose images that accurately represent your work and that you have permission to use. Keep the appeal close enough to the form that people do not have to scroll through a long organizational history before giving.
| Stage | What the donor needs |
|---|---|
| Appeal | Who is asking and what the funds support |
| Gift selection | Amount, currency, and one-time or recurring choice |
| Details and payment | Clear fields, payment options and any additional charges |
| Confirmation | Payment status, amount, next steps and a contact for help |
This is a planning structure, not a requirement to use separate screens. A short form can keep several stages on one page.
Keep the form focused on the gift
Ask for information needed to process and administer the donation. Review extra questions individually: does this need to be collected now, and does the donor understand why?
Use a few relevant suggested amounts alongside a custom-amount option. Show the currency clearly. Mark optional fields, and keep newsletter sign-up separate from the act of donating so the choices are understandable.
For form labels, follow the W3C labeling guidance: each control needs an appropriate accessible name. Persistent visible labels are generally the clearest choice for donation fields.
Your payment provider affects the design. Before approving a layout, check which fields, payment methods, recurring options, and accessible controls its form supports. A design that the chosen tool cannot implement will need to change.
Make recurring gifts and fees explicit
If recurring giving fits the appeal, provide a clear choice between one-time and recurring gifts. Show the frequency, amount, first charge timing, and how the donor can manage or cancel future payments.
Before submission, make the selected option unmistakable. A donor should not have to infer whether a payment repeats from the color of a small tab.
If you offer a fee-covering contribution, show what is optional and how it changes the total. Also check whether the platform adds a separate tip or contribution request. Review the complete amount the donor will authorize, not just the headline gift.
Test the mobile path and error states
Run through amount selection, details, payment, and confirmation on a phone. Check that controls remain usable when the keyboard is open and that important instructions are not hidden below it.
Test an incomplete form and a failed payment using the provider's supported test tools. Error messages should identify the issue and explain the next step. Preserve non-sensitive information where safe, so people do not have to restart unnecessarily. W3C's form notification guidance covers accessible feedback.
Also consider uncertain outcomes. If the network drops after submission, the page should not confidently say either “failed” or “complete” without knowing the payment status. Give the donor a way to check what happened before trying again.
Make payment status and identity clear
Use a recognizable organization name and consistent branding. When payment happens on an external page, make the handoff understandable and provide a route back to your site.
A lock icon or “secure payment” badge does not establish that an integration is secure. Use the provider's supported payment flow, describe it accurately, and have the implementation reviewed rather than adding unsupported security claims.
After a successful payment, show the amount, currency, and any recurring schedule. Explain whether a receipt or confirmation email will follow and how to get help. Distinguish successful, pending, and failed states where the provider exposes them. Avoid presenting a generic thank-you screen as proof of a completed charge.
Before launch, verify the administrative side too: does the transaction appear in the provider's records, and does the intended confirmation arrive? If a CRM integration is in scope, check that it receives the expected record without duplication.
Include a first accessibility check
Try the form without a mouse. Check that controls can be reached and operated, focus is visible, and errors can be located. Keyboard behavior varies by component; Tab alone is not the complete test. W3C's keyboard guidance explains the conventions.
Check readable contrast and usable zoom, including on any hosted payment page. These checks help identify barriers but do not replace a complete accessibility assessment.
For a broader review, use our nonprofit website accessibility checklist.
What changes the scope of the build?
Embedding a supported donation form differs from building a custom payment flow. Recurring gifts, donor accounts, migration, and CRM synchronization add requirements that should be identified before estimating the work.
Separate implementation work from provider subscriptions and transaction fees. A donation page is not automatically the same product as a landing page for paid advertising.
For projects accepted into iQyra's nonprofit program, development within the defined scope is free. The organization pays its external expenses, including applicable platform and payment fees.
See the nonprofit website cost guide for budgeting and the pro bono program for eligibility and terms.
Donation page launch checklist
Use this iQyra checklist to organize testing. Record the result and the person responsible for any remaining issue.
| Area | Acceptance check |
|---|---|
| Appeal | Organization and use of funds are clear; impact claims are supported |
| Gift | Amount, currency and recurrence are visible before submission |
| Fees | Optional additions and the final total are understandable |
| Fields | Required and optional inputs are clear; labels remain usable |
| Mobile | The full flow works on a phone, including the on-screen keyboard |
| Errors | Invalid input and failed or uncertain payments have a clear next step |
| Accessibility | Keyboard operation, focus, labels, contrast and zoom have been checked |
| Confirmation | The displayed payment state matches the provider's actual result |
| Administration | Transaction, email and any in-scope CRM record have been checked |
| Help | A donor can find a contact and manage a recurring gift |