Double-Charge while there is only one order in Tessitura & Charge with no order in Tessitura

Hi there, 

I wonder do any other organizations experience the issues listed below during their busy ticket sales? 

Issue 1: The customer has been charged, but no order exists in Tessitura.

Issue 2: The customer charged twice while there is only one order in Tessitura. 

Please share your experience if you had similar cases, and let me know if you have figured out or given a solution by Tessitura why these problems are occurring. 

Thank you,

Mehtap

  • We are having this issue now in 2023.  One where someone only purchased 1 ticket and that is all that is in Tessitura but CC statement showed a charge for two.  And now today had a call with a person being charged who has not been here in over a year. We use Windcave

  • These issues are endemic to payment gateways generally: a payment will go through, but something in the reporting of that success back to Tessitura fails and Tessitura is left having to err on the side of caution and assume that the charge has failed.  We are hoping that the "auto-reconciliation" reports in TMS will simplify identifying these for us (and hoping that having more parts of the process under one roof will reduce the number of occurrences).  Reconciling between Windcave reports and Tessitura can be arduous, as reference numbers are not always properly shared back and forth and timestamps can often be quite different (and this can give you different figures when using the same timespan on reports from each system).

    The first thing to check is the Incomplete Credit Card Transactions Report, which attempts to look for anomalies in gateway transaction reporting in Tessitura.  In my experience it has a lot of false positives.  It also can miss problem transactions, but that is rare.

    https://www.tessituranetwork.com/Help_System_v151h/Tessitura.htm#Reports/Incomplete%20CC%20Trans.htm

    Are you saying someone had their card recently charged by your organization despite them not having done a transaction with you in over a year?  That would be something altogether different.

  • Sorry to hear about your experience. At the time (over 2 years ago) I reported this issue, our gateway was Windcave. Following Tessitura's recommendation, we switched to their payment gateway, Adyen. However, our primary issues, such as double charges and charges without corresponding orders in Tessitura, still persist.  

  • We are having this problem now as well.  We went live May 10th 2023, and are still having issues with Double and triple billing.  This is only happening through our TNEW online site for purchase tickets.  We have been working with Tessitura to get this resolved but are getting really frustrated.  

  • We have also had the first issue as well.  Those are much fewer but happen after a guest has entered all their payment information and something happens to the transaction and it ends up timing out or erroring out on the customer side.  Tessitura is still processing the payment and it gets charged on the card without a transaction created in Tessitura.  Different issue but same process.

  • We recently discovered a new type of double-charge - we have been on Tessitura Merchant Services/Adyen since April, and usually the standard reconciliation process will catch discrepancies on either side. However, after a couple of patrons contacted us, we discovered that in rare cases on our website a card was getting charged twice, but both charges were associated with a single payment_no in T_PAYMENT. To complicate further, the order and constituent record would show us a single successful payment, but the Payment Gateway Summary/Detail report run in Tessitura would show both payments. That meant our daily reconciliation between the Tessitura payment gateway report and Adyen wasn't catching the double-charge, since both payments were being reflected in the totals.

    To try to pin these anomalies down, I dug into the T_PAYMENT_GATEWAY_ACTIVITY table a bit, and tried to isolate examples of multiple payments authorized under a single payment_no. My query is below (pardon the amateur SQL, there's probably a more elegant way to do it) - basically, each payment_no should have a single authorization, so if any payment_nos rise to the top of the list with 2+ authorizations, there's a duplicate issue to resolve. Luckily we only found 5 of these since April, so it wasn't as widespread as feared.

    Our web developers (non-TNEW) took a look and they believe in rare cases a user is refreshing or not being properly redirected after their first payment is authorized, causing them to input a second payment under the same payment_no. They are adding some code so that every time the payment component data is being requested and loaded onto the page, it will void any previous authorizations and request a fresh payment_no. Hopefully that will help us solve it.

    SQL query for multiple authorizations under one payment_no:

    select payment_no, count(payment_gateway_transaction_type_id) as num_auths from T_PAYMENT_GATEWAY_ACTIVITY
    where payment_gateway_transaction_type_id = -1
    and create_dt >= **SET DESIRED START DATE HERE**
    and response_message = 'Authorised'
    group by payment_no
    order by num_auths desc

  • I totally understand and appreciate the frustration that this issue is causing and I want to let you all know that this is the primary focus in the Payments team right now.  There are three basic issues that we have identified and are working on that can cause payments to be recorded without a corresponding order, or in some cases duplicate payments for the same order.  The first is caused by the use of Guest Checkout in TNEW v16 when the customer completes a payment and then decides to continue shopping in the same session.  A patch for this issue was put on test TNEW sites last week and was deployed to production sites today.  This affects v16 only.  The second was caused by a load balancer routing issue and has been fixed in both TNEW v7 (for v15 sites) and TNEW v16.  The final known cause, the fix for which is currently in development, is not properly handling the situation when a customer uses the browser back button or refreshes the page in the middle of a payment process.

  • I completely understand your frustration. I raised these concerns over two years ago, and we continue to encounter them with Adyen. 

  • Yes, the problem of being charged without an order in Tessitura is quite common. I'm sorry to hear that you're also facing the same challenges.