Sage 100

Credit Card Swipe - is that released yet? I have a customer that wants to upgrade to 5.00 so they can use the credit card swipe. But I don't recall if that is released yet. Anyone out there have experience with the stock Sage Credit Card Swipe?

I have two people swiping with 2013. Seems to be working OK for them.

Good question. I thought it was working as there is a field for it in v2013. I have a client that has been swiping CC's for almost five years and being charged the keyed rate. They have been on v2013 since August and haven't seen their monthly charges decrease at all. I was talking with them today and they say the field is checked when they swipe the card. Do we have to purchase and ""official"" card reader from Sage??

Whoa, GOOD NEWS? Where did they purchase the card swipers? Any recommendations?

that is exactly why our customer is interested - the reduced rate. If the rate doesn't go down with SPS for swiped cards, then something doesn't add up.

After an exhaustive search four years ago, a reseller on the east coast sent information on ID Innovations. Their swipe reader works very well with Sage 100 (comes with a small program to parse the data into the appropriate fields. I would give a shout out to Sage but the worthless comes immediately to mind. www.idinnovations.com Jeff@idinnovations.com I just don't know how they check box works in Sage or how it knows the card has been swiped. Now that year end is nearly over, I can start working with the client to get to the bottom of the fee mystery. Plus it is time to contact SPS to discuss the fee creep that hits the client every year.

Ahhh, I thought it was just a couple of my clients that experienced fee creep. We could call it FCD (fee creep disorder). Is that covered under obamacare?

oh don't get me started LOL. Seriously though, these recurring charge models are what constantly creep. Sage maintenance on average has probably doubled or tripled from what it was even 10 years ago.

I think every does. Prior to SPS, client paid about $300 per month to B of A for credit card services. Used a small swipe/printer device. Switch to SPS and MAS for the convenience and they are now paying in excess of $1K per month. I have been promising less fees in v2013 but so far I have egg all over my face....

Both of my clients got their swipers from SPS.

Recently? Back in the day when I was looking, SPS was a deer in the headlights. My rep (I think) gave me the name of the east coast reseller who gave me the name of the company in TX. I just remember thinking that it was incredible that NO ONE at Sage was able to help locate the swipe readers. Any idea how much the swipe readers from SPS cost? Can you break out the annual M & S fee also or should we just assume 25% of SLP per reader per year. Recurring revenues, right?? I am betting that we will have to purchase the SPS readers with software. Otherwise, how else will Sage Exchange know that the card was actually swiped and not just keyed? @BethBowers - are your two clients ACTUALLY receiving the swiped rate now or are the swipe readers ""just"" working? My client's non SPS readers are working (for the past four years), they just aren't getting the swiped rate..........

ebiz charge from Century Business Solutions has much lower rates than SPS ... customers that we have switched from SPS are MUCH happier with the rates. http://centurybizsolutions.net/

Is Century still authorized with Sage? I'd thought they were not and were able to offer 2013 but possibly not later versions?

Echoing Wayne's question, are your clients on v2013?

I don't know what you mean by authorized by Sage, but Century is partners with Blytheco and SWK. We have many customers on 2013 and ebiz charge.

As a development partner with access to source code

I don't know if they need to be as I don't know if their code lies inside MAS or not .. regardless, their solution works.

Interesting. @JaneScanlan Is this available on your web site?

Yes we have information on this on our website @JeffSchwenk. Just enter ebiz charge in the search field.

American Payment Solutions also claims to be compatible with Sage 100 v4.4 through 2013. They seem to be for real, although I haven't done anything more than talk. Bryan Deeney, 888-685-1900x414, bdeeny@apsmerchants.com.

On a related note, one of our clients has been declined by SPS because they are on their Prohibited Industry list (tobacco products MOTO/internet). I've been pinging my SPS rep periodically for a solution because as we all know, Sage has been mum on the question of merchant processor choice. I learned late yesterday that SPS has a new feature called Virtual Network Switch that uses the SPS gateway but diverts to 6 other carriers. Simply put, it's much like diverting to AMEX and DISCOVER. There is an hourly setup fee and a $60/mo fee billed directly to the customer. I'll post the write-up when I receive it today.

The blytheco link that @JaneScanlan referenced http://www.blytheco.com/ebizcharge/

So the SPS guy who first said I could publicize the afore-mentioned solution now says I should keep it to myself since it is new and provided on an ""exception"" basis. In other words, if the client is declined for SPS, there may still be an option. So for now, if your client finds themselves in this position, contact your SPS rep and use the double-secret code ""3rd Party/Virtual Network Switch"" and tell them Edward Snowden tipped you.

Rare un-retouched image of a Sage Payments representative when you mention ""3rd Party/Virtual Network

Asking Sage on this. Standby.

You may not want to - they may kill it.

I'm asking about the two ISV's not the side program

I've heard different stories from different people and Sage have tap danced around it. They probably won't answer.

The side program is probably just being kept ready for an actual lawsuit to arise...

I'm moving forward with getting our client enrolled. Will report back.

I received no reply from Sage via email so I am asking in their official channel management program -- which seems to be a public post to LinkedIn. This is apparently a hot area so they'll probably ignore me there too. I suspect that Phil is on the right track and Sage is concerned about a lawsuit.

Feedback from SPS regarding swipe readers and v2013 Cosgrove, Justin <Justin.Cosgrove@sage.com> To enable the swipe button for Sage 100 you will need to enable the Magensa Card swipe in the Sage Exchange Desktop. This is done by right clicking the Sage Exchange Desktop icon on the system tray and selecting settings. On the setting screen you will check the box for Magensa Card Swipe and if they want automatically start card swipe. Afterwards they will click OK, Sage Exchange will restart and they will be able to swipe cards. Unfortunately, it wasn't quite this easy. I reached out to my swipe reader contact Jeff Zimmerman (www.idinnovations.com Jeff@idinnovations.com) for additional assistance. He had me download software to update the 4 year old swipe reader and I selected the Universal reader. The swipe is now populating the CC field. Now I just have to get verification from SPS that the information is being processed under the swiped rate. On a related note, does anyone know who to get the swiped check box field to default to ""on"". I cannot locate the field in SO invoice header under advanced options.

The latest word from Sage on this whole credit card integration. I still see this as a very slippery slope for Sage given Doug's explanation. If they have the technology to enable CC integration to non-SPS sources doesn't this put Sage in the position now of not only providing access for those who don't qualify for SPS but perhaps also for those who can get a better rate elsewhere?

Hmm - this is interesting. I wonder if this means that as PU come out for Sage 4.5 and earlier that since the CC info is stored in Sage and Sage no longer undergoes PCI audit - that there's some risk the customer assumes? "" We strongly recommend upgrading all customers on v4.5 or earlier since credit cards are stored in the ERP and there is a heightened risk of issues. All customers on versions earlier to v.5 could be subject to PCI/PA-DSS audits if they are using solutions that continue to keep the credit card numbers in non-secure methods

Anyone who takes credit cards ""could be subject to PCI/PA-DSS audits"", so that statement is just self-serving FUD. I wish these greedy bastards could at least be honest, and stop insulting us with their bullshit: ""Look, Sage bought a credit card processing company. Credit card processing is way more profitable than ERP software. We are going to lock as many people as possible onto SPS, and if we lose a few ERP customers along the way we'll just write that off as a marketing cost for SPS."" For our customers, we need to find out what the automatic decline triggers are for an SPS application and let them know what they might want to put on their application in order to become an ""exception"". And no, I don't find any contradiction in encouraging lying in order to force Sage to behave ethically:-)

We were told by our SPS rep that Magtek Centurion was the swipe to buy from them for approx $100. Client found and ordered online for $59. Then SPS said it needs to be encrypted for use with 2013. What does that mean?

The SPS swipe and Sage mobile swipes are different. The swift plugs into the audio jack and makes sounds picked up by the application. The communication between the swipe and application must be encrypted for PCI compliance. The two applications use different swiptes. The swipe comes with the mobile application setup fee. Thanks to Todd Martin and Sage Insipre Tour for the eduction.

Follow up with Sage 100 v2013 and credit card swiping. With the assistance of Justin Cosgrove and Jeff Zimmerman of IDInnovations, client is now swiping the cards in v2013 and receiving the swipe card rates. One thing you will want to verify with SPS if you are implementing swipes in v2013 is that the customers SPS account is set up for Swiping. An existing account may be set for keyed rates only (as was my client). A back door tech support source at SPS is below.....

Thanks Jeff. Good information.