df_preview not working?

Options

so, i am building a donation API request, and df_preview is not working, the request looks something like the following



params = 'billing.name.last=Reid&billing.address.street1=1730+La+Loma+Ave&df_preview=true&billing.address.street2=&billing.address.country=United+States&billing.address.city=Berkeley&level_id=XXXX&other_amount=4823&response_format=json&method=donate&card_exp_date_month=1&billing.address.zip=94709&card_exp_date_year=2009&billing.address.state=CA&form_id=XXXX&api_key=XXXXXXXXXXX&billing.name.first=Nick&card_cvv=111&summary=both&donor.email=nick.reid%40donordigital.com&v=1.0&card_number=4111111111111111';
new Ajax.Request("https://my.care.org/site/CRDonationAPI",{
"parameters"arams,
"onComplete":function(transport){
alert(transport.responseText);
}})

What i get back is



{"errorResponse":{"code":"1","message":"Unable to process request."}}

If i remove the df_preview argument, it will return a correct donationResponse (with an error)

is anyone else having this problem? Ive used the donations api w/preview before and it worked like magic . . .

Tagged:

Comments

  • I'm also having problems with df_preview. This if my first time using it, so I may be missing something else? I'm getting the same error response back.

  • Ryan Means:

    I'm also having problems with df_preview. This if my first time using it, so I may be missing something else? I'm getting the same error response back.

    I'm continuing to verify that there is a problem. Not filling out a credit card number correctly, or leaving off another required field the API will return me an appropriate result letting me know what I did wrong. But when I submit a complete form with all the values set, rather than letting me continue onward in a preview mode it just throws a "generic error". I would think I was doing something wrong, but seeing how i'm not the only person having problems with this, is this a known issue right now?

  • Ryan Means:

    I'm continuing to verify that there is a problem. Not filling out a credit card number correctly, or leaving off another required field the API will return me an appropriate result letting me know what I did wrong. But when I submit a complete form with all the values set, rather than letting me continue onward in a preview mode it just throws a "generic error". I would think I was doing something wrong, but seeing how i'm not the only person having problems with this, is this a known issue right now?

    Is this built in a pagebuilder page? I see the alias for your site is my.care.org, but I'm wondering if Convio is blocking that request for security reasons? I have a version working in test that is going to secure3.convio.net/uw/site/CRDonationAPI....

  • Ryan Hagg:

    Is this built in a pagebuilder page? I see the alias for your site is my.care.org, but I'm wondering if Convio is blocking that request for security reasons? I have a version working in test that is going to secure3.convio.net/uw/site/CRDonationAPI....

    Nick's page might be my.care.org - that's not ours. The page that is failing for us is not a page builder page, it's from our own site. But from what I understand of the API, none of that should matter as this is a client API - so the request being sent to the API is always coming from the user's browser as it is posting to it directly.

  • Ryan Means:

    Nick's page might be my.care.org - that's not ours. The page that is failing for us is not a page builder page, it's from our own site. But from what I understand of the API, none of that should matter as this is a client API - so the request being sent to the API is always coming from the user's browser as it is posting to it directly.

    One point of clarification - this is actually my first form with the API and convio. We have another person that handles all of the convio administration, setting up non-api forms, etc. So I am rather clueless as to what is going on in the form. Is there a mode or setting the donation form setup by our site administrator has to be in order to support testing with df_preview flag?

  • Ryan Means:

    Nick's page might be my.care.org - that's not ours. The page that is failing for us is not a page builder page, it's from our own site. But from what I understand of the API, none of that should matter as this is a client API - so the request being sent to the API is always coming from the user's browser as it is posting to it directly.

    I actually got the df_preview function to work, its supposed to be a url var, not a post var . . . (?df_preview=true)

    the site im setting up is completely external to convio, so this DOES WORK.

  • Nick Reid:

    I actually got the df_preview function to work, its supposed to be a url var, not a post var . . . (?df_preview=true)

    the site im setting up is completely external to convio, so this DOES WORK.

    Actually, I think I just identified the problem (at least for me), and it appears to be a bug in convio's framework. I was able to keep it as a hidden field in the form and not include it in the URL. However, my problem was that I had the summary parameter as a hidden field on the form - "name="summary" value="data" - which is a valid paramater according to their document. Not sure what exactly this is supposed to do, but I assumed I needed it and that I just wanted the data back. That's what threw the problem, removing this parameter all-together has solved my issue and returned me the valid XML result back I was looking for! .. too bad "Generic Error" couldn't tell me that. And their documentation doesn't help you either.

    In general, I've noticed a very lacking API documentation on their open.convio.com site. I had to go hunting just to find the df_preview tag... API's are only as good as their documentation

  • Nick Reid:

    I actually got the df_preview function to work, its supposed to be a url var, not a post var . . . (?df_preview=true)

    the site im setting up is completely external to convio, so this DOES WORK.

    Nick,

    Just an FYI, if you are completely outside of the Convio servers, then your servers need to be PCI compliant too.

  • Ryan Means:

    Actually, I think I just identified the problem (at least for me), and it appears to be a bug in convio's framework. I was able to keep it as a hidden field in the form and not include it in the URL. However, my problem was that I had the summary parameter as a hidden field on the form - "name="summary" value="data" - which is a valid paramater according to their document. Not sure what exactly this is supposed to do, but I assumed I needed it and that I just wanted the data back. That's what threw the problem, removing this parameter all-together has solved my issue and returned me the valid XML result back I was looking for! .. too bad "Generic Error" couldn't tell me that. And their documentation doesn't help you either.

    In general, I've noticed a very lacking API documentation on their open.convio.com site. I had to go hunting just to find the df_preview tag... API's are only as good as their documentation

    I had this same problem with the summary="data" parameter. I had to send a support request to get someone to figure it out. They should really update that in the documentation. They should also provide some kind of realistic test response for use with df_preview so that I can map out the resulting data.

  • I think that it will work if you remove the argument "sumary=both". I think that I remember seeing this once before and tracing it down to a NullPointerException that occurs because the transaction does not really get processed.

    I'm doing some stuff in the donation API right now, so I'll try to dig into it and make a permanent fix.

    Sorry about that. If it's not already apparent, the errorCode=1 essentially means that an Exeption was thrown in the processing and caught at the outermost processing in the API. It's essentially the equivalent of the "Technical Difficulties" page.

    Dave

  • DavidHart :

    I think that it will work if you remove the argument "sumary=both". I think that I remember seeing this once before and tracing it down to a NullPointerException that occurs because the transaction does not really get processed.

    I'm doing some stuff in the donation API right now, so I'll try to dig into it and make a permanent fix.

    Sorry about that. If it's not already apparent, the errorCode=1 essentially means that an Exeption was thrown in the processing and caught at the outermost processing in the API. It's essentially the equivalent of the "Technical Difficulties" page.

    Dave

    Hey Dave,

    I'm having a similar problem with the generic error message, but not the same coding exactly (I took it from an example hosted by Convio). The page I'm trying to make work with an API is at https://secure.operationsmile.org/site/SPageNavigator/API_Preliminary linking to ghost form https://secure.operationsmile.org/site/Donation2?df_id=3380&3380.donation=form1. I filed a support case on it about 2 weeks ago and still haven't heard back, so i wondered if someone else in the community might have some solutions as I want to get this working for A/B testing.

  • Matt Burghdoff:

    Hey Dave,

    I'm having a similar problem with the generic error message, but not the same coding exactly (I took it from an example hosted by Convio). The page I'm trying to make work with an API is at https://secure.operationsmile.org/site/SPageNavigator/API_Preliminary linking to ghost form https://secure.operationsmile.org/site/Donation2?df_id=3380&3380.donation=form1. I filed a support case on it about 2 weeks ago and still haven't heard back, so i wondered if someone else in the community might have some solutions as I want to get this working for A/B testing.

    Matt --

    I can tell by the dates you have been waiting for an answer for 3 weeks now . . . i hope you got this solved, but here is the problems i found in your form

    1) https://secure.operationsmile.org/site/CRDonationAPI&df_preview=true should actually be https://secure.operationsmile.org/site/CRDonationAPI?df_preview=true

    2) It looks like your form_id and level_ids are incorrect if you are using the form you have posted . . .meaning, form_id=3280 needs to be form_id=3380

    When i made these changes (w/firebug) . . . the form processed happily . . . good luck with your A/B test . . .

  • Nick Reid:

    Matt --

    I can tell by the dates you have been waiting for an answer for 3 weeks now . . . i hope you got this solved, but here is the problems i found in your form

    1) https://secure.operationsmile.org/site/CRDonationAPI&df_preview=true should actually be https://secure.operationsmile.org/site/CRDonationAPI?df_preview=true

    2) It looks like your form_id and level_ids are incorrect if you are using the form you have posted . . .meaning, form_id=3280 needs to be form_id=3380

    When i made these changes (w/firebug) . . . the form processed happily . . . good luck with your A/B test . . .

    Hi Nick,

    Thanks for the response, but I did manage to figure it out on my own and get Convio's approval of the form as good coding. What was throwing me was a simple error on my part - I wasn't putting the df_preview in the proper place and wasn't sure exactly what I was reading. For those who, like me, sometimes need things spelled out, the code I used which worked was:

    <form id="donate_form" method="post" action="https://secure.operationsmile.org/site/CRDonationAPI&df_preview=true" ]::true::::smileysurprised:nsubmit="submitFormUsingAjax();return false;"]] >

    (Added the "&df_preview=true" section which hadn't been there initially in the posting method, I originally thought the Convio S334 conditional was putting that in instead of just checking to see if it was there. It looks like you accomplished the same thing, just with a "?" instead of an "&".)

    Since getting it to work in preview mode, I've switched it back to the donation form I originally wanted it to link up to, the one which allows for recurring giving. We've done two successful live transactions using cards from people in the office - refunded immediately, of course - and all appears to be working perfectly. The only last thing I want to tweak is getting the custom form element - the "How'd you hear?" info - to stop passing the first option of "Please Select..." as a valid response, but that's more a perfectionist thing since we have that same problem with our current pages.

Categories