Information on Merchant Accounts,
Ecommerce and Credit Card Processing

May 3rd, 2010 by Jamie Estep

A Comparison of 3 Alternative Payment Methods

Filed in: 3rd Party Processors, Merchant Accounts, Review | 9 comments

Ecommerce website owners have typically had 2 payment methods their customers would want to pay with, Paypal and credit cards. In the the past 10 years there have been many attempts and many failures to dethrone Paypal’s dominance as the primary alternate payment method on the internet. In the past 2 years, 2 services, Google Checkout, and Amazon Payments, have emerged as at least a distant-contender in the alternate payment landscape, both using their massive presence and customer base to establish an immediate threat to Paypal’s dominance.

So, how do the 3 alternate payment methods compare to each-other from a merchant’s perspective? There are 3 main areas that merchants are generally interested in, cost, protection, and integration. The following is a comparison of Google Checkout, Paypal, and Amazon payments in these 3 areas.

Cost

Since cost is one of the most, if not the most, important aspects of any payment system, we’ll waste no time in comparing these. All of these services offer volume based pricing, meaning if you process many thousands of dollars per month the cost comes down considerable.

Standard processing fees:

Monthly Volume Paypal Google Checkout Amazon Payments
0-$3,000 2.9% + $0.30 2.9% + $0.30 2.9% + $0.30
$3,000-$10,000 2.5% + $0.30 2.5% + $0.30 2.5% + $0.30
$10,000-$100,000 2.2% + $0.30 2.2% + $0.30 2.2% + $0.30
>$100,000 1.9% + $0.30 1.9% + $0.30 1.9% + $0.30

Micropayments:

Transaction Amount Paypal Amazon Payments
(< $10 Amazon, < $12 Paypal) 5% + $0.05 5% + $0.05

It’s no coincidence that Google and Amazon have priced their services exactly the same as Paypal. Paypal has a terrible reputation from many sellers perspective, and I think that Amazon and Google are betting that by simply matching their costs, they will gain customers based on their quality of service.

Seller protection

Google Checkout, Paypal, and Amazon Payments are all considered 3rd party processing systems. What this means is that they are accepting payments on behalf of your business. With a traditional merchant account, your business has a direct relationship with Visa and MasterCard through your credit card processor, whereas a 3rd party processor, you are basically using the 3rd party processor’s merchant account.

Seller protection is of significant importance because the 3rd party processor is responsible for any expenses related to chargebacks and fraud from your business. If you receive a chargeback, they generally pass expenses down to your business, but the 3rd party processor is ultimately accountable to Visa and MasterCard for expenses associated with these. Google Checkout, Paypal, and Amazon Payments employ their own fraud screening, customer dispute, and chargeback management systems. Since you have very little control and access to your customer and transaction information, it is important to understand what sort of protection you have available, and what sort of pre-filtering you can setup to prevent unwanted transactions in the first place. One good note about Amazon payments in particular, is that many of the potential customers using this services have long standing relationships with Amazon.com, which can greatly reduce the number of potential fraudulent orders.

Account taken over? – All 3rd party processors introduce a second avenue for fraud that traditional merchant accounts do not have, which is when an account gets hacked and taken over. hacked accounts are not always immediately discovered creating a real chance that you accept payment and ship an order that was placed through a hacked account. As far as I have seen, seller protection is not extended to hacked accounts even though there is no way for you to know if you are accepting payment from a hacked account.

Lastly, since all 3rd party processors have their own dispute resolution systems, a customer actually has 2 chances to make a dispute or chargeback. The first is directly with the 3rd party processor through their dispute resolution system, and the second is directly with their credit card issuer. This gives customers 2 chances to recoup their money if they are unhappy with your services, or are trying to defraud a merchant by making a chargeback after receiving their order.

Paypal

Paypal allows for the most flexibility in the parameters that are required for you to accept a payment. You can specify countries, confirmed shipping addresses, payment types, among many others. For Paypal to provide protection to a seller a number of certain qualifications must be met otherwise Paypal will not cover the cost of a chargeback. Since a merchant can manually change their own requirements for accepting a Paypal transaction, it’s possible to inadvertently remove oneself from seller protection.

Additionally, likely due to the number of people using it, Paypal is probably the #1 avenue that fraud is committed over the internet. Search around and you’ll find thousands if not millions of cases where sellers have lost their money and product, and in many cases complying with all Paypal seller policies. You’ll find an equal number of upset buyers who lost money from an unethical sellers.

  • The transaction must be marked eligible or partially eligible for Seller Protection on the Transaction Details page.
  • The item must be shipped within 7 calendar days of receiving payment to the shipping address on the Transaction Details page, and in accordance with our shipping requirements.
  • In the event a buyer files a claim, you need to respond to our request for documents and other information in a timely manner.
  • The item must be a physical, tangible good that can be shipped. Your primary residence, as listed in your PayPal account, must be in the United States.

With that being said, Paypal does offer reasonable protection for merchants selling tangible products who can meet Paypal’s requirements on a transaction. Once such requirement is proof of shipping, which essentially requires a signature from the actual person whom placed the order. Anyone who has ever shipped for a business knows that the person making the purchase is the same person that signs for the package about 1% of the time, and packages are usually left on a doorstep or with the first person with a pen. In many circumstances, this does not count as verified delivery.

So, while Paypal is by far the most used 3rd party processor, they also offer the least amount of seller protection, and have an uncountable number of negative experiences reported with their customer service, and policies. Paypal’s risk management also leaves something to be desired, and I would say it is inevitable for a merchant’s funds to be help at some point with Paypal. While this is unrelated to seller protection it is a huge pain to send the documents to Paypal and then hope to have your account reinstated. Since Paypal does very little to pre-qualify buyers or sellers, the account-hold situation will forever be an undesired Paypal feature.

Google Checkout

Google offer’s excellent chargeback and fraud protection, however merchants have very little control over buyer requirements. This isn’t necessarily a problem considering that the buyer’s country / location can be a requirement for purchasing through your company via Google Checkout. Google takes a very lenient stance on chargebacks and will rarely charge a merchant for a chargeback or fraud even if the merchant loses. Google as a company has a way of commoditizing products and services and their payment service is no exception. I’ve personally seen Google absorb chargeback costs for merchants, where a merchant account provider or paypal would have billed the merchant every time.

Google’s official policy is as follows:

Guaranteed Payment: Checkout’s Payment Guarantee protects 98% of Checkout orders on average — when an order is guaranteed, you get paid even if it results in a chargeback.

Free Protection: While merchants are typically charged for fraud protection services, Google’s comprehensive protection is free.

Lower Fraud Costs: Checkout’s fraud detection systems reduce fraud and manual review costs by proactively filtering out fraudulent orders.

More Sales: The same systems also help increase sales by identifying legitimate orders that you might otherwise mark as fraudulent.

Fair Treatment: Unlike other services that immediately deduct funds from you for chargebacks, Google does so only after a decision has been made as to who is at fault.

With moderate success, Google applies their typical do-no-evil attitude to the Google Checkout service.

Amazon Payments
Amazon offers protection similar to Google Checkout. Amazon’s official statement is:

If a seller follows the Amazon.com Community Rules when listing, selling and shipping their item and, can document shipment to the customer or that the buyer received the correct item, Amazon.com usually does not hold the seller responsible for the reimbursement of the claim. Otherwise, Amazon.com will usually debit the reimbursement for the claim from the seller’s account.

The gotcha here is again the “document shipment to the customer”. As with Paypal, it is very difficult to actually prove that the person placing the order received the package.

Amazon payments is still a newcomer to the payments business, and has positioned themselves somewhere between Google and Paypal. Something that neither Paypal or Google Checkout have, Amazon has the huge benefit of millions of active Amazon.com customers, many with years of history purchasing from Amazon. This pre-qualification goes a long way in reducing fraudulent orders and chargebacks. Going out on a limb, I think it’s fairly safe to say that accepting payments from Amazon is going to be safer than any other payment method because of this existing relationship.

As far as potential customer service blunders, one thing to be careful of here is Amazon customers expect a certain degree of service when it comes to product delivery and return/refunding orders. Amazon’s policies on these are far more lax than most online retailers, so there’s definitely the potential for conflict if a customer wants to return a product outside a business’s normal policies.

Non-tangible goods

There’s very few processors who handle payments for non-tangible goods like digital downloads, consulting, and other services very well, 3rd party processors are hardly an exception. This is because a customer can make a chargeback with their card issuer for a number of reasons that are virtually un-challengable. Chargebacks like “product not as described” are almost impossible to beat even with superb descriptions, disclaimers, and anything else merchants try to throw at their customers. Until Visa/MC/Amex issuers change their chargeback policies, it’s unlikely that merchants will receive any relief from these types of chargebacks for non-tangible goods and services where the accuracy of the description is easily interpretable. Amazon is currently making the most public push to cater to digital sellers, and of the 3 they offer the most options and protection for this type of service.

Integration

Integration is likely an afterthought for the business owners, but is the most important feature for a developer. All 3 providers offer integrations ranging from simple to advanced allowing developers to create unique and completely customized checkout systems. The most simple integrations require only pasting HTML into an existing website, while the advanced methods use API (Application programming interface) which allows for a seamless connection from an existing website to the processor. API’s allow for passing information like shipping and tax, in addition to a number of other data possibilities, directly to and from the website’s shopping cart.

Paypal

Paypal is probably the easiest to integrate with. There are literally thousands of scripts online, and just about every shopping cart software is ready to go with Paypal out of the box. Paypal offers several methods of integration.

  • Website Payment Standard (HTML buttons to place on a website or blog)
  • Express Checkout or Website Payment Pro (API integration for simple and advanced payments on an existing shopping cart)
  • PayPal payment gateway (ex-Verisign’s Payflow gateway)

The most simple Paypal integration is the buy now buttons that almost anyone could paste in their website to allow a customer to purchase an item from them.

Most website owners would want to use the express checkout or payments pro integration methods. These offer the cleanest user experience. I personally recommend the express checkout method of integration. Your customers start and end on your website, offering the best opportunity for the customer to complete a purchase and the least confusing checkout method possible. The API integration methods allow for uploading shipping and shopping cart information directly into Paypal, and offers support for calculating shipping and tax if the customer changes their address while on Paypal’s website. While the information and code samples that Paypal provides are severely lacking in documentation and organization, the pre-made scripts are a good start for many to get some of the more advanced checkout features going. My personal opinion on the pre-made scripts is that the code is grossly overdone, good programmers or those with a large number of website visitors, should really look into writing their own code to save system resources and reduce complexity.

The Paypal gateway is the former Verisign Payflow link and pro payment gateways. Using these requires a merchant to sign up for a more traditional merchant account through paypal. A merchant still needs to use one of the other integration methods to accept direct paypal payments from their customers.

Recently Paypal has been making huge advancements in developing their integration platforms. Developers are beginning to gain access to systems allowing for aggregation, mobile payments, and a variety of other advanced payment resources. Paypal is pushing the front-line of web and mobile payment development and is desperately trying to get developers to buy into their platform, which in my opinion is working.

Google Checkout

Google also offers several methods of integration from the most simple paste in scripts to very advanced API functions. Google also offers email invoicing, and the Google checkout shopping cart, through their administration panel.

Google’s most basic integration is the Checkout Store Gadget and buy now buttons,which allow website owners to visually create products and buy now buttons and then past them into their website. Multiple options can be added to a product and once clicked on the buyer can quickly make a purchase through the Google checkout system. The store gadgets are a great way to add a few products to a website, but if a store owner has an existing website or a full catalog of products, they’ll want to use one of the more advanced integration methods.

Google’s API offers advanced shopping cart integration and many features to streamline the purchasing process. Google also provides a number of well designed integration scripts in just about every language to get programmers off to a quick start. The API supports fully uploading a customer’s shopping cart items and descriptions, and allows for custom shipping and tax calculations, sales, discounts, coupons and just about anything else a website owner can come up with. Google Checkout is a moderately difficult service to integrate with, but the pre-made scripts are great and most medium level programmers shouldn’t have too much trouble once familiar with Google’s API.

Once a user is setup with a Google checkout account, it takes about 2 clicks total to make subsequent purchases. This is very important to help sales, as 3rd party checkout systems offer a mixed bag of conversion rates compared to an on-site checkout.

Amazon Payments

Amazon offers several methods of integration again ranging from simple paste-in code, to the most advanced API integration.

Amazon’s most simple method of integration is the Amazon Simple Pay, which is similar to Google and Paypal’s button creating features. Again like Paypal and Google, most website owners with more than a handful of products will want to use the more advanced integration methods.

Amazon’s API’s are very robust and offers a number of very advanced features. To list them all would be a post in itself, but they offer just about anything a business owner could want from pre and post transaction payments, variable amount donations, recurring payments, aggregation, 3rd party payments, credit card authorization and capturing, and all of the normal features a payment system would have. With the huge amount of features comes a the burden of trying to integrate Amazon’s system into a website, and I again stress that it is no easy task once a website moves past the basics.

The typical method that most merchants will want to use is Checkout by Amazon, which allows for a merchant to include shipping and tax information when their customer completes a purchase on Amazon’s checkout page. Checkout by Amazon will meet the needs of the majority or websites, and includes several sub-checkout methods for different situations, one allowing for a very quick conversion. The Amazon PayPhrase requires only that a customer enter their secret phrase on the checkout button, and the purchase is complete! Checkout by Amazon will not cater to developers with very special checkout needs, which is there Amazon’s most robust API comes into play, however 98% of website should be perfectly fine with Checkout by Amazon.

Amazon Flexible Payments represents the pinnacle of ecommerce payment technology at this point. Amazon Flexible Payments is also the obvious reason why Paypal has invested millions in their platform as it is truly a huge step ahead of anything out there. Amazon Flexible Payments allows for developers to create very complex payment mechanisms involving multiple parties and/or very flexible payment time-frames and parameters. Want to bill one customer, pay another and take a cut, Amazon Flexible Payments. Need to charge a customer a month after they download your software, Amazon Flexible Payments. If you can think it up, Amazon Flexible Payments can probably do it. However, with the huge set of features comes the difficulty in implementing them, and as stressed above is not an easy task. Amazon Flexible Payments is the most difficult payment system to integrate with, and is one of the more difficult API’s I’ve ever encountered. Amazon Flexible Payments supports only more advanced integration methods like SOAP (If you don’t know what this means, don’t worry, you don’t need to know). Realistically most beginning and even some intermediate and advanced level programmers will have a very difficult time integrating with many of Amazon’s more advanced services. The benefits for the right business are worth it, but most websites will be better suited with Checkout by Amazon.

Concluding thoughts

I cannot make a judgment on which 3rd party payment method is better because in the end it all comes down to your customers. Naturally you should use what your customers want to pay with, and for hopes of better conversion, it is a good idea to offer your customers alternate payment methods in case they do decide to use them. In the almost 10 years I’ve been running ecommerce websites, I can still honestly say that nothing beats straight credit card acceptance, through a payment gateway, at least for tangible products. Paypal makes a very strong statement if your business sells very-tech related products. If I were to pick 2 payment methods that I think every ecommerce website will benefit from, it would be direct credit card acceptance through a merchant account / payment gateway and Paypal. Just based on the usage, these 2 are absolutely essential. Google and Amazon have some amazing features, usability, and speed, but until more customers want to pay with them, they are still not on a comparable level.


April 26th, 2010 by Jamie Estep

Blippy is why Visa and MasterCard should protect their merchants

Filed in: Fraud, Industry News, Merchant Accounts | 4 comments

This last week, a social networking company Blippy, notified the world that at some point they suffered a small data breach involving a handful of their customer’s credit card numbers.

Blippy is a service that allows people to share and discus, the purchases that they are making in near real-time. Basically, every time a Blippy user makes a purchase using their credit card, it shows up on Blippy. A little bit like twitter, a user can also embed their blippy feed on their blog, facebook profile, other social network, or website, and their followers can track and discuss every purchase that they make. For this to work smoothly, Blippy obviously needs to store and access some very sensitive information.

This data breach looks like it was extremely small, completely insignificant for realistic purposes, but I think it brings up some very strong points that should question card issuers stance on protecting their card holders.

The reason that Visa and MasterCard should provide some sort of protection for merchants, is that if card holders are stupid enough to share their credit card and bank login information with a social networking site such as Blippy, there’s really no reason that they should be continue to be protected at the expense of merchants. It’s simply absurd to think that merchants should bear the cost of people so ignorant that they would give their banking information out to some random website. “Social networking” and “security” are 2 terms as synonymous as fire and water.

One could always argue that Blippy should have kept the information more secure, which is obvious, but the real problem here is that credit cards are not meant to be used in this manner. It’s just baffling to me that someone would actually enter their card or bank login into any site that they do not have a close relationship with, or are making a purchase from. Then to expect their bank to cover them from unauthorized charges, is just beyond any reason. It’s reckless on Blippy’s part to make a service based on and requiring such sensitive information, and it’s even more reckless for card holders to share this information.

A quick example of the absurdity of this service is a line in Blippy’s terms of service:

Privacy: You may not publish or post other people’s private and confidential information, such as credit card numbers, street address or Social Security/National Identity numbers, without their express authorization and permission.

Hey, but Blippy can publish yours…

To me, this service is clearly crossing the line where credit cards were not mean to and should not go until major modifications to security and merchant protection are established!

To top it all off, Blippy issued this statement on their blog:

In general, it’s important to remember that you’re never responsible if someone uses your credit card without your permission.

As a merchant and a merchant service provider, I don’t want to end up taking a stolen card because a card holder decided to hand out their banking information to a social networking site, who thinks that chargeback expenses are somehow covered by a magical chargeback fairy. It’s the merchant that accepted the card who eats the cost of your poor programming, and complete lack of data security. I think Visa and MasterCard need to step in right now and quash this type of service, and specifically Blippy. It’s really simple, as Blippy is not involved in any part of a credit card transaction, they have no right to a card holder’s transaction information.

Blippy has issued resolutions to prevent this from happening again, but realistically their service should be canned now! My hat goes out to anyone who can get a $12M investment in a service that lets people share their purchases with the world, but it’s time that this is stopped before it gets out of hand.


March 17th, 2010 by Jamie Estep

30 Second Fraud Checklist for Ecommerce Merchants

Filed in: Ecommerce, Fraud, Merchant Accounts | 10 comments

Credit card fraud and online ordering fraud has hampered ecommerce merchants since the first credit card payment was taken over the internet. Because fraud is still successful, and because there is virtually no way to go after someone you suspect of fraud, it is still a plague to website owners trying to run a business on the internet. Online fraud is especially troublesome to online retailers, because they end up losing twice, first when the merchandise they shipped is not recoverable, and second when the real cardholder makes a chargeback. Now they lose the merchandise and the money they would have collected for it. There are numerous fraud screening applications designed to help ecommerce merchants prevent accepting and shipping fraudulent orders. However, many ecommerce sites aren’t even covering the most basic of fraud screening principals.

Here is 10 items that should be checked on every order before shipping. If you do nothing else for fraud screening at least cover these basic principals to help prevent some of the more obvious fraud.

If any of these are true, it’s a good idea to further review the order, or contact the person making the purchase before shipping.

  1. Billing and Shipping Addresses Don’t Match
  2. Requesting Overnight Shipping
  3. Order is for Multiple Quantities of the Same Item
  4. Items Being Ordered are Mainly of High Value
  5. Order is for Uncommonly Purchased Items
  6. Different but Related Products Being Ordered
  7. AVS and/or CVV Verification Failed
  8. Customer Made Several Unsuccessfully Attempts Before the Transaction was Approved
  9. Customer’s phone number and/or email look unconventional
  10. Order is Being Shipped to Africa, Asia, or Eastern Europe

(more…)


February 11th, 2010 by Jamie Estep

Paypal’s India Fiasco

Filed in: 3rd Party Processors, Industry News | 6 comments

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.


February 3rd, 2010 by Jamie Estep

Chargeback tip – check your descriptor

Filed in: Chargeback Tips, Merchant Accounts | 2 comments

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.


January 21st, 2010 by Jamie Estep

You cannot require an ID for a Visa transaction???

Filed in: Fraud, Merchant Accounts | 9 comments

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.


January 15th, 2010 by Jamie Estep

Dear MSP

Filed in: Merchant Accounts |

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


December 22nd, 2009 by Jamie Estep

Surcharging customers using credit cards is illegal!

Filed in: Merchant Accounts | 7 comments

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.


October 30th, 2009 by Jamie Estep

Making sense of the PCI mess

Filed in: Merchant Accounts | 2 comments

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.

Hard disk on fireHow 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 »


October 29th, 2009 by Jamie Estep

How to re-bill your customer’s credit card, without storing it!

Filed in: Ecommerce, Merchant Accounts | 2 comments

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.