Unique Business Challenges and General Discussion

[clearis]

Removing the capability of properly storing credit card information in MAS is not a step forward, but a reduction in software functionality. Some may even ask, where is the value to upgrading to the next version if I loose this?

Everyone is incurring the cost of protecting credit card information - users of MAS 90/200 included. They've had to make their networks and servers PCI compliant, hire external consultants to review their data systems and have credit card information less available to their staff.

[SRYork]

Please know that the credit card gods came down with this requirement.  We are only following their commandments. With identify theft being a huge issue today, the credit card companies needed to do something to try and tighten security, especially given the increase in risk as more people shop on the internet.

This is really no different than the SEC requiring financial audits in order for a company to publicly sell their stock on an exchange.

When the requirement first came out I heard worse case, the risk of non-compliance is a business found to utilize software to process credit card transactions not certified by the PCI council could loose their ability to accept credit cards in their business at all.

At a minimum, I would expect the risk of non-compliance is a business found to utilize software to process credit card transactions not certified by the PCI council would incur significant up charges in setup and transaction fees.

I would expect over time the credit card processors will implement some sort of auditing of their accounts, most probably as contract terms expire.  But this is just a guess.  All it will take is a major hack into some database where thousands of credit cards or other personal or secret information is stolen.

So, you may not like the consequences of the standards, but it really becomes a necessity of doing business just like paying taxes.

[rmikolainis]

---

clearis wrote:

Removing the capability of properly storing credit card information in MAS is not a step forward, but a reduction in software functionality. Some may even ask, where is the value to upgrading to the next version if I loose this?

Everyone is incurring the cost of protecting credit card information - users of MAS 90/200 included. They've had to make their networks and servers PCI compliant, hire external consultants to review their data systems and have credit card information less available to their staff.

---

Perhaps you should send a letter to the governing bodies in charge of PCI compliance? This wasn't SAGE's decision.

[givingtr]

Personally, I feel it's a step forward, as long as software developers don't restrict a users choice in credit card processors. Compliance is a huge burden and frankly, most end users don't bother making the investment. I think we'll ultimately see developers working around this problem by creating links to their on-premise databases or hosted solutions.

[jrstew]

I have 2 concerns regarding storage of credit card information in the Sage Exchange Vault:

     1.  We do monthly repetitive invoicing for customers who subscribe for our data

          services products.  Will the billing program (done in SO) be able to obtain

          the credit card information in order to apply payment to the invoice as it does

          under our current version, which is now at 4.4?

     2.  Can we obtain the full credit card number form the Vault storage in order to

          dispute chargebacks?  We must have that information in order to start

          the dispute process.  Currently we can access that information on a password

          protected basis.

[ebjelovs]

JRStew,

I have great news for you in this regard. As you may already know, Sage ERP MAS 90 and 200 is becoming Sage 100 ERP. With the next release of Sage 100 ERP, there will be some very significant enhancements to the credit card processing functionality built into the product.  First, Sage will be using Sage Exchange, a connected service that allows ERP products to link directly to a PCI-compliant, secure vault.  In the vault, card numbers are stored, but they can be edited and retrieved as necessary by authorized personnel for legitimate business reasons, like disputing chargebacks.  So this will be something you'll be able to continue to do.

 In addition, the Sage 100 ERP team is adding functionality into the Repetitive Invoice Entry area to allow integration with Sage Exchange from there. So, you'll be able to store a card number in the vault, but 'attach' it to a repetitive invoice. When you run your batch of repetitive invoices you'll be able to select the credit card charges by assigning a reference number to all credit card-associated repetitive invoices.  The batch can then flow directly into AR Invoice Data Entry (like it does today with repetitive invoices), and charge the appropriate credit cards for each transaction. 

But even more than that, Sage Exchange has much more that it will be bringing to the table.  Because Sage as a company has invested in the payments business, we have much more in store coming with Payments that we will be introducing and sharing at Sage Summit.  You won't want to miss the hands-on sessions at the conference to learn all about it.

[givingtr]

Having just attended a webinar on Sage Exchange, I'm hopeful that implementing credit card processing in version 5 will enhance security and be less taxing for customers. As Erika stated, additional features will also enable users to reap benefits. Unfortunately, I've also learned that if customers are not approved by SPS or if they simply want to use another service, they will be unable to integrate credit card processing with Sage 100.

Previous comments in this thread discussed the fact that MAS 90 will no longer store credit card information. My concern is not where cards are stored, it's about having access to resources and alternatives. While I applaud Sage for implementing a solution that forces PCI compliance, the inability of Sage 100 to use other integrated credit card solutions is a step backward... but also creates an opportunity for developers.

When selling Sage 100, will I now have to disclose to prospects that they may not be able to implement integrated credit card processing, even if they agree to use SPS? If their application is denied, will they have to double enter all credit card payments because no other options exist? Is this an acceptable risk for ERP prospects? Am I missing something here?

[jrstew]

As I understand from previous inquiries, we can stay on our 4.4 or 4.5 for the time being using

PC Charge under our contract with them until we are ready to make the move to SPS and version 5. 

Would the posting below yours apply to all versions or only to 5 and up where the exchange vault is used?

[givingtr]

My understanding is that it will only apply to version 5. The good news is that I've received information on options, which I'll review once version 5 becomes available. 

[cspeedy]

I'd like to clear up several points of misinformation.

Storing credit card numbers poses tremendous financial risk and there's really no need to store full card data any more due to changes in the card association requirements and companies expanding other solutions to make it easier not to store the data. 

Official Visa notice: usa.visa.com/download/merchants/PAN_truncation_best_practices.pdf (full card no longer needed for disputes) 

Official PCI Standards on storage: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf ( storing card data standards) 

Sage has apparently made a strategic decision, most assuredly driven by PA DSS & PCI Compliance requirements  to use only internal solutions vs integrating with 3rd parties for storing card data. That's at least for 2012, per their news alert, and there is no indication that users will be able to use any other credit card processor in the future. PC charge was probably dumped 

    jrstew 2.  Can we obtain the full credit card number form the Vault storage in order to

          dispute chargebacks?  We must have that information in order to start

          the dispute process. 

If you could obtain the full card number, then it would be virtually impossible to be PCI Compliant. As per the Visa link above, the full card number is no longer needed for the dispute process. 

SRYork "After we remove storing credit card data we aren't required to be.  The PCI council standards are not applicable to us. "

All merchants must be PCI Compliant, as has been the case for nearly a decade. Even if you had a dial up terminal you still have obligations. A 'breach' is not just something that happens on a computer. 

What does the future hold? Some companies are closing the doors-they want total ownership of the software and payment processing. Others are going the opposite direction and adding solutions  that are easily connected to, to open the door to everyone. Which direction Sage goes may ultimately be determined by client attrition in the next year as users decide what's more important- a flexible processor option or MAS 90.