Pledge Billing & Credit Card Expiration dates - Windcave

Hi Michele,

So you are aware, we are experiencing similar issues on 15.1.1 and Windcave. I actually documented a very specific example and have an open ticket on it. It's not with the pledge billing utility, although I wouldn't be surprised if we have run into it there as well.

Here is what happened in our case:

1. Patron successfully places an order on our website (i.e. processed via Tessitura/Windcave).

2. Patron attempts another order on our website, but types in an incorrect expiration date (for example, 0922 instead of 0923). The card is declined.

3. Patron attempts processing the order again on our website multiple times and types 0923 as the expiration, but Windcave shows that 0922 was used as the expiration. Card is declined.

4. Staff member is processing a phone order and uses this same card as stored in Tessitura - card is declined.

5. Staff member gets the card number from the patron and enters it in the payment window with the correct expiration of 0923 - i.e. the same card as what we had stored. This is also declined.

6. Staff member deletes the stored card from the customer's record, then attempts #5 again with the exact same card number. This time it works.

In all cases above, the same token was used - even with #6 when the card was deleted from Tessitura and reentered. Also, for #3-6, the T_PAYMENT_GATEWAY_ACTIVITY table shows that 0923 was the expiration; however, Windcave indicated that 0922 is what was used to attempt the transaction.

I'm not 100% sure where the problem is; however, the fact that deleting the card from Tessitura resolves the issue and that it is the same token after we reenter the card in Tessitura suggests to me that perhaps Tessitura updated the stored card in T_ACCOUNT_DATA with the incorrect expiration when the failure occurred and is sending the expiration from T_ACCOUNT_DATA rather than what is specified at the time of entry. If they are only updating T_ACCOUNT_DATA after a successful charge, it results in never being able to use the card until it is deleted (which is what we experienced). 

Anyway, I'm going to see if I can look at a database backup before the card was deleted to see if the wrong expiration date is in fact in T_ACCOUNT_DATA. 

Thanks,

David

Hi David - This is pretty much word for word what we've been experiencing. I just received a response from Tess on the 21st that says this:

I think you are running into an issue that is the result of a known defect that has been fixed, but that caused data to be mismatched for a time. The short version is that tokens are stored with Windcave with an expiration date, and if we send a token along for a transaction authorization Windcave only cares about the token and does not look at the expiration date that is passed along from Tessitura. It is expected that when the expiration date is updated in Tessitura a call is made to update the expiration date with Windcave, however there was a defect (in v14) where this important step was not happening (it is fixed in v15). This caused Tessitura to to have the accurate expiration date and Windcave to have the inaccurate expiration date. Since Tessitura is not seeing the expiration date change it is not telling Windcave to update the expiration date, and Windcave is using the expiration date they have stored.
 
The good news is that development has recognized that this mismatched data is causing a lot of problems for some organizations and they are working to update the Tessitura functionality so that with each and every transaction Tessitura is starting with the Update Expiration Date call first, and then authorizing the card. This means that as your saved cards are used they will be updated in Windcave so all your expiration dates get back in line.
 
I don't have an exact ETA on when this will be available, but hopefully in the next service pack or two (the developers are working on it, but until it is marked as complete the timing is still subject to change).
 
Until the fix is available and in place your best bet is to delete the token when this error is returned and add it back in.

Hi David - This is pretty much word for word what we've been experiencing. I just received a response from Tess on the 21st that says this:

I think you are running into an issue that is the result of a known defect that has been fixed, but that caused data to be mismatched for a time. The short version is that tokens are stored with Windcave with an expiration date, and if we send a token along for a transaction authorization Windcave only cares about the token and does not look at the expiration date that is passed along from Tessitura. It is expected that when the expiration date is updated in Tessitura a call is made to update the expiration date with Windcave, however there was a defect (in v14) where this important step was not happening (it is fixed in v15). This caused Tessitura to to have the accurate expiration date and Windcave to have the inaccurate expiration date. Since Tessitura is not seeing the expiration date change it is not telling Windcave to update the expiration date, and Windcave is using the expiration date they have stored.
 
The good news is that development has recognized that this mismatched data is causing a lot of problems for some organizations and they are working to update the Tessitura functionality so that with each and every transaction Tessitura is starting with the Update Expiration Date call first, and then authorizing the card. This means that as your saved cards are used they will be updated in Windcave so all your expiration dates get back in line.
 
I don't have an exact ETA on when this will be available, but hopefully in the next service pack or two (the developers are working on it, but until it is marked as complete the timing is still subject to change).
 
Until the fix is available and in place your best bet is to delete the token when this error is returned and add it back in.

Thanks for sharing what you learned about this, Michele! It's good to hear there is an update coming that will fix this.