CiviCRM Community Forums (archive)

I have a client who is migrating recurring cc payments to a newish CiviCRM install (3.0).

To do this, it looks like she has to go in anonymously/manually and create the payment via the payment form for each one.

One idea i had to make this easier would be to generate checksum tokens for each user and then add them to the anonymous contribution form url so that they wouldn't have to manually reenter the contact information and worry about matches/merging etc.

Does this make sense? Or is there a better way of importing recurring cc contributions?

the vocabulary is a little confusing here ..

1. the client had recurring contributions stored in another system (Raiser's Edge). In that system they have the cc number (but not the cc code) as well as amount/name/frequency. This information currently gets spat out by Raiser's Edge in some machine readable form each month that is then fed somewhere else (or maybe manually processed, i'm not sure).

2. so they'd like to input these contributions into CiviCRM, preferably a one-time entry as a recurring contribution rather than having to do it each month. As they noticed and you confirmed, they can't do this through the admin interface (though they could re-input them each month through the admin interface).

So, my idea was that the org. staff would input them as recurring contributions through the public interface, masquerading as the constituents/donors (though that would require the cc code, right?). The only issue with that approach would be to make sure the constituent data was clean enough to ensure a match with the existing constituent record, to avoid having to dedupe afterwards - which is where the idea of using a checksum token came from...

But I think you're saying the bin/ContributionProcessor.php is a useful script, so can you point me at a little documentation? Is that a script that they would run each month with the equivalent of what raiser's edge exports?