Vantiv connectivity

Hi everyone,

We regularly experience double charges due to issues communicating with Vantiv.  Not so much with in-person, card swiped at box office terminal transactions, but it's more with online customers.  Is there anything we can be doing to speed up the connection, or is this 'Vantiv being Vantiv?'  It is causing our Finance team major headaches with reconciliation.  I know there have been a few conversations floating around about this, but I've not seen any actual resolutions... we're now on v15/TNEW 7, but was happening prior to the upgrades as well.

Thanks,
Kathleen 

Parents
  • Hello Kathleen and all,

    As you have likely found, the process of authorizing a credit card is complicated; there are many entities touching a single transaction as it is passed along from your website or the Tessitura application to the card holder’s bank and back. There are many points at which communication can break down. The Support Team is always happy to help investigate double-payment issues, and Kathleen, I have opened a ticket for you so we can start to look at the specific instances in your environment.

    With that being said, there are several common patterns we see around double payments:

    1. The authorization is initiated and then communication between Tessitura and the payment processor or the payment processor and the bank is disrupted. In some cases the authorization is disrupted, but in some cases the payment is authorized at the bank but the authorization does not make it back to Tessitura. To help resolve some of these instances Tessitura tries to reverse any authorization that returns a communication error three times.
    2. The payment is authorized, but is not saved before the Tessitura application closes ungracefully. We see this when connecting to Tessitura through Citrix when the Citrix session time out closes Tessitura before the Tessitura application timeout closes Tessitura. We recommend saving an order or contribution with an authorized payment before walking away from the application. In addition, we recommend setting the application timeout to 15 minutes (900 seconds in T_DEFAULTS) so that Tessitura can close and cancel any unsaved payments properly. We also see the application close ungracefully sometimes due to defects causing the application to crash. We work to resolve these defects as they are identified, and encourage you to report to Support when you see the application crash before a payment can be saved.

    3. With hosted payments online, both in TNEW and custom integrated websites, we see payments recorded with the processor that do not make it into Tessitura for a variety of reasons, from users clicking away too soon to communication breakdowns between the payments window and the website. In TNEW we have added a variety of checks and safety procedures in the coding around the payment window to prevent as many stranded payments as we can. When stranded hosted payments occur reach to Support or your web developer for custom integrated websites.

     

    In all cases, we recommend reconciling your batches in the bank regularly, so that these issues can be identified and corrected quickly. When you find payments recorded in the bank and not in Tessitura contact Support and we can help to identify the underlying issues.

     

    Thanks,

    Boann Petersen

    Support Escalation Manager

Reply
  • Hello Kathleen and all,

    As you have likely found, the process of authorizing a credit card is complicated; there are many entities touching a single transaction as it is passed along from your website or the Tessitura application to the card holder’s bank and back. There are many points at which communication can break down. The Support Team is always happy to help investigate double-payment issues, and Kathleen, I have opened a ticket for you so we can start to look at the specific instances in your environment.

    With that being said, there are several common patterns we see around double payments:

    1. The authorization is initiated and then communication between Tessitura and the payment processor or the payment processor and the bank is disrupted. In some cases the authorization is disrupted, but in some cases the payment is authorized at the bank but the authorization does not make it back to Tessitura. To help resolve some of these instances Tessitura tries to reverse any authorization that returns a communication error three times.
    2. The payment is authorized, but is not saved before the Tessitura application closes ungracefully. We see this when connecting to Tessitura through Citrix when the Citrix session time out closes Tessitura before the Tessitura application timeout closes Tessitura. We recommend saving an order or contribution with an authorized payment before walking away from the application. In addition, we recommend setting the application timeout to 15 minutes (900 seconds in T_DEFAULTS) so that Tessitura can close and cancel any unsaved payments properly. We also see the application close ungracefully sometimes due to defects causing the application to crash. We work to resolve these defects as they are identified, and encourage you to report to Support when you see the application crash before a payment can be saved.

    3. With hosted payments online, both in TNEW and custom integrated websites, we see payments recorded with the processor that do not make it into Tessitura for a variety of reasons, from users clicking away too soon to communication breakdowns between the payments window and the website. In TNEW we have added a variety of checks and safety procedures in the coding around the payment window to prevent as many stranded payments as we can. When stranded hosted payments occur reach to Support or your web developer for custom integrated websites.

     

    In all cases, we recommend reconciling your batches in the bank regularly, so that these issues can be identified and corrected quickly. When you find payments recorded in the bank and not in Tessitura contact Support and we can help to identify the underlying issues.

     

    Thanks,

    Boann Petersen

    Support Escalation Manager

Children
No Data