Announcement

Collapse
No announcement yet.

Support ticket never resolved: Transactions preauthorizing instead of charging

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Support ticket never resolved: Transactions preauthorizing instead of charging

    Hi,

    My organizations has contacted customer support many, many times over the past month -- both by phone and email -- and our ticket has yet to be addressed.

    It has now become a serious issue for us -- so much so that we might need to change vendors.

    Many of the one-time credit card transactions our contacts attempt to make are pre-authorized for a date one month in the future, rather than being processed TODAY. Over the past month, we've had to call/email each of our contacts so they could make alternate payment arrangements since our payment portal did not work. This has not been a consistent issue and we've been unable to identify the root of the problem.

    This has been a serious service issue for our donors, which was made worse with the end of the tax year. On December 31, a number of our donors -- including Board Members -- attempted to make end-of-year donations that would be deductible in tax year 2013. Unfortunately, the system again preauthorized those transactions for payments that would be made on January 31, 2014 rather than actually charging the cards on that December 31.

    We have made multiple attempts to resolve this with CnP support but have been largely ignored.

    At this point, any assistance -- both on the technical issue and the CnP customer support issue -- would be greatly appreciated.

    Best,
    Radha

  • #2
    Good day!

    You had submitted this ticket twice and I deleted one of them.

    I researched this and our support department is aware of your ticket. Our PaaS team is trying to figure out what is going on with your instance. This feature works correctly at our instance and what you are describing is not consistent.

    The future transaction is expected to work as follows:

    - The Transaction date is when the first transaction should occur.
    - The date when the transaction is set will result in a $0 transaction to be authorized for receiving the authorization code by the gateway.

    Based on our tests it works as expected and others are using this all the time. I am told that we have access to your account and that you are still on version 7.
    Regards,
    Click & Pledge Support Department

    On Salesforce? Help us by rating our app: Click & Pledge Donor Management on AppExchange

    Join us @ the educational webinars: https://clickandpledge.com/webinars/
    Live Support available Join between 3:00 - 3:30 p.m. ET Monday - Thursday: https://clickandpledge.com/webinars/
    Are you on Salesforce? Join us at the Power of Us Hub: https://powerofus.force.com/0F980000000CjpC

    Comment


    • #3
      I appreciate that the support department is aware of the issue. However, they have not been responsive, nor have they been proactive in contacting us about this issue. Moreover, the issue is related to basic CnP functionality -- the ability to accurately charge credit cards -- and our basic business needs. Many of our follow up emails have not received responses.

      I can vouch that CnP is clearly not working as expected in our organization. And we have lost revenue, as well as donor trust.

      We do not feel CnP is responding with appropriate speed or concern to our case. Even after my post, I have not been contacted by support with any suggestions or resolutions. The problem continues to occur and we continue to loose revenue.

      Best,
      Radha

      Comment


      • #4
        Dear Radha,

        I am sorry that you think we are not working on your issue. I would like to explain the chain of events that has taken place since your post and I leave the judgement to you since you are absolutely sure nothing has happened and I find no reason to argue.

        Steps taken since your post and your support ticket:
        1. The test team has tested the virtual terminal since it was assumed that you are referring to the Salesforce virtual terminal. After logging into your account and validating the setup we came to the conclusion that the virtual terminal is working as designed.
        2. We researched all your transactions and requested the XML's that are being posted from your account as well as the receipts that were sent. Once the database team retrieved the XML's we concluded that, once again, the system is working as expected.
        3. In reviewing the XML's we realized that you are not referring to the Virtual Terminal in Salesforce but the results are based on a FaaS form. If this post had been posted to the FaaS forum we would have started our search elsewhere. Here is what the XML heading shows:

          <Application>
          <ID>CnP_FaaS</ID>
          <Name>CnP_FaaS</Name>
          <Version>FaaS.20131015.001.035.001.001.035</Version>
          </Application>

          Based on above the FaaS form is being used.
        4. The following shows results from transaction #: 1312310018576532011


        <Transaction>
        <TransactionType>Payment</TransactionType>
        <CurrentTotals>
        <TotalDiscount>0</TotalDiscount>
        <TotalTax>0</TotalTax>
        <TotalDeductible>20000</TotalDeductible>
        <Total>20000</Total>
        </CurrentTotals>
        <ChargeDate>14/01/30</ChargeDate>
        </Transaction>

        Based on the above XML post the payment is scheduled for processing on January 30, 2014. The transaction date was 12/31/2013

        There is a feature in the FaaS API for setting a transaction to process at a future date (http://manual.clickandpledge.com/For...tml#ChargeDate) . Once the node is set the first transaction is done for $0 and a pre-authorization is done for use in the future. The transaction is set as a recurring transaction with the installment set as subscription and period of 1.

        In reviewing your form: https://transgenderlawcenter.secure.force.com/donate

        TLC Future Date Transaction

        Line 935

        <select id="ChargeDateDay" name="ChargeDateDay">
        <option value="1">on the 1st</option>
        <option value="15">on the 15th </option>
        </select>

        It appears that you have a feature set for the donor to choose when the charge needs to take place. One of our developers reviewed your form and noticed the following:

        var tdy = new Date().getDate();

        var tm = new Date().getMonth() +1;

        We are not sure of your logic but whatever is being done you are invoking the ChargeDate node with a date set to a month in the future. To re-iterate this process as explained in the first post to your question:

        The ChargeDate, as the name implies, is the date when the FIRST charge will take place. The following steps are taken when ChargeDate node is invoked:
        1. The credit card will be pre-authorized for $0 and the authorization code will be saved for use in the future
        2. In Salesforce no opportunities are created since the charge has not yet taken place.
        3. On the date set by the ChargeDate the transaction will run for the full amount
        4. If the transaction is set for recurring, all future recurrings will run on the set period following the first transaction.

        Since your post a member of the testing team, the developer for the virtual terminal, the team for the API platform have all worked on your ticket to determine the cause of the problem.

        Please check your code and let us know if this is a bug in your program or if you think the system is not doing what it should do.
        Regards,
        Click & Pledge Support Department

        On Salesforce? Help us by rating our app: Click & Pledge Donor Management on AppExchange

        Join us @ the educational webinars: https://clickandpledge.com/webinars/
        Live Support available Join between 3:00 - 3:30 p.m. ET Monday - Thursday: https://clickandpledge.com/webinars/
        Are you on Salesforce? Join us at the Power of Us Hub: https://powerofus.force.com/0F980000000CjpC

        Comment

        Working...
        X