Stanley Kox: Hi, my name is Stanley Kox. How may I help you?
Friday, September 30, 2016
An online chat with eFax (a j2 company)
Stanley Kox: Hi, my name is Stanley Kox. How may I help you?
Posted by Michael at 10:01 AM 16 comments
Tuesday, September 20, 2016
Are you considering eFax? Or any other j2 company?
Note: j2, which owns eFax and many other disreputable companies, has an F rating from the BBB with hundreds of complaints. Before you trust them with a credit card number, take a look at their Google search results.
j2 owns about half of the fax line companies out there, including eFax. The web is littered with complaints about those companies. What is particularly striking is the companies that were independent and had good reputations, but had slews of complaints after j2 bought them.
j2, in the guise of eFax, recently bought MaxEmail. The transition has not yet completed, but customers like me have already fled. I was glad to leave j2 in 2005, and there is no way I’m going back to a j2 company like eFax.
The companies say that prices will remain the same. Reality check: one line I looked at is going from $14.85 to $84.00 under eFax, more than 5.5x the previous price.
The companies say that the allowed fax pages will remain comparable. Reality check: one line I looked at is going from unlimited inbound pages to just 250 inbound pages. And I will lose the rollover of over 22,000 pages/messages, as well as the usage credit on the account.
The companies say that the terms and conditions will remain comparable. Reality check: if I want to reclaim my own fax number that I had ported in originally, MaxEmail charged nothing, while eFax charges between $40 and $500.
The companies say that the services will remain comparable. Reality check: we had a couple of voicemail lines with MaxEmail which allowed callers to leave messages without pressing buttons. That may sound unimportant for human callers, but it’s actually critically important with a number of health care providers for our child who use automated systems to leave messages. Those automated systems can leave a message with MaxEmail, but they cannot with eFax, because eFax doesn’t offer that capability.
The companies say that customer service will remain good. Reality check: eFax refuses to issue refunds for prepaid services even when they unilaterally change terms and conditions, and even when they disable necessary features. When I tried emailing four different fax services to ask similar questions, three of those fax services answered the questions within a couple of hours. eFax did not reply for 3 days.
I don’t know if MaxEmail will be kept around as a zombie brand, the way j2 has done with so many other brands. I’ve recommended MaxEmail many times between January 2005 and August 2016. That’s why I feel like I need to publicly unrecommend them now.
Posted by Michael at 9:53 AM 0 comments
Sunday, September 18, 2016
Out with the old, in with the new
February 2016: I lost my primary credit card processor when Amazon Local Payments closed. (Advance notice: several months.) I replaced them with Square, which had been our previous credit card processor and which we still had as a backup. Getting our data out of Amazon Local Payments before they deleted their records took some hours. At least they gave a few months notice. No other costs.
June 2016: I lost my shopping cart service when Americart folded. (Advance notice: initially 1 week, then 4 weeks, then uncertain, then they surprised us one morning.) They replaced themselves with Capital One Spark Pay, which has been buggy and dim-witted, but at least saved us from having to redo the shopping cart integration on thousands of web pages. Setting up the new back end took about 100 hours including testing. Putting in bug reports has taken about 20 hours, and is ongoing.
August 2016: I lost my primary software sales channel when Kagi folded. (Advance notice: none at all.) I replaced them with FastSpring. Switching took about 20 hours of research, 10 hours of setup, and a week of downtime while switching over. Other costs: income for some sales that vanished along with Kagi.
August/September 2016: I lost two voicemail lines and one fax line when Maxemail folded. (Advance notice: 1-4 weeks estimated, with no certainty.) I replaced the voicemail lines with Google Voice and the fax line with Nextiva vFax. Setup for the voicemail lines was about 30 minutes and worked immediately. Setup for the fax line was about 2 hours of phone calls and paperwork, and 15 days of waiting to port the number. Other costs: $50 in advance payments to Maxemail gone, and some hours of research to decide on replacements.
September 2016: I lost my ability to process credit cards from web site orders when Capital One Spark Pay decided that they would no longer allow manual processing. (Advance notice: none at all, then 8 days.) I replaced manual processing with Stripe’s online gateway. Research was about 30 hours, setup was about 1 hour, testing is ongoing.
At the end of all of this, I am simply dealing with different providers. Nothing is better or cheaper or more likely to work correctly. And all of the changes since June have been one crisis after another with little warning and lousy communication.
I’m hesitant to even think about the providers who are acting reliable this year. At this point it feels like another shoe is always about to drop.
Posted by Michael at 11:41 PM 1 comments
Spark Pay is removing manual credit card processing
Capital One’s Spark Pay (aka SparkPay) division offers shopping cart software for web sites. They provide the back end that lets our customers put items into a shopping cart and then enter payment information. With a credit card, a merchant might use a payment gateway to charge the card automatically, or the merchant might collect the credit card information from Spark Pay to charge the card manually (offline processing).
The merchant might prefer to do offline processing of the credit card for any number of reasons: to examine payments for fraud attempts, to use a processor which isn’t connected to a gateway that the shopping cart software can interface with, to wait to confirm that an item is in stock or to wait until the item has shipped before charging the card, or to confirm total order amounts before charging a card.
Spark Pay used to offer both options. Starting September 27, that’s over, according to this email from Spark Pay:
We're enhancing security. Starting September 27, 2016, we'll no longer be able to store your CVV data for offline processing. What This Means for You Your customers' CVV data will not be available after September 27th. You'll need to modify your manual offline credit card processing before then to ensure compliance with PCI standards. Capital One(r) will not impose any fees for this change.
What Spark Pay is not mentioning is that processors all require the CVV code in order to charge a card. When Spark Pay no longer gives that CVV data to the merchant, the merchant cannot charge the customer’s card at all. It’s completely unclear why Spark Pay would give the merchant the remaining credit card data, since it’s basically useless without the CVV code. (Note: to be precise, it’s actually the CVV-2 code, which is the security code printed on the card, rather than the CVV or CVV-1 code which is encoded in the magnetic stripe.)
PCI standards (both for PCI-DSS and for PA-DSS) are very clear that merchants and payment applications must not store CVV data after the card is authorized. But if you delete the CVV data before the card is authorized, you’ll never get to charge the card at all. That’s precisely why the CVV data is so important to protect: it’s what lets you use the card to make purchases.
But Spark Pay is insisting that they cannot store CVV data BEFORE authorization, a complete misstatement of the PCI standards. And Spark Pay insists that merchants can still charge credit cards without the CVV code, even though that’s just not true. In fact, their own credit card processing division is perfectly happy to confirm that a charge will be denied without a CVV code. Spark Pay tried last week to identify an alternative processor that does not require a CVV code, and could not find any.
With almost zero notice, Spark Pay is effectively disabling their shopping cart software, while still pretending that merchants will be able to process credit cards without a CVV code even though Spark Pay knows that isn’t true.
Do you use a processor which doesn’t require CVV codes? Please speak up in the comments here. (Though be aware that they’re likely to start requiring CVV codes soon if they don’t already, because everyone else has started doing that in recent years.)
Do you know a payment gateway which doesn’t require PCI compliance paperwork? Please speak up in the comments here. We were delighted to stop having to do PCI compliance paperwork every quarter when we switched from using Elavon to using Square for processing credit cards, but Spark Pay doesn’t offer Square as a payment gateway.
If you are a Spark Pay merchant who is affected by this, give them a call at 1-800-936-9006, Ext. 1, between 8 a.m. and 6 p.m. CT Monday to Friday. Ask for an account manager. Ask for a supervisor. And good luck to us all.
Added on September 18, 2016: If you go to Spark Pay’s support page at http://kb.mysparkpay.com/what-are-cvv-authentication-codes-and-why-are-they-not-stored.aspx you’ll find the following about CVV codes:
Storing CVV-2 Information
This information is not permanently stored because that action is prohibited by law. The Visa USA Inc. Operating Regulations explicitly prohibits merchants and/or their agents from storing the CVV-2 data. The merchant may require this code to complete any transaction, whether it be online, over the phone, or in person. Some merchants chose to process payment on purchase of the item, while others wait until the order has been shipped. To accommodate these methods,Spark Pay online store CVV-2 information until the order payment is obtained, then it is stricken.
Prohibited by law? Technically, our laws are written by Congress, not by Visa USA. Also, the CVV-2 data cannot be stored after authorization. Other than that, this is a reasonable policy that meets the requirements of credit card processing, data security, and common sense. Keep the data only as long as you need it, then delete it. Too bad they aren’t sticking with this policy.
Posted by Michael at 9:23 PM 0 comments
Sunday, September 4, 2016
More than test scores
Posted by Michael at 11:32 PM 0 comments