Thursday, July 10, 2014

Merchant Account Contracts

OMG, the credit card processing industry is so messed up.  I'm tempted to go start my own and cut through the industry like a knife through butter.

First, a little background, I run a ~$10M online business based on recurring monthly billing.  It's all about efficiency, effective handling of credit card data, and cost control. Also reliability. After a decade with one vendor that we have totally outgrown, we are finally switching vendors. After a few months of talking to vendors, we finally found one with great technology and prices for the handling of recurring card not present data.

I'm ready to sign and they send over the contract. OMG!  So poorly written and one-sided that instead of signing, we are now going back to our candidates two through five to see what's going on.

Our third favorite candidate immediately flew in (I'm going to see them this morning) and said: "You are a great merchant, we'll do whatever you want contractually."

Meanwhile, the first choice company just sent me a revised version of the contract which still has:
- a three year initial term during which there's no way out unless the processor messes up, gets notified in writing formally, and fails to address it within 60 days.  So they could stop answering the phone and  go down weekly and my business would be legally stuck with them for two months.  I don't think I'm going to sign that.
- no clarity (despite my request) that the customer's credit card data is ours and is available upon request to move
- not a single obligation by the processor to us that they'll remain compliant with all laws, stay solvent, safeguard data, do their best for us, etc etc But there's probably 1-2 pages of such certifications requested of us. Here's a for instance. They claim the right to see all of our financial statements upon request. Fair enough since they are underwriting. I told them in the conference call that this sort of thing needs to be clarified. For what purposes do they get to pull our data? Who gets to see it?  This will be confidential data etc etc.  Oops, it's not there!  Does this mean that other vendors agree to provide their financials but they do so with no if, ands or buts about it?
- they did in the latest draft agree to freeze prices during the initial 3 years but they didn't agree after that to any prior notice period before changing prices.  They did say that in the long term if they change prices, we can complain in writing and if they fail to address or reprice within 60- days, we would be allowed to change vendors.
- the agreement includes five specific references to processors "standard operating procedures."  Remember, this is a contract, not a conversation. I asked about getting a copy of the standard operating procedures. It turns out that these are not written down. I asked about the transparency of these procedures to an outsider and if there was any way that the Merchant could verify them or was it just: "whatever the Processor says it is."  Of course, it's a totally nebulous opaque concept. Yet they left it in the contract.  Who does that?

Of course, I understand that mostly, contract don't matter. People and companies do what they want to and the contract is one of many pieces of the process and relationship so focusing on the contract too much is not smart business.  But still, my minimum requirements;
- freedom to move if it's in our business interest
- clarity on the cost and mechanism for us getting our credit card data
- nothing weird in the rules that will come back to haunt us.

Wednesday, May 14, 2014

Chips on the Cards, EMV, Shifting Liability

I'd like to thank Wikipedia for this info.

What is EMV? EMV stands for EuropayMasterCard and Visa, a global standard for inter-operation of integrated circuit cards (IC cards or "chip cards") and IC card capable point of sale (POS) terminals and automated teller machines (ATMs), for authenticating credit and debit card transactions.

What about EMV in Card Not Present Situations?  Visa and MasterCard have developed standards for using EMV cards in devices to support card-not-present transactions over the telephone and Internet. MasterCard has the Chip Authentication Program (CAP) for secure e-commerce. Its implementation is known as EMV-CAP and supports a number of modes. Visa has the Dynamic Password Authentication (DPA) scheme, which is their implementation of CAP using different default values.

Why should I, an online merchant, care about EMV?  The supposed increased protection from fraud from EMV has allowed banks and credit card issuers to push through a 'liability shift' such that merchants are now liable  for any fraud that results from transactions on systems that are not EMV capable. This is true as 1 January 2005 in the EU region and it is supposedly coming to the US in "two years", ie 2016. (Note,  I don't have a source for this.)

Credit Card Processing for Monthly Recurring Billing

We have used the same vendor for ten years and we are sick of him. He has never really helped us understand the industry,  how things work, or helped us with improving operations. Service is intermittent. Problems are frequent. There are three areas that we ought to be able to really improve our situation.

1. Declines processing.  On any day, X% of our monthly subscribers are declined.  They are declined conceptually for a few reasons:
A.  insufficient funds
B.  expired credit card
C.  updated credit card due to security
D.  credit card account closed

Our vendors returns a few different pieces of information on the credit card declines:
1.  Call a 1 800 number to get the sale approved. The number is our own credit card processor who then gives us a phone number and the credit card number so that we can get a voice authorization. This is time consuming and results nine times out of ten in a failure.
2.  Invalid account number. Does this cover B, C, & D?
3.  Expired.
4.  Declined. This is the vast majority but they do come with a code: 0700540009  (BTW, if you google that code you get a fair number of people asking about what that decline code means).

Our traditional system of handling declines is to try again every ten days:
D1 - The first decline. We ignore it.
D2 - Second decline. If they are an active user, we send them an email
D3 - Third decline. If they are an active user, we send them an email and turn off their account with a message
D4 - If they are an active user, we send them an email and turn off their account with a message.
Also, we notify those with credit cards that are going to decline in the next 60 days that they need to update their credit card.
Recently, we've tried some robocalling to notify our users about declines and that has been surprisingly successful.  No numbers yet. We used to try to call ourselves and never found a way for it to be effective.

Questions - Ideally by A, B, C, & D above...

1.  Overall percent of D1s of billings?
2.  Overall number of D1s that become D2s?
3.  Overall number of D2s that become D3s?
4.  Overall number of D3s that become D4s?
5.   Credit card updates by users because we notify them that their credit card is expiring?
6.  Percent of each type of decline that our vendor returns to us?
7.  Updates between D2/D3, D3/D4?

Overall, our real questions are:

- What's the best method for avoiding declines with updaters and submission of AVS data and whatever.
- Once declined, how best to proceed in terms of trying again, contacting user, using technology to update?
BTW, all of this is focused on recurring billing cancellation, what about initial cancellations?

2. Costs. We are still in a system of tiered pricing which is confusing. There are costs and credits. Overall, we are paying ~4% to the gateway, processor, and credit card vendors. A lot!  Just getting this down by a percent will save us a lot of money per year.


3.  Reliability and reports. Compliance too.



Card Not Present Expo


The Card Not Present Expo is coming up and is conveniently located for us. Also, it's a hot topic. Nevertheless, the agenda seems a little too deep for me, the part that I'm interested in is the three hour bootcamp which is 2-5pm,  Monday, May 19th, $648 for the whole four day expo. It's in Orlando.  I wonder if there is a price just for the Boot Camp?

Intro: What Every CNP Merchant Should Know: 
Navigating Today's Challenging Payments Eco-System
  • The State of The Payments Union; 2014 Threats Update
  • Effective Payment Processing; Getting Set Up For Success
  • Protecting Your Sales Process From Fraud; Pre-Sales Trends and Tools
  • Post-Sale Challenges/Considerations; Effective Chargeback Management
  • Maximizing Your Billing and Customer Retention Efforts
  • Mobile and Emerging Payments
The CNP Boot Camp has been specially programmed for attendees to learn as much as possible—as quickly as possible—about accepting card-not-present transactions and the complex issues surrounding them. The Boot Camp was developed in response to feedback from merchants and industry executives and will provide campers a knowledge base enabling them to optimize their timeand get the most they can out of the rest of the Expo.

The Next Step: 
Profit from New Markets and New Realities
  • Evolving business models: ISO to PSP
  • Expanding from the US to global markets
  • Landing in Europe: a regulatory approach
  • Fraud challenges for international expansion
  • Mobile Payments: business models around the world
  • Navigating Alternative Payments in three dimensions
Reg TodayBased on the phenomenal success last year of our Boot Camp workshop, this year we are serving the other end of the spectrum. We will be offering a Grad School program, designed for veteran payments professionals, that will offer a more sophisticated look at the issues under debate in CNP payments and what challenges and opportunities lie ahead. This session will be will be offered free of charge to all registered attendees, and will run simultaneously with the Boot Camp Workshop.

Thursday, May 1, 2014

Merchant Account Credit Card Consulting

We have searched around for a number of years to improve our credit card processing and so far, haven't been able to make a decision. Our problems:

  • Our current processor works, we have ten people trained on using it, it's integrated with us technically and in our accounting system. As a small company, it seems like an overwhelming project to change processors
  • The costs are bad but whose to say how bad? Overall, Visa/MC/ processing add up to around 3.9% of revenue with the average transaction at ~$24 on over $5M of business.  Will they definitely go down if we switch?
  • Sometimes, our current processor does something good about fixing a problem or providing us info so we like him.
  • Other vendors sound like they are full of it saying all sorts of silly things about reduced costs (which they won't guarantee) and pooh pooing how difficult it will be to switch.
So we've finally made a decision. We've decided to hire a consultant to help us figure out what to do. Enter Paul Larsen consulting. We might work with Mr. John Sullivan. Stay tuned....

Wednesday, December 4, 2013

TRUNCATION and other Merchant Account Info you should know

Here's some terms related to merchant accounts and credit card processing that I should know about:

TRUNCATION - When only some digits of a customer's card number appear on a sales draft or receipt to  provide better security while still enabling  identification (for the cardholder) of the card used;  it’s required by federal law (since 2006) that no more than the last five digits of a card may be shown on a receipt.

TOKENIZATION - Replacement of sensitive data with a unique identifier that cannot be reversed mathematically;  commonly used in payments to replace card data.

ADDRESS VERIFICATION SERVICE (AVS)  - The process of validating a cardholder’s given  address against the issuer’s records to determine accuracy and deter fraud; a code is returned with the authorization result that indicates the accuracy of the address match 

These are samples from Litle & Co's Payment Dictionary which is available as a free download. Very cool. Thanks Litle!

Friday, October 11, 2013

Paypal as a Merchant Account Vendor: PCI Compliance & Chargebacks

I received an email from Paypal, who we use as a merchant account vendor, about how to avoid Chargebacks. It's a pretty good resource. I've excerpted a bit below.

In contrast, they've never contacted me about PCI compliance which I think is amazing. I've always believed that PCI compliance is required for everyone who takes credit cards.  I would count as a tier 3 vendor since I don't store any credit cards and my only obligation to be PCI compliant is to:
- ensure my merchant account is PCI compliant
- have my site checked by an authorized reviewer annually that it is clean and strong so that when we pass the credit card numbers, there's not problem. But I think they, as my merchant account vendor, are obliged to make sure that I am aware of these issues and in compliance.

A chargeback, also known as a reversal, is when a buyer asks their credit card issuer to reverse a transaction after it has been completed. It is available only to users who make a payment funded by their credit or debit card.
There are three main reasons a buyer will do this:
  1. The purchased item never arrived.
  2. The item was significantly different than advertised.
  3. Their credit card was used without their permission to purchase the item fraudulently.
Chargebacks are initiated and handled by the buyer's credit card issuer - not by PayPal - and therefore will follow that company's regulations and timeframes. That said, PayPal often plays a role in resolving chargeback disputes.