I'm getting the same thing with a client who has a merchant number and does process. They've previously been able to view/edit the entire card number. Like you say, it's masked both in Sage and in the Paya pop up window. Sage support says it's not a Sage issue.

From Paya Support, "There was an update made to mask the first 12 digits of the Card Number for Compliance reasons. Merchant do not need to view customer full card number once those numbers are stored. Merchant will have access to the last 4 of the card number to verify. Merchant will have the ability to update the card number if they need to however the only time they will have access to the full card number is when their storing the card number” 

Wish I saw this post sooner.  Apparently this is due to the Paya 2.0.3.20 Update.  Argh!!  I had only located this post: communityhub.sage.com/.../can-t-see-credit-card-numbers

Well, that takes away the Vault Only functionality, which was used to store payment in Sage in a PCI compliance way (tokenized not just encrypted). This will mean users will start to keep the payment info in a memo or other field in plain text and open themselves for PCI issues. BTW If anyone reading this says "well that is what we do", stop right now and fix it. Get it out of Sage as plain text. Use one of the integrated Payment options from a 3rd party to get PCI Complient. 

Cards in Vault Only will never be processed through Paya or even in Sage, it is only a vault. Saying the Merchant does not need to view customer full card number isn't correct if the merchant is using the vault only function to store the CC to be used to enter in a terminal or other payment system not integrated with Sage 100. This is means that the vault only setting is only to keep a tokenized payment when copying a company so that the payment is stored and if it is setup to use a Merchant account that it can without losing the payment info from the source company.

This could be a very big surprise to customers using the functionality to securely store cards yet processing the card information externally.

The client says their main reason for wanting to see the entire card number is because sometimes the information is unknowingly entered incorrectly into the system, causing the credit card to be declined.  So they contact the customer and first confirm the card # is correct.  However, I explained that I don’t see how that’s possible because it won't even let you enter an invalid cc (at least based on the algorithm), but she claims that has in fact been the case.  So we agreed to wait and see if it happens again and if it is in fact a bad card # issue.  And she'll remind the other users NOT to install the Paya Update so that the full cc #’s can still be viewed elsewhere.

Exactly, while a lot of customers are on a 3rd party processor, not all of them are. They didn't have to be as they had a function in Sage 100 to store them tokenized and use them as needed with the processor of choice. This will be a big surprise for them. 

In this case I would expect a valid last 4 to be OK to confirm that the card was entered correctly. They would verify the last 4 and expiration date for a valid entry. If it is ACH, you wouldn't know if it was correct or not as I don't think there is a checksum like CC. If the customer says that last 4 is correct, then they would just rekey it to make sure it is valid. Hopefully they are not reading it out to the customer to validate it as that is a security issue. If the customer is reading it to them then they may as well rekey it.

Depending on the processor, Click to Pay helps with issues like this or if the stored payments are synced to Sage 100 so the customer enters this on the web. Having the merchant not being involved with any of the entry or validation helps protect the merchant from PCI issues and needing to view the full payment info.

This is different than customers without an integration to Sage for payment processing who would need to be able to see it to still be able to process outside of Sage 100. For security, always processing with an integrated processor is the best option. This can be a big surprise to those who process outside of Sage, which is where my concern is. Not sure if this is Kevin's case or if he was just letting us know of the change or what.  

Our client was using the vault data to use an external processor.  This unilateral change by Paya, without warning, has broken a previous critical feature.

Does Sage have a plan to replace or restore this functionality?  (Please do not say it is a Paya decision... this is how CC's are stored securely in Sage 100 without any contract with Paya).

According to our understanding, Paya released an update to the Paya connect, version 2.0.3.18 back on the 15th of December that started masking credit card numbers. However, after we reached back out to them they let us know that they rolled-back those changes, and that version 2.0.3.20 should have the numbers again un-masked. zip it sounds like your customer is on 2.0.3.20 and the number is still masked, is that correct?