Selective storage/deletion of tokenized credit cards

We have been automatically storing tokenized cards and would like to continue using this feature.

Our ticket kiosks use a dummy constituent ‘Kiosk User’ as a way to offer a quick, anonymous guest checkout experience. Since this dummy account is used by many different users each day, we realized it has been storing hundreds of tokenized cards on the record, which we do not want.

The only way I can find within the client to clear out just this specific account is to delete the cards one-by-one from the record. The parameters on the Credit Card Tokenization and Deletion Utility can be set to EXCLUDE a list of constituents, but not to target specific ones.

I am looking for:

  • a way to prevent the storage of tokenized credit cards in specific situations (e.g. by constituency, MOS, etc.) or
  • an overnight procedure to clear out the cards saved to the dummy account

I’ve been in touch with TASK, and am currently looking into developing a stored procedure based on AP_PURGE_T_ACCOUNT_DATA. Before we spend a lot of time on it, I wanted to check if anyone else already has a solution.

I’ve tested simply deleting the lines from T_ACCOUNT_DATA for that specific customer_no, and haven’t found any issues yet. Could it be as simple as that, or am I missing something?

We are on 12.5.1 and use Payment Express.

Parents
  • Hello Jennifer, 

    We recently had the same problem and we had so many credit cards stored on our Kiosk Anonymous User constituent record that if you tried to open that screen, the application crashed. 

    I created a list that was all constituent ID's not equal to my Kiosk record and used that as an exclusion parameter within the CC Deletion Utility. Nearly 48K cc's were deleted (which I had validated with our DBM in advance, was the correct number of cc's being stored on that 1 record). The Deletion Utility ran quite quickly - less than 30 seconds I would say. Though it took slightly longer the first time I ran in review mode, which I assumed was due to the list being generated for the first time. 

    We did a few tests in our TEST database first, and then ran in PROD this past Monday at 5PM as the Museum was closing.

    In testing, we did discover that we could no longer perform a full cc order search for kiosk orders, but a partial cc turned up results. 

Reply
  • Hello Jennifer, 

    We recently had the same problem and we had so many credit cards stored on our Kiosk Anonymous User constituent record that if you tried to open that screen, the application crashed. 

    I created a list that was all constituent ID's not equal to my Kiosk record and used that as an exclusion parameter within the CC Deletion Utility. Nearly 48K cc's were deleted (which I had validated with our DBM in advance, was the correct number of cc's being stored on that 1 record). The Deletion Utility ran quite quickly - less than 30 seconds I would say. Though it took slightly longer the first time I ran in review mode, which I assumed was due to the list being generated for the first time. 

    We did a few tests in our TEST database first, and then ran in PROD this past Monday at 5PM as the Museum was closing.

    In testing, we did discover that we could no longer perform a full cc order search for kiosk orders, but a partial cc turned up results. 

Children