updateRecurringCreditCardInfo API Questions

Options
Hi,



We just happened to be testing / playing around with the updateRecurringCreditCardInfo API and have the following questions as result of our testing.



The first one, when attempting to update the credit card payment I got the following error code 612001 and would like to reconfirm whether does this means that we could only update an active and ongoing recurring gift and not the "COMPLETED" or "CANCELLED" ones ? (as we are currently under the impression that updating the associated cc used for the latter would actually reactivate the recurring gift, but pardon me if it is not).



The second one, this is more of security best practice purpose. Aside of having the pagebuilder as a secure page and not proxying that, if we use "password" type text input within the form for the Credit Card related fields (i.e. number, cvv) will the API pass it just fine to the backend for processing? or is there any common best practices that we might probably be missing out thus would like to know.



Thanks in advance for your help and time!



regards,

Daniel​
Tagged:

Comments

  • Stephen Richarme
    Stephen Richarme Blackbaud Employee
    Ancient Membership First Comment Loyalty Badge Activity: First Reply
    Error code 612001 translates to "No recurring gift found" according to the error codes page:

    http://open.convio.com/api/#main.error_codes.html



    Most likely, this does mean that constituents (donors) cannot update a "COMPLETED" or "CANCELLED" recurring gift, but only active/ongoing recurring gifts. If you run into a situation where a constituent would want to update a completed/cancelled recurring gift, the easiest solution is to direct the constituent to a donation form, where they can make a new recurring gift with the appropriate updated information.



    You might verify a few things to confirm this issue:

    1) Does the recurring_gift_id you are sending in the "updateRecurringCreditCardInfo" call match a recurring_gift_id returned by a "getRecurringGifts" call?

    2) Are you submitting the "updateRecurringCreditCardInfo" with an authentication token identifying the logged-in user that made the original donation, or with valid API administrator credentials (for Server API calls) and passing the cons_id of the user that made the original donation?



    For the second question, the "password" input type is only different from the "text" input type in the display to the user in their browser - the "password" input type automatically masks the characters typed by the user with asterisks or circles, while the "text" input type shows the user what they have typed. However, the value entered by the user is still accessed the same way by JavaScript, so your form submission should treat a "password" input type exactly as it would treat a "text" input type.



    For example, if I have the following two fields on a form:

    <input type="text" id="my_text_field">

    <input type="password" id="my_password_field">

    These will appear as two text input fields, with the difference that the user will see asterisks or circles when they type in the second field, rather than the text that they typed (which they would see in the first field). JavaScript, however, can access the values typed by the user in each of these fields directly. So, if I typed "12345" in each of the fields shown in my example above, I would expect to see "12345" as the "value" property of those fields in JavaScript, such as:

    <script type="text/javascript">

    var textValue = document.getElementById('my_text_field').value;

    var passValue = document.getElementById('my_password_field').value;

    if (textValue == passValue) console.log("All values are the same");

    </script>

    You can also see this with jQuery, or by using Web Developer tools in your browser to inspect the "POST" arguments sent in your API call. In general, any POST form submission will send the value typed by the user into a "password" input field, just as it does for "text" input fields.



    I hope that helps!
  • Thanks Stephen for the clarification !



    As for the additional verification questions you have



    You might verify a few things to confirm this issue:

    1) Does the recurring_gift_id you are sending in the "updateRecurringCreditCardInfo" call match a recurring_gift_id returned by a "getRecurringGifts" call? Yes, they are. We were mimicking the out-of-the-box functionality that is currently on that default Service Center within "site/UserCenter" that basically list the all the gifts through "getRecurringGifts" API and were giving option to update their credit cards when applicable (if that particular gift transaction was done through CC), thus the id was passed from the previous API on that gift detail ("getRecurringGiftDetails" API) -- We'll have to revise ours then to only give option to update CC when the gift is active/ongoing.



    p.s.May I know what is the value of the returned "status" for these ongoing/active gifts?




    2) Are you submitting the "updateRecurringCreditCardInfo" with an authentication token identifying the logged-in user that made the original donation, or with valid API administrator credentials (for Server API calls) and passing the cons_id of the user that made the original donation?

    I am currently using LuminateExtend library thus defining the auth through it (requiresAuth: true) and checking whether one is logged in or not instead of the API administrator credentials.



    thanks again Stephen!



    regards,

    Daniel

Categories