Skip to main content

​
Overview

The Import Wizard can change payments that are already in WeGive. You do this with the Update action on the Donations and Payments object type. Update never creates new payments. Each row in your file is matched to one existing payment, and the values you mapped are written onto it. Typical uses:
  • Store a reference number from another system (a CRM record ID, a bank deposit number, a batch label) on a group of payments.
  • Fill in a Static custom field on a payment, such as a grant cycle or an accounting code.
  • Mark a specific list of payments with one shared value so you can find them again with a filter.
If you want to update supporters instead of payments, see Importing Existing Supporters.

​
Before you start

  1. Create the custom field first, if you plan to use one. In Settings > Custom Fields, create a field on the Transaction object with the type Static. Only Static fields appear in the import mapping list. Computed fields are calculated by WeGive and cannot be written by an import. See Custom Fields.
  2. Build a CSV with one row per payment you want to change. Include a column that identifies the payment (see “Choosing the identifier”) and a column for each value you want to write.
  3. Save the file as UTF-8 CSV.

​
Steps

  1. Go to Data > Imports and click + to start a new import.
  2. Choose the Update action and the Donations and Payments object type.
  3. Upload your CSV.
  4. On the mapping screen, map the identifier column to its matching WeGive property (for example WeGive ID).
  5. Map the column holding your new value to one of these:
    • your Static custom field, which appears in the property list under the custom field’s name, or
    • Custom ID, a free-text field on every payment.
  6. In Primary Identifier, pick the identifier you mapped in step 4. It must be one of the fields you mapped.
  7. Review and run the import. Download the results file afterward to see which rows succeeded and the error on any row that did not.

​
Choosing the identifier

For payments, the Primary Identifier can be any one of:
  • WeGive ID (the payment’s own WeGive ID)
  • Salesforce ID
  • NPC ID
  • Virtuous ID
  • HubSpot ID
  • PlanningCenter ID
  • Custom ID
Update matches on only the identifier you pick. Every row in the file must have a value in that column. A row with an empty identifier fails, and a row whose identifier matches no payment fails with “Transaction does not exist”. If an identifier matches more than one payment, that row fails rather than guessing.

​
Writing the value

  • Static custom field. The text in the mapped column is saved to the field on the matched payment.
  • Custom ID. The text is saved as the payment’s Custom ID. You can later filter the Payments table by Custom Import Reference to find every payment carrying that value, then act on the whole set (for example, archive them). If you give many payments the same Custom ID value, do not choose Custom ID as the Primary Identifier in that import. Use WeGive ID (or another unique ID) to match the payments and Custom ID only as the value being written.
Blank cells are ignored. An empty cell never erases a value already stored in WeGive.

​
What an Update cannot change

  • Some payment fields are protected and silently skipped, including the payment processor, payout, platform fee, refunded amount, and the organization the payment belongs to.
  • For payments that were actually processed through a payment processor, Amount, Fee amount, Status, and As Guest are also skipped. Those fields can only be changed on imported or manually recorded payments.
  • The payment’s donor cannot be changed with Update. The donor lookup columns are only offered for the Create action. To move a payment to another supporter, see How to Move a Transaction to Another Supporter.

​
Storing an ID from another system

The mapping list for payments includes ID columns for a fixed set of systems: Neon, Salesforce, NPC, PlanningCenter, Virtuous, HubSpot, Bloomerang, Raiser’s Edge, DonorPerfect, and Little Green Light. There is no dedicated column for a DonorDirect ID. If you need to keep a payment ID from DonorDirect or any other system that is not on that list, create a Static custom field on the Transaction object (for example, “DonorDirect payment ID”) and map your ID column to it, or use Custom ID.

​
Tips

  • Test with a small file first. Update 5 to 10 payments and check them before running the full list.
  • Keep the results file. It shows the outcome of each row, which is the quickest way to find mismatched identifiers.
  • Use a Custom ID value you can recognize, such as a short batch label, so your filter is easy to build later.
Last modified on October 30, 2026