Sage 100

Fair warning regarding testing SPS. Client is migrating to Sage 100 2014 and moving off EBM to it's own shopping cart using Web Services and/or SData to connect. We are creating a completely separate test environment. We installed Sage 100 2014 Advanced on a new server and migrated the data. We created company TST from the production company. In TST Payment Type Maintenance, we changed the SPS Merchant account to our SPS Test account. The message ""Transferring credit card data to the new account"" appeared. ""Transfer"" to me means ""move"". Emergency call to Sage and SPS Virtual Terminal support confirmed the message meant ""copy"", i.e. the process copied saved credit cards only from one account to another. No transaction data was copied. Sage support tech agreed verbiage was misleading.

Wasn't there an earlier post about something similar just last week (or maybe the week before)???

Yes, on 8/12 (below). However, our experience was that nothing was ""moved"" in the vault and no SPS fix was needed. by David Overholt @MoiraGoggin - not entirely without warning - the warning that comes up indicates that you will no longer be able to process cards in this company code. (I don't have the exact message handy this morning). Reading that message does not exactly explain that the GUIDs for the credit cards are going to be moved from the vault. Hind Sight is 20/20 of course and after thinking it through, it makes perfect sense that this is what would happen. The newly copied install is pointing to the same cloud vault that you live installation is using. As soon as I hit the OK button on that message, the next message was ""transferring credit cards from vault"" which was a little better description of what was happening. but it was a little late at that point. Sage Payment Solutions can correct the vault but it was not a quick fix.

interesting. in our case things were moved. As soon as the ""transfer"" began in the non-production environment the client started getting errors when processing credit cards (in the live environment). in our case the difference may have been that we turned off credit card processing in company maintenance instead of changing things in payment type maintenance.

after re-reading Bob's post I think the difference is that he performed a copy company which created a new vault for the company TST. Then changed the settings in TST. We were in the test environment but turned off credit card processing in the same company code as our live data which was linked to our live vault.. I still recommend proceeding with great caution in any test environment with Credit cards. I think the steps that @BobPfahnl performed sound like a good method.

That sounds reasonable. We did not turn off cc processing. On the other hand, it is disturbing that the messaging is so mis-leading and that unchecking a box in ERP could have such a profound impact on their SPS account.

I will add, The root of this issue comes from version 5.0 after making a copy company. I worked extensively with SPS Support and eventually got the Tools team & SPS support guys to collaborate on the issue. (Thank you. Now add it to the KB). Upgrade 405 to 5.0 in May 2013. Trying to process a credit card transaction after making a copy of the production company would return an error message ""Unable to Communicate with Sage Exchange"". The exchange was fine. The system just couldn't find the new vault ID assigned to the production company. The copy company did not have CC processing enabled but did show the Vault ID - copied over. This resulted in a new vault ID being provided to the production company, the one copied from. It's an empty vault. As it was explained to me back in June 2013 by SPS Support, the Exchange is comprised of vaults. The company may have one vault or more vaults under its assignment where CC information is being securely stored. Look at it this way. You rent a bunch of storage lockers that reside securely behind a locked door. Only way to get to those storage lockers is through this one door. The storage lockers are your vaults and the locked door to access these lockers is the vault ID assigned in company maintenance. The copy feature runs and data is copied over, but there is only one access door and the door cannot be shared. So the primary company is basically given a new door or Vault ID. However that door doesn't lead to your row of storage lockers. So your exchange data previously recorded is no longer accessible or seen. You can process in company that was copied to because that is the Vault ID that links to the row of lockers you have data stored in. AR5003 is the hot fix added to PU3 for Sage 2013.Which moves the data into a vault that the new Vault ID can access. My notes (write up) to myself on this issue is in the attached. I'm just saying , the messages returned from the errors are weak and weaker. Hope Sage resolves this soon. Many hours spend on the initial support tickets and at client's. Sorry if this is a little winded. (But where is the KB?!-Vote for Joan)

Thanks @JoanSerr that clears up a lot. Very interesting.