How to Create a Test Donation with Checkout Preview

Scope of this article: this covers both ways to test a donation — the dedicated test account (Option A below) and Checkout Preview mode on a live checkout (Option B below). If you only need the test-account workflow, see the companion article “How to Create a Test Donation” that covers the test account exclusively. Testing a donation before you launch is the single best way to catch problems while they are still cheap to fix. A five minute test donation tells you whether your checkout collects the right information, whether your receipt looks the way you want it to, whether your donor record maps correctly, and whether your automated follow up actually sends. This article walks through how to create a test donation in WeGive, what payment details to use, and the best practices that keep your test data clean and your live data safe.

​

What you need before you start

• Access to your WeGive account
• A checkout you want to test
• An email address you control and can check

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

​

Step 1: Choose where to test

WeGive gives you two ways to run a test donation. Pick the one that matches what you are trying to learn.

​

Option A: Your test account (recommended)

Every WeGive organization has a test account alongside its live account. It is a full sandbox that mirrors your production setup, and it is completely separate from your live data. Transactions you create there never appear in your live Payments table, reports, or integrations. To switch to your test account:

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, reach out to your admin and they can set one up for you. Use your test account for: integrations, custom fields and field mapping, imports, automated journeys, new checkout builds, staff training, and any testing you plan to repeat.

​

Option B: Checkout Preview on a live checkout

If you want a quick look at one live checkout without switching accounts, use Preview.

1. Go to Checkouts and select the checkout you want to test
2. Click Preview
3. Confirm you see the banner at the top of the page reading “This is a test checkout; your payment will not be processed.”

One thing to know: a Preview transaction runs inside your live account. It is clearly flagged as a test in your Payments table, but it will also create a supporter record in your live database and it can still trigger receipts and automated emails. If any of that would be a problem, use your test account instead.

​

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 [email protected]: Two rules for the text after the +:

1. No spaces. you+john [email protected] is not a valid email address. Use you+johnsmith@ or you+john.smith@ instead.
2. Describe the scenario when it helps. [email protected] 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 [email protected]. Note: Verification emails sent from your test account are real emails, and they go to whatever inbox you use. That is helpful when you are reviewing receipt copy, and it is a good reason to never use a real supporter’s address for testing.

​

Step 3: Enter a test payment method

Your test account and Preview mode accept standard test card numbers, but whether a specific test card actually behaves as described below depends on how your organization’s test account is connected to a payment processor. How this actually works: most organizations’ test donations are not sent to any payment processor at all — WeGive marks them successful locally without a real gateway call, so a card number’s digits are never actually validated. The specific decline/failure scenarios below only produce their described failure behavior for organizations whose test account is explicitly connected to a Braintree or Finix account with sandbox mode configured. If your organization is on WeGive’s default processing or another processor, entering any of the numbers below — including the failure-scenario cards — will simply succeed, because the charge never reaches a processor that could decline it. If you need to verify failed-payment messaging works and you’re not sure whether your org’s test account has a sandbox-capable processor connected, ask support.

​

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 test mode, so any reasonable entry will pass.

​

Additional test cards

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

​

Testing failed payments

These scenarios only actually trigger a decline if your organization’s test account has a sandbox-capable processor connected (Braintree or Finix sandbox — see the note above). Testing the unhappy path matters as much as testing the happy path, but confirm your setup first or these cards will simply succeed like any other test card.

​

Testing bank transfer (ACH)

If bank transfer is enabled on your checkout:

​

Step 4: Complete the donation

1. Open the checkout. In your test account, use the checkout’s normal link. On a live checkout, use Checkouts and then Preview.
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. Submit the gift and confirm that you reach the confirmation screen.

​

Best practices

Test before every launch, not just the first one. Any change to a checkout, a designation, a receipt template, or a journey is worth one test donation before it goes in front of donors. Use your test account by default. Reach for Preview only when you specifically need to check something on a live checkout. This keeps your live supporter database clean without you having to think about it. Use dummy donor data, always. A test donation with a real supporter’s name or email creates a record you will have to clean up later, and can send that person an unexpected email. 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. Open the checkout on your phone and complete a gift there 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. Exclude test transactions from reports and integrations. If you do not want test gifts triggering receipts or automated messages, add an audience rule of Test Transaction is false to those triggered messages. Filter test transactions out of any report you share with your board or sync to your CRM. 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. Loop in your team before testing engagement. Emails and text messages sent from a test account are real. If you are testing a journey, let your team know so nobody is surprised by a message in their inbox.

​

Good to know

• Test gifts never move money. Nothing is charged and no payout is generated, so there is nothing to reconcile.
• Reusing an email address merges the gifts. Two donations to you+johnsmith@ attach to the same supporter record. That is exactly what you want when testing repeat giving, and exactly what you do not want when testing a first time donor experience.
• Test transactions can still trigger automated messages unless you exclude them with an audience rule.
• Preview transactions live in your production account, flagged as tests. Transactions created inside your [TEST] account are fully isolated.
• If a test card is declined unexpectedly, clear the card field completely and retype the number. A partially replaced card number is the most common cause.