When migrating from another payment processor (such as Blackbaud, BluePay, or Celero) into WeGive, recurring plans that already exist in your CRM (like Salesforce or Virtuous) need to be linked to the correct new payment tokens before they can be processed through WeGive.
This guide explains what’s required, why it’s necessary, and what your team needs to provide to complete the token transfer successfully.
What Is a Token Transfer
A payment token is a secure, encrypted reference to a donor’s saved payment method. When you migrate to WeGive, your existing processor can export these tokens so that donors do not need to re-enter their payment details.
For WeGive to correctly match each imported token to your existing recurring donations in Salesforce (or another CRM), we need a clear data link between the two systems.
Why a Mapping Document Is Required
Your recurring plans already exist in your CRM with their own unique Recurring Donation IDs.
The payment tokens, however, come from your old processor and reference a separate system ID (for example, a Blackbaud Recurring Gift ID).
To connect these two systems, WeGive needs a mapping document that shows how each recurring plan in your CRM corresponds to its original token.
This ensures that:
-
The correct token is assigned to the right donor and recurring plan.
-
Donors are charged seamlessly without needing to reauthorize their payment method.
-
Recurring donation history and reporting remain accurate after migration.
What You Need to Provide
WeGive will need three files to complete the mapping and token transfer process:
| File | Description | Required Columns |
|---|---|---|
| 1. Old System Export | Export of recurring plans from your previous processor (e.g., Blackbaud, BluePay). | Old System ID, Token ID, Donor Name or Email, Amount, Frequency |
| 2. New CRM Export | Export of recurring donations from Salesforce or your CRM. | Salesforce Recurring Donation ID, Donor Name or Email, Amount, Frequency, Old System ID (if available) |
| 3. Token Transfer Spreadsheet | Provided by your old processor or payment vendor. | Token ID, Expiration Date, Card Brand, Last 4 Digits |
These three datasets allow WeGive to establish a connection between:
New Token → Old Token → Old Plan → New CRM Recurring Plan
Example Process
-
Your team requests a token transfer from your previous processor.
-
The processor provides the token transfer spreadsheet containing the old token IDs.
-
You export recurring plans from your old system (including token IDs) and from Salesforce (with old system references).
-
WeGive merges and matches the exports to map every plan correctly.
-
Once verified, WeGive imports the recurring plans into the platform with the correct token references.
Deliverables Summary
Please provide the following files to your WeGive Implementation Manager:
-
Export from your old system (including token IDs)
-
Export from your CRM (including old system references)
-
Token transfer spreadsheet from your payment processor
Once these files are received, WeGive will complete the data matching and confirm before activating recurring charges.
Important Notes
-
Do not edit or modify token IDs in any of the spreadsheets.
-
Do not create new recurring donations manually in WeGive until the transfer is complete.
-
If your CRM does not store the old system ID, coordinate with your WeGive contact to confirm an alternate linking field.
-
Once mapping is finalized, WeGive will verify accuracy before enabling processing for recurring donations.
Summary
| Step | Responsibility | Deliverable |
|---|---|---|
| 1 | Client | Request token export from old processor |
| 2 | Client | Provide old and new system exports |
| 3 | Client | Send token transfer spreadsheet |
| 4 | WeGive | Map and validate all recurring plans |
| 5 | WeGive | Import and confirm successful migration |