Element Deletes Transactions After 120 Days – A Potential Refunding Nightmare

Gloria,

I specifically asked Element about that. It doesn't matter if you're tokenized or not, Element removes transactions after 120 days and thus Tessitura cannot refund. To break down what you posted in red;

Currently Tessitura supports the refund option which needs a transaction to match up against in the system to perform. We purge card data and reference number from our system after 120-days for compliance reasons which means a refund can no longer “match” up against anything in the system, hence the limitation.

The part in bold is the important bit. Tessitura needs transactions for the refund but Element purges it after 120 days making normal refunds after 120 days impossible.

Tessitura has an option to integrate to the credit transaction which doesn’t require a matching transaction on the other side and will just process. The merchant just has to have the card number or be using Element’s tokenization to call up the token and refund the card.

What they’re talking about here is what I mentioned below and Element refers to it as a “blind credit”. If Tessitura were to implement a function allowing us to make a “blind credit” in the system we would only need to have a saved credit card to be able to refund. However, currently Tessitura requires a transaction as well as the credit card information.

I would like to get further information from them as well to verify I’m right. I’d love to be wrong about it but I’m pretty sure I’m not. 

Oh, and as they said in their response to you ... tokenized credit cards are also only stored for 120 days. Meaning you can't pull up a saved credit card after that period either unless you've saved it in Tessitura and you're *not* tokenized.

That means even if Tessitura implements the fix to this issue, you wouldn't be able to refund at the "blind credit" level after 120 days if you're tokenized because the credit card would no longer be in their system. 

If I'm understanding this issue properly, tokenization would potentially make this problem worse if you needed to refund after 120 days. 

Cliff,

Our DBA had a conversation with an Element representative after one of the sessions where this was discussed.  The Element representative indicated that they (Element) are encouraging the Network to include the "blind credit" functionality in v12.5.1 (the first EMV version).  The Element rep. felt that if the Network did not get it into v12.5.1, they would get it into another release shortly thereafter.  

Element was clear that there was no way for us to bypass this restriction on our own and that there was no way for Element to accommodate a change to their 120 day rule.

It looks to me that the "blind credit" will be the only viable option and that it will be up to the Network to include this functionality in a release sooner rather than later. 

I too would like to hear something official from the Network concerning this issue.

Is there a plan to accommodate "blind credit" functionality from within the application in a future release?  If so, is there a release for which that functionality is targeted?

Dan

I should let Andy Kraus weigh in on this (he's the one who spoke with Element at the conference about this issue), but it seemed pretty clear to us that they simply had no concept of a business model where someone might sell something significantly in advance of it being delivered.

This also has significant customer service impacts for us.  Our season typically starts in September, but our initial onsale begins in April.  Our season ends in May (or sometimes early June).  So you could easily buy tickets to a performance that you will not attend for 14 months.  But beyond that, our typical patron makes one purchase a season.  If they were to buy tickets at the beginning of one season, and not again until towards the end of another, we're talking up to a 26 month span between purchases.  That would be fairly extreme, but the majority of our customers are going to make a purchase with us typically once every 12 months.  This means we cannot keep a card on file for the vast majority of our customers.

The next thing to consider is cards being used to pay pledges or payment plans.  Most people are going to have a quarterly payment plan system as their maximum, so that's unlikely to be a problem, but pledges are often billed at longer intervals, and in those cases the card will also be lost and the development officer will have to call up the donor and bug them for their card information again.

Tanya, 

Unfortunately I believe your information is incorrect though I wish it wasn't. At first I thought the same as you and though it seemed like an annoying way for Element to make money, it wasn't a big deal. We could just keep ongoing donor information and simply remove tokens after a performance is over. We could make that work.

However, I found that with or without tokens, Element only keeps transactions and credit card information for 120 days. That information is straight from Element.

Cross posting this here from another thread:

It seems as if some clarification is needed here and I hope this helps. 

Tessitura has always had the ability to store credit cards and we are PA-DSS certified to continue to do that.  Nothing in any new version of Tessitura has changed this ability.  It has also always been the case that some sites have preferred not to store card data and we have the ability to configure the software to do that as well.

New functionality in v12.1 and v12.5 provides additional new options available for card handling.  Following is a summary of the options currently available.

1. You can continue to store credit cards as you have done in the past, using them for refunds and automated billing when necessary.
2. You can decide not to store any credit card data on your system at all.
3. You can decide not to store actual card data and instead decide to tokenize the cards that you use for automated billing.  This allows you to continue to do automated billing without storing card data.   There is a token storage fee for Element users.  Tokenization is not currently an option for TNS users in the UK and Ireland.
4. Cards that are tokenized in Tessitura can be used for all of the same purposes that regularly stored cards are.  That means that you can select a tokenized card from the list of stored credit cards and refund directly to it.
   
5. Regardless of whether you store any credit card data in Tessitura, Element users in North American can also refund credit card transactions back to the original card by using the Refund by Transaction number feature.  Element’s retention policy for this feature is to store the transaction reference and card data for 120 days.  Payment Express users also have this ability for most transaction types.
6. If you elect to neither store the card information or tokenize, then you have increased security but have left yourself in a position of not having access to card information after 120 days, in which case you would have to contact the customer if a refund were necessary.

I want to make it clear that we have not taken away any existing functionality for credit card handling—just provided some new options.  These new options do have some limitations because each of them are designed to provide greater levels of security.

V12 also introduced support for encrypted card readers—this option was also designed to provide additional security and ease of PCI compliance by keeping credit card data off of your network.  However, these new types of secured readers are not required—you can continue to use your existing card swipes.  Doing so does mean that unencrypted card data is transmitted on your network as it has always been.

It is possible that future security regulations may force us to restrict the options available in Tessitura for card storage and handling.  But at the moment, we are providing only additional capability to provide you with more options.  Data security, and in particular payment data security, is something that we take very seriously and so we are always studying and participating in best practices in this area.

Hope this information helps explain things.

And just to be clear, Tessitura has always had, and continues to have, the ability to do "blind credits".  That is what you are doing when you issue a refund from the payment window after swiping or keying in a card number.

And just to be clear, Tessitura has always had, and continues to have, the ability to do "blind credits".  That is what you are doing when you issue a refund from the payment window after swiping or keying in a card number.