How to Create a Test Donation

Every WeGive organization has a test account: a full sandbox that mirrors your live setup, where you can create donations, supporters, checkouts, and events without touching any real data.

Running a test donation there before you launch is the best way to catch problems while they are still easy to fix. A five minute test tells you whether your checkout collects the right information, whether your receipt reads the way you want it to, whether the supporter record maps correctly, and whether your automated follow up actually sends.

This article covers how to create a test donation in your test account, what payment details to use, and the best practices that keep your testing useful.

What you need before you start

• Access to your WeGive test account

• A checkout in that test account

• An email address you control and can check

No real payment method is required, and no money will move.

Step 1: Switch to your test account

Your test account carries a [TEST] prefix so you always know where you are.

1. Click your name in the top right corner

2. Click Change Login

3. Select the account with the [TEST] prefix, for example [TEST] Your Organization

If you do not see a test account, contact your admin and they can set one up for you.

Confirm the account name in the top corner reads [TEST] before you begin. Everything you create from here lives only in the sandbox. It will never appear in your live Payments table, your live reports, or any of your live integrations.

What your test account is good for: new checkout builds, integrations, custom fields and field mapping, imports, automated journeys, event and fundraiser setup, staff training, and anything you expect to test more than once.

Step 2: Create a test donor identity

Every test donation should use a first name, a last name, and an email address. Give each test its own identity so you can tell your test runs apart later.

The simplest way to create unlimited unique test donors is plus addressing, which almost every email provider supports. Anything you add after a + in your address is ignored for delivery, so the message still arrives in your inbox, but WeGive treats each address as a separate donor.

If your email is you@yourorganization.org:

Two rules for the text after the +:

1. No spaces. you+john smith@yourorganization.org is not a valid email address. Use you+johnsmith@ or you+john.smith@ instead.

2. Describe the scenario when it helps. you+declinedcard@yourorganization.org tells you at a glance what that record was testing.

Keep the name fields consistent with the email so your records stay readable: first name John, last name Smith, email you+johnsmith@yourorganization.org.

Important: Verification emails in your test account is real. Verification Emails and texts sent from the test account go to the actual inbox or phone number on the record. Use dummy donor data only, and never a real supporter's contact information.

Step 3: Enter a test payment method

Your test account accepts standard test card numbers. Nothing is charged, no payout is generated, and no live processor is touched.

The card to start with

Card number: 4111 1111 1111 1111

Then fill in the rest with anything plausible:

The card number is the only value that has to be a recognized test number. Expiration date, security code, and ZIP code are not validated in the test account, so any reasonable entry will pass.

Additional test cards

Use these when you want to test a specific card brand.

Testing failed payments

Testing the unhappy path matters as much as testing the happy path. These cards let you see exactly what a donor experiences when a gift does not go through, and whether your failed payment messaging is set up the way you want.

Testing bank transfer (ACH)

If bank transfer is enabled on your test checkout:

If the flow asks you to confirm two small deposit amounts, enter 32 and 45 to verify successfully.

Step 4: Complete the donation

1. Open the checkout link from your test account, exactly as a donor would receive it.

2. Enter a gift amount and select a frequency.

3. Fill in the first name, last name, and email address from Step 2.

4. Enter the test payment details from Step 3.

5. Answer any custom questions or opt in choices the checkout presents, so you can confirm later that those answers recorded correctly.

6. Submit the gift and confirm that you reach the confirmation screen.

Best practices

Do your testing in the test account, not your live account. This is the whole reason the sandbox exists. It keeps your live supporter database, your reporting, and your integrations clean without you having to remember to clean anything up.

Mirror your live setup before you test. A test is only as good as the configuration behind it. If you are testing a checkout you plan to launch, make sure the designations, custom questions, receipt template, and journeys in the test account match what you intend to go live with.

Test again after every meaningful change. A new designation, an edited receipt, a reworked journey, a change to your suggested amounts: each one is worth a single test donation before it reaches donors.

Use dummy donor data, always. Test account engagement is live. A test record with a real supporter's name or email can send that person an unexpected message.

Name your test donors deliberately. A consistent convention such as you+monthly50@ or you+declinedcard@ turns your test records into something you can actually read a week later.

Test the amounts and frequencies your donors actually use. Include your suggested gift amounts, a custom amount, a one time gift, and a recurring gift. Recurring gifts create a different set of records than one time gifts, so testing one does not test the other.

Test on a phone, not only on a desktop. Most donors give on mobile. Complete a gift on your phone before you launch.

Test at least one failure. Run a declined card so you know what a donor sees and so you can confirm your failed payment follow up is set up correctly.

Read the receipt as a donor, not as an administrator. Check the sender name, the subject line, the amount, the designation name, the tax acknowledgment language, and every link.

Walk the full journey, not just the gift. If a donation triggers a welcome series or a thank you sequence, let it run and read each message in order the way a new donor would receive it.

Keep a short record of what you tested. A few lines noting the date, the checkout, the scenarios you ran, and what you found makes the next launch faster and gives your team a reference point when something looks off.

Tell your team before you test engagement. Since test account messages are real, let colleagues know if a journey you are testing might land in their inbox.

Retest in the test account before you replicate settings live. Once everything behaves the way you want, build or publish the live version with confidence, then run one final gift on the live checkout at the smallest allowed amount if you want a true end to end confirmation, and refund it.

Good to know

• Test gifts never move money. Nothing is charged and no payout is generated, so there is nothing to reconcile.

• Test account data is fully isolated. Transactions, supporters, and reports in the test account never appear in your live account.

• Receipts and triggered messages don't actually send from the test account, however verification messages will send.