Success redirect enhancement idea

Ryan Means

We are wondering if it would be possible to include an option to enable the transaction id to be appended to the success redirect URL - similar to how you can use "sign_redirects" option to enable a redirected URL to look like this:

https://mydomain.org/myapplication/conviosuccess.jspx?ts=1256077711&signature=c4c655a1c1ed50b955eaa83f838b7dc1

What we would like is if it could form a URL like so:

https://mydomain.org/myapplication/conviosuccess.jspx?ts=1256077711&signature=c4c655a1c1ed50b955eaa83f838b7dc1&transactionid=1234546789

We're requesting this because our web applications are all hosted externally from convio. We can't get the transaction information from a donation.

Going this route, would allow us to store the returned transaction ID with the additional record we are creating based on their donation in our custom application. Then, using the Convio Web Services route, we could then verify and "sync" transaction details down on a scheduled cron to our internal product that is holding that transaction id that was provided on the success URL. Our cron could then finish off the necessary processing to verify their donation in our internal product.

Any other suggestions as a way to get the transactional details after a transaction from an external app (not on convio's servers) are more than appreciated!

mark.ajws

Maybe try returning the transaction confirmation in xml/json, display a short modal dialogue saying "Your donation was successful, please click here to complete your transaction" along with a few details (name, amount, recurring), then have them click through to a page to your server with all the transaction dynamically appended to the URL. The page they land on then stores the data to your local datastore.

Jeff Mills

You should be able to include any* of the request or response values in redirect URLs. Response values are specified with an XPath like expression, so referring to the sample XML response in the donation API documentation, we see the transaction ID should be referenced like this: "...&ts=${donationResponse/donation/transaction_id}". Request parameters (what was sent in the donation API call) are specified with their form element name, like this: "...&fn=${billing.name.first}...".

* A few values, like credit card information, are not allowed for security and PCI-compliance reasons.

Ryan Means

JeffMills :

You should be able to include any* of the request or response values in redirect URLs. Response values are specified with an XPath like expression, so referring to the sample XML response in the donation API documentation, we see the transaction ID should be referenced like this: "...&ts=${donationResponse/donation/transaction_id}". Request parameters (what was sent in the donation API call) are specified with their form element name, like this: "...&fn=${billing.name.first}...".

* A few values, like credit card information, are not allowed for security and PCI-compliance reasons.

Jeff - this is perfect! I haven't verified the transaction_id field yet since I'm running in preview mode, but I believe it works based on the other fields I'm seeing returned on the URL. This will definitely help us accomplish our goal and making the data sync process much easier!

Thanks!

Can this be put in the donation documentation on the redirect info?

Noah Cooper

Doh! Somehow I didn't see Jeff's response before I hit Reply.

Message was edited by: Noah Cooper

Michael

Ryan Means:

Jeff - this is perfect! I haven't verified the transaction_id field yet since I'm running in preview mode, but I believe it works based on the other fields I'm seeing returned on the URL. This will definitely help us accomplish our goal and making the data sync process much easier!

Thanks!

Can this be put in the donation documentation on the redirect info?

Just wanted to second the request above for Jeff's info to be put into the API documentation. Also, a little more elaborate description of how it works would be helpful...

Oh, one other tip -- if you're just starting to develop a remove d-page using the success and error redirects (and have't really built out those pages yet) and you can't figure out why the form won't actually process, try removing the redirect parameters and submit your donation, you'll get the standard responses from Convio that include error messages.

Steve Mook

Michael :

Just wanted to second the request above for Jeff's info to be put into the API documentation. Also, a little more elaborate description of how it works would be helpful...

Oh, one other tip -- if you're just starting to develop a remove d-page using the success and error redirects (and have't really built out those pages yet) and you can't figure out why the form won't actually process, try removing the redirect parameters and submit your donation, you'll get the standard responses from Convio that include error messages.

This information appears in the current docs under "Substitution of Response Elements in Redirect URLs," here: http://open.convio.com/api/#main.using_redirect_parameters.html

It may be helpful to link to this topic from the description of the redirect parameters.

Colin McClure

JeffMills :

You should be able to include any* of the request or response values in redirect URLs. Response values are specified with an XPath like expression, so referring to the sample XML response in the donation API documentation, we see the transaction ID should be referenced like this: "...&ts=${donationResponse/donation/transaction_id}". Request parameters (what was sent in the donation API call) are specified with their form element name, like this: "...&fn=${billing.name.first}...".

* A few values, like credit card information, are not allowed for security and PCI-compliance reasons.

I'm currently using an xpath expression to bring back field errors in the donation checkout. The expression is this...

errorMessage={donationResponse/errors/fieldError}

The only trouble is when there are multiple errors. Convio just concates all the values together. i.e.

errorMessage=Credit+card+number+is+invalid.You+have+entered+an+amount+that+exceeds+the+maximum+of+%2450%2C000.00+permitted+on+this+donation+form.+Please+enter+a+lower+amount.

I was splitting the value on periods to try and list the errors idividually, but I run into a problem with the decimal in $50,000.00. Is there any way to have a delimiter between the values of the multiple returned nodes?

Ryan Means

Colin McClure:

I'm currently using an xpath expression to bring back field errors in the donation checkout. The expression is this...

errorMessage={donationResponse/errors/fieldError}

The only trouble is when there are multiple errors. Convio just concates all the values together. i.e.

errorMessage=Credit+card+number+is+invalid.You+have+entered+an+amount+that+exceeds+the+maximum+of+%2450%2C000.00+permitted+on+this+donation+form.+Please+enter+a+lower+amount.

I was splitting the value on periods to try and list the errors idividually, but I run into a problem with the decimal in $50,000.00. Is there any way to have a delimiter between the values of the multiple returned nodes?

good point. Because you don't know what the response is going to look like before you send the the parameters on the URL for the xpath you want back, there is no way that to tell xpath to get each field individually.

The xPath synax for donationResponse/errors/fieldError says get all the fields named "fieldError" under that path. We can't specify /fieldError, /fieldError, /FieldError .. etc.

I'm in full agreement that not just for the fieldError field, but for any field that may produce multiplets, a common delimiter needs to be provided OR even better in my option you need to return it on the URL like this:

Given this:

errorMessage={donationResponse/errors/fieldError}

Should return like this for cases where there are multiple fieldError nodes matched:

errorMessage_1=Some+value&errorMessage_2=Another+value

** EDIT - temporary workaround?

The only thing I can think of as a workaround is to call it as if it did have those fields, not sure if convio would return them null or not if not set, but it's worth a shot:

errorMessage_1={donationResponse/errors/fieldError}&errorMessage_2={donationResponse/errors/fieldError}&errorMessage_3={donationResponse/errors/fieldError} ... etc. Just make sure you give yourself enough for all the possible errors!