Donation API - can you tell the API which constituent is making the donation?

Ryan Means

We're looking for a way in which we can tell the donation API which constituent is making the donation. We've been having a common issue across several of our custom applications and usage scenarios in which our custom applications know exactly who the constituent is upon them logging into our custom applications. However, we can't seem to find a way for users to be able to make a donation when we know exactly who the constituent is. I had asked about the proxy ID before, but that is not used for what we are trying to do. We really didn't want to just use email address as in our scenario we had to open up email to not be forced to be a primary key as constituent.

Any ideas are welcome. Specifically this is being used by apps external to convio domains and we'll be using the donation API with signed redirects, etc.

Ryan Means

I know this post is old - but I wanted to check to see if any new advancements in the donation API had been considered for this? We have the constituent ID available that is making the donation, but many times, the email address being used for the donation ends up creating a new constituent record or is for a different constituent then the one that is actually making the donation - it's rather difficult to explain why this can happen in our usage scenario - but an email address does not always equate to a single constituent. If we could set the constituent ID on the donation, then we would save ourselves a lot of work time in merging duplicates and correcting donations because they were associated to the wrong constituent record.

Any ideas? I highly doubt the API supports this at this time (Although I've been wrong several times before as the documentation just wasn't fully updated).

Noah Cooper

Ryan Means:

I know this post is old - but I wanted to check to see if any new advancements in the donation API had been considered for this? We have the constituent ID available that is making the donation, but many times, the email address being used for the donation ends up creating a new constituent record or is for a different constituent then the one that is actually making the donation - it's rather difficult to explain why this can happen in our usage scenario - but an email address does not always equate to a single constituent. If we could set the constituent ID on the donation, then we would save ourselves a lot of work time in merging duplicates and correcting donations because they were associated to the wrong constituent record.

Any ideas? I highly doubt the API supports this at this time (Although I've been wrong several times before as the documentation just wasn't fully updated).

If you have the cons_id, why not use the Single Sign-On API methods to log the constituent in first?

Ryan Means

Noah Cooper:

If you have the cons_id, why not use the Single Sign-On API methods to log the constituent in first?

Since the last update, we did try that. However, the donation API would still default to the email address that was being submitted with the donation as being the constituent to match to instead of the logged in user via the SSO API. To make a long story short, we were forced to come up with an entirely new solution that is working for us. Since we know our internal member id that is stored on a constituent of the user donating and all we really care is that the correct constituent member id makes the donation - we are using a coded email address of our own such as memberID#####@oursite.com to make the donation with. The end user doesn't see this since it is a hidden field within our application. While this creates a new constituent record for our coded email address, it does so in a manner that we have the correct constituent making the donation and comes down exactly the way we want it on our batch files. The receipted email that convio sends to the memberID#####@oursite.com address then comes into our email distribution center which then rebrands the email and forwards it on to the correct email address that made the donation.

A very big round-about way about the problem, but one that was necessary due to the importance of this application we are releasing tomorrow that is using the donation API. Our only issue that remains now is an issue with the donation API loosing write-in donations when you use more than one write-in on the donation. Convio receives all of the write-in's because they correctly bill the constituent, but there is an incomplete record of the write in donations in the convio database, both via the reports we ran and via hunting through the convio web services console.This issue is easy to duplicate, just make a donation with 5 write-in's all on the same form, only one of the write-in's will process and show up in the database and reports, the rest will be totaled in the bill to the constituent, but will not be recorded. We have a support case for this open and are disabling that part of our product until convio can resolve the issue.

Thanks for the suggestion!