In the past 2 weeks a very confusing and upsetting situation has takes place in India with the respect to Paypal and personal Indian payments.

It all started around the 1st of February.

All payments sent from personal Indian accounts are reversed. This would basically be like accepting a credit card, and 5 days later (long after the merchandise or service has been performed) that money is given back to the customer!

When reversed, there are several immediate reactions. First off, it is confusing to anyone who sent a payment and had it returned a few days later. It is more confusing and upsetting to the business that accepted that payment as they are now without the money and without the service or product that was paid for. Additionally, this unbalances the accounts of thousands and possibly millions of account holders, not just in India. Many of these recipient account holders made payments to other businesses. When the original amount was reversed and subtracted from their account, any recipient account lost money, and many Paypal accounts went negative. Some people got paid, while others lost the money. Paypal was also blocking any withdrawals to an Indian bank account, so even if a business did manage to get paid, there was no way for them to take the money out of Paypal.

As usual Paypal was completely mum about the actual details of the events of what was happening, further compounding the frustration and confusion that was sweeping Indian paypal account holders and those who received a payment from an Indian account. On February 5th, I had speculated that there was some government intervention going on, as the scope and damage that these events were causing were absolutely massive. Even at this point an Indian Paypal user could send money, and at first would seem successful, but would be returned several days later.

On the 6th of February, with Paypal users continuing to panic still trying to send money, Paypal finally publicly announced that there was a problem with personal payments.

I’m writing to let you know that personal payments to and from India and transfers to local banks in India have been suspended while we work with our business partners and other stakeholders to address questions they have about the service.

While this was an unacceptably vague response to the seemingly massive situation that was unfolding, it was nevertheless some response.

More problems…

About a day later, a second problem had been discovered with many Paypal accounts. After being refunded, many Paypal users noticed that foreign exchange fees had never been refunded. Thousands of Indian freelancers, Indian businesses, and worldwide businesses who accept payments from Indian account holders are getting more upset and confused. Although Indian payments only make up a small portion of Paypal payments, it’s clear that there is a major problem affecting far more people and businesses than just Personal Indian account holders. Now there’s money, paypal fees, and separate foreign exchange fees lost in millions of payments and refunds, a true accounting nightmare.

Everyone knows there is a problem, but nobody knows what it is and Paypal won’t say a word.

On February 10th the truth finally comes out.

1. Why did you suspend local bank transfers and personal payments to and from India?

We temporarily suspended these services to respond to enquiries from the Indian regulators, specifically questions on whether personal payments constitute remittances into India.

We’re working with the regulators and our bank processing partners in India to get this resolved as quickly as we can. We realize that this is causing considerable inconvenience to our customers and I want to reassure you that this is a top priority for the leadership at PayPal

2. When will personal payments be turned back on?

The regulators recently let PayPal know about revised licensing rules that we are now actively engaged in securing. Personal payments to and from India will be suspended for at least a few months until we fully resolve the questions from the Indian regulators.

3. When will local bank withdrawals be available?

Customers should be able to withdraw their funds to a local bank within the next few days. In the meantime, we’re going to restore the money into the PayPal accounts of any customers in India who have initiated a recent withdrawal, so they know that the money is safe in their accounts. Customers will also be reimbursed for any withdrawal fee charges.

4.The PayPal reversal has left me with a negative balance. What shall I do?

If you bought something or transferred money out of your PayPal account to your bank account before we reversed the payment then you may be left with a negative balance.

If this was a payment for a purchase of goods or services, you should contact the sender and have him or her resend the payment as follows:

(a) click the Send Money tab, and

(b) select “purchase.”

If this was a personal payment, then the sender will need to find another payment method until we restore the service. We’re sorry about this.

If you can’t recover the funds from the sender, you can bring your PayPal balance current by logging in to the PayPal account and clicking the “Resolve Negative Balance” link on the Account Overview page.

5. My payment was reversed but it was not a personal payment. What happened?

Only personal payments should have been reversed. Customers who believe that their payments were reversed in error should request that the payment be sent again by following the steps above (click the Send Money tab and select “purchase.”)

The Reserve Bank of India (RBI) put a halt to all Paypal payments when they finally realized that Paypal was a acting as a cross border money transfer system due to a law passed in 2008, “Providers of cross-border money transfer service need prior authorization from the Reserve Bank under the Payment and Settlement Systems Act,”. The reasoning behind the law is that many cross-border transactions are considered remittances, which fall under additional regulation by the RBI.

At this point, Indian Paypal account holders cannot send or receive money through paypal, and even many Business account holders cannot withdraw into their Indian bank account. Paypal has indicated that it may takes months before payments get back on track in India, leaving very few payment options for freelancers and many businesses in India’s rappidly growing IT services industry.

What strikes me as simply baffling is how it took 2 years for the Indian government to realize that Paypal users in their country could transfer money to and from Paypal users in other countries, and why they would tackle this situation is such a disruptive manner. Seriously, Paypal has been in India for several years and nobody bothered to consider that the fastest growing payment mechanism in India might fall under this new law when it was being drafted?

Equally baffling is why Paypal didn’t completely suspend Payments when they were given the request on January 27th. Instead they reversed thousands of transactions that had already been submitted, allowed these recipients to forward the money they received as payments to other businesses. They also continued to allow transactions to be sent until after the 7th, 10 days after they stated that transactions had been halted.

The combination of gross under-sight by India’s financial regulatory systems, and Paypal’s gross negligence in adequately responding to a major operational casualty, caused one of the larger payment system implosions that we’ve seen. Most of the ancillary damage was completely avoidable, had Paypal responded immediately and adequately to RBI’s request. While I’m sure that Paypal will pull through unscathed as they have so many times before, I do believe that their position in the Indian payments market will be scarred for a long time.

One of the top reasons for receiving a chargeback is when a customer doesn’t recognize a business name on their credit card statement. These are the types of chargebacks generally occur a few weeks or even a month after a purchase was made. The customer looks at their credit card statement and not recognizing the name of a place where they made a purchase, they call their bank. Many times they do not even need to request their bank to file a chargeback, but the bank automatically does on their behalf. American express has a history of making chargebacks without their customers asking for one. We were unfortunate enough to be the recipient of one such chargeback, and Amex even refused to reverse it after the card holder told them that they indeed made the charge.

When you initially set up your merchant account, your business name (DBA) is normally used as your descriptor. The descriptor is the name that your customer will see on their credit card statement. While this is a fairly simply process, many times processors mess up the descriptor, or they put something that a customer would not immediately associate with the business they just purchased from. A long business name can be difficult to logically squeeze into the few characters allowed in a descriptor. Websites are especially susceptible to this dissociation, as a domain name may not directly match the business name. Some customers will remember the domain, and some the business. In most cases I recommend using the domain name rather than the business name. If they don’t recognize it, they can pull up the website: “Oh yeah, I remember buying something here.”

Here’s an actual screen shot from my bank account. I have no idea what this is…

When you open your merchant account, you should always run a test transaction (NOT WITH THE MERCHANT ACCOUNT OWNER’S CARD!) for a few dollars to make sure the money goes into the correct bank account. This is a perfect time to check the descriptor and make sure it is something that makes sense.

These types of chargebacks are a waste of money and time for business owners to deal with especially since they are normally legitimate transactions. Make sure your descriptor looks the way you want it to. If you start receiving “Cardholder does not recognize transaction ” chargebacks, it is a good idea to verify that your descriptor is not what is causing the problem. If there’s something wrong with it, your processor should be able to fix it for you.

Lastly, operating multiple websites on the same merchant account will often result in an increase of chargebacks. Unless the products are the same and the domain names are similar enough that a customer will recognize the charge on their statement, business’s should have a unique merchant account for every website they operate. Visa and MC routinely shut merchants down for operating multiple unrelated websites on the same merchant account. How do they find out about them? Almost 100% of the time it’s from: “Cardholder does not recognize transaction” chargebacks.

If you find any ridiculous descriptors on your statements feel free to send them to me, and I will post them up here. Use a service like photobucket or flickr to upload them and send me the link to your photos through the form.

After reading an article this morning, the author states that merchant’s are prohibited from asking for an ID to process a transaction. Sounding completely ridiculous, I decided to further investigate.

I stumbled on a Visa operating regulation that I was not aware of. “You cannot require an ID in order to complete a Credit transaction.” Furthermore, you cannot decline or refuse a transaction if your customer refuses to provide an ID.

Although Visa rules do not preclude merchants from asking for cardholder ID, merchants cannot make an ID a condition of acceptance. Therefore, merchants cannot refuse to complete a purchase transaction because a cardholder refuses to provide ID. Visa believes merchants should not ask for ID as part of their regular card acceptance procedures.

The author was completely wrong as far as MasterCard goes, who takes a different approach to the situation…

For unique transactions processed in a face-to-face environment (with the exception of truck stop transactions and card-read transactions where a non-signature CVM is used), request personal identification of the cardholder in the form of an unexpired, official government document. Compare the signature on the personal identification with the signature on the card.

American express is a little vague, but still states that the identity should be verified…

Verify that the customer is the Card-member. Cards are not transferable.

It’s actually hard for me to believe that Visa goes this far in trying to protect their cardholder’s convenience at the expense of their merchants being exposed to potential fraud. I strongly recommend checking the ID of every card holder. No regulation prevents a merchant from asking for an ID, and I can’t imagine a customer seriously refusing under any normal circumstance. Merchants are not allowed to ask for an ID on “PIN” debit transactions where a customer enters their PIN number into a pinpad. For signature debit, where the card is processed like a credit card, treat the transaction just like credit and ask for an ID.

If anyone would like to see the various card regulations, they can be found here:
Visa
MasterCard Chargeback Guide
AMEX

Discover’s site requires registration, and I was unable to register with the Discover numbers of the 4 merchant accounts that we have. If anyone has a copy of Discover operating regulations, I would love to see them.

I am starting a new category where I will answer relevant merchant account related questions on the blog. This will be in the format of a Dear MSP. If you have a question that you need answered, please feel free to ask as usual, just keep in mind it may end up being answered publicly if it is relevant to other business owners. As always, any personal information sent will remain strictly confidential.

I’ll try to answer these question in a weekly Dear MSP post.

Thanks
Jamie

Visa and MasterCard have long standing regulations preventing surcharging customers for using a credit card. Recently they have allowed discounting for cash purchases (wordsmithing somehow negates the meaning of surcharging???).

I see merchants on a daily basis surcharging for credit transactions, and while I see it more as an inconvenience, the government doesn’t see it the same way. Currently there are 10 states with laws against credit surcharging, California, Colorado, Connecticut, Florida, Kansas, Maine, Massachusetts, New York, Oklahoma and Texas. Some of these states have very easy ways to report businesses that are illegally surcharging, creating a quick path to fines, bad publicity, and lawsuits.

Apart from state laws, all that an angry customer needs to do is call their card issuer and report the business. The issuer passes the message down to the business’s processor, who then tells the business to stop. If more complaints are received, fines are assessed ($10,000 – $20,000 for the first offense), and then the business is shut down and placed on the TMF list by the issuer. They are then prohibited from accepting credit cards by just about every processor in the world until they get off the list.

It’s true that many businesses get away with surcharging for a long time, but I urge any business owner to seriously consider the potential consequences from breaking the surcharging regulations. It may seem like a logical idea from a financial standpoint, but the repercussions can be quick and severe.

The merchant account industry is in turmoil right now relating to the PCI-DSS fees that just about everyone is currently experiencing. I would like to make an analysis of why we are all seeing these fees and how this whole situation came about.

Just to dispel any hopes that these might be going away soon, they’re not. If anything, PCI is going to get much stricter, as congress has openly stated that PCI-DSS is not nearly enough.

How did we get to this point?

The entire PCI-DSS concept materialized about 5 years ago when Visa created PCI and MasterCard created a program called SDP. By creating a security framework based on history, logic, and anticipated weaknesses, these programs were designed to be a model for safely storing and transmitting credit card data. Eventually the issuers joined together and created the PCI security council, which was supposed to be an envelope organization in charge of PCI standards. The idea was that it would be far easier for merchants to handle a single version of PCI, rather than Visa, MasterCard, Amex and Discover separately having their own standards. Over time, PCI-DSS gained an adoption time-line, and became much more organized. PCI covers general operating principals, but is primarily geared to network and data security, as the internet and broadband access have created unseen opportunity for thieves to remotely steal large amounts of credit card and sensitive data.

Continue Reading »

Many times business and website owners want to store credit card numbers for later. This allows re-billing customers for recurring orders, and allows easier checkout for repeat customers on a website.

If a business decides they want to actually store credit card numbers, they are subjected to stricter PCI-DSS standards, and run a real risk of losing customer data just by the fact that they have it. Apart from PCI, it’s difficult to securely store credit card data as there is a multitude of technical aspects to doing it safely. If you lay it all out on paper, there is a huge amount of work, ongoing management, and liability in storing credit card numbers.

But, sometimes we still need to store credit card numbers, so how do we do it?

We simply let somebody else store it for us. If we outsource our credit card number storage to another party, we are no longer liable for that data. This is still your customer’s data, so your reputation is on the line, but not necessarily your wallet. What’s even better is that with some of today’s available services, outsourcing this can give us an easier method of re-billing our customer than if we could easily store credit cards.

Who can we store these with?

This is the easy part. Your payment gateway may have a customer storage mechanism, or customer vault. If it doesn’t, find one that does.

What this does is store your customer’s information and credit card number in the payment gateway’s secure database. If you need to charge your customer again, you simply reference their customer number and the amount you wish to charge. You can do this manually through the administrative virtual terminal of your payment gateway, or you can often do it directly through your website using an API. You can also setup recurring payments, refund, void, or credit via a customer’s stored card.

With a system like this, a developer can create a custom recurring billing system, or a user friendly “remember card” feature with your ecommerce site’s checkout system.

Which gateways support this?

The Network Merchants Gateway which we developed an integration module a few weeks ago, supports customer storage at a very low cost per month. Network Merchant’s customer storage is called the Customer Vault.

Authorize.net has a similar system called the Customer Information Manager.

There’s definitely a number of other gateways that have custom vault type systems as well. These can be integrated with a website, charged manually, or even integrated with a desktop application. A customer vault is a responsible way to outsource credit card number storage while still being able to use them.

We’ve just finished a PHP Integration class for the Network Merchants Payment Gateway.

This script integrates with the Network Merchants Direct Post API, and the Network Merchant customer vault API.

The Direct Post API allows processing credit cards and electronic checks. The Customer Vault allows merchants to store their customers credit card and check information in Network Merchant’s secure customer vault. The API allows charging customers stored in the vault without a merchant ever storing a credit card number.

View and download the class here »

We just finished creating a new tool. This tool generates a voided check for your business.

When a new business goes out to setup a merchant account, they will be asked for a voided check. Many processors will no longer accept temporary checks, so we developed this too to print a voided check until you get your real ones.

Generally a merchant can ask their bank for a letter of an accounts existence, but many banks are now refusing to do this, in an effort to force customers to process with them. Since it’s perfectly legal to print your own checks, here’s our response to this dilemma.

So, if you need a voided check, take a look at our Voided Check Generator.

Authnet suffered an outage this morning. Current rumors suggest that it was due to a fire at a data-center, which subsequently destroyed the backup generators from the sprinklers.

Authorize.net is currently the largest payment gateway in the world. This is affecting millions of websites right now. To my knowledge this is the first major outage since the DDOS attack they suffered several years ago.

A casualty of this magnitude has the ability to permanently damage / destroy this company’s trust and reputation.