Duplicate charges in Vantiv?

We are in your exact situation: we were told that lags in RAMP were triggering this, and that we would need to upgrade. We are also now in a very busy season, so it feels like a pretty bad spot to us too. 

We scheduled the "incomplete credit card transactions" report to run nightly. If these errors happen, they will show up on that report.( I don't fully understand why- as you say, these transactions don't seem to have a record in Tessitura at all, so it is confusing to me that they show up on a Tessitura report.)  Hopefully having something to reconcile against will help your finance team feel like they've got their arms around the problem until you can transition to the new version. 

Shannon

Hey RJ,

This is a known issue affecting many users on all versions, both Vantiv and Payment Express, both self-hosted and RAMP, and both custom web and TNEW. We started noticing this back in December as well. We are on V15 and TNEW and RAMP.

- Chris

Soooo... an upgrade would NOT fix the problem?  Ouch.  I'll let folk know and I'll re-download the known issues worksheet.  Thanks for this.

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

We are also experiencing this.  Often multiple charges, sometimes it doesn't show up in Tessitura at all. The only way we found out that there was an issue was because the patron had not received a confirmation of their purchase.  The problem we are running into with this happening is that the customer is initiating chargebacks or refunds through their bank, and it's hard to figure out if we should refund the extra charges if we don't know that they've already initiated it on their end.  Also, the patrons are not very happy about the duplicate charges.  I did try to run the incomplete credit card transactions report mentioned in this thread and our most recent occurrence of this does appear, so I guess running this on a daily basis will help us to initiate the refunds before the customer has a chance to report them to their bank/credit card company.  Oh... and this only began occurring once we did the most recent upgrade.  We had never had this problem in the past.  We are now switching payment processors, but I suspect that it won't change anything because as was mentioned, I think it's some kind of issue in the communication between Tessitura and the (any) processor, not that the processor is itself messing the charges up.