• Replies 5 replies
  • Subscribers 218 subscribers
  • Views 131 views
  • Users 0 members are here
Related

Duplicate charges in Vantiv?

Richard Jackson (Past Member)
$organization

Hello –

We have a problem where we seem to be duplicate charging online customer’s credit cards for a transaction only to have to refund the addtional transaction via Vantiv after we’re sure it’s not intentional several days later.  Example: Customer buys $300 worth of tickets online on 12/3.  Their card is charged $600.  $300 is credited back to them on 12/19 by one of our finance staff via Vantiv. 

We put in a support ticket back in September and after a lot of log trading and troubleshooting we ended up with zero progress.  Our website (L2) couldn’t find anything causing it on their end, we couldn’t find anything causing it on our end and Vantiv couldn’t find a cause on their end.  In the final act, we were told by Tessitura support to simply upgrade to the next version of Tessitura (at that time, 14.1.8)

Due to the Xmas demand to “not stop the money train” we put off the upgrade and when we were finally ready, Tessitura was onto v14.1.11 which we had not tested so… we put off the upgrade again.  Well, now we’re in subscriptions renewals and the same issue has cropped up.  Our finance staff is keeping written logs of each transaction we have to refund or wait to clear out (i.e. charges in Vantiv with no backing transaction in Tessitura). 

My question isn’t about a fix (we’ve been told to upgrade – we just need to find a time to do it) but about whether or not we are the only site experiencing this?  Is anyone else getting mysterious random duplicate charges in Vantiv?

Any input is appreciated to help ease the conscious of our finance department.  Thanks!

RJ

Parents
  • $organization

    Hi Richard and all,

     

    It is probably a bit of an understatement to say that the process of authorizing a credit card is complicated. A single transaction is passed along from your website or the Tessitura application to the Tessitura Payment Gateway, to your payment processor (Vantiv), then to your merchant processor, and finally to the card holder’s bank. As such, there are many points at which communication can break down. The Support Team is always happy to help investigate double-payment issues, and Richard, I have opened a ticket for you so we can start to look at your specific double-payments.

    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
  • $organization

    Hi Richard and all,

     

    It is probably a bit of an understatement to say that the process of authorizing a credit card is complicated. A single transaction is passed along from your website or the Tessitura application to the Tessitura Payment Gateway, to your payment processor (Vantiv), then to your merchant processor, and finally to the card holder’s bank. As such, there are many points at which communication can break down. The Support Team is always happy to help investigate double-payment issues, and Richard, I have opened a ticket for you so we can start to look at your specific double-payments.

    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