A lot of companies claim to be "the" leading provider in this or that. This is a common issue in the payment processing and infrastructure realms. Of course, rarely is there one true "the" and of course you can immediately tell the difference between a start-up claiming "the" and a public company which has to actually defend their claims and therefore more often saying they are "a" leader.
Personally I have always argued for the more mature stance at the various start-ups that I have worked for claiming "a" leadership role in the various realms. Actually nothing is more satisfying than being "the" and everyone actually knows it but you do not have to claim it.
Credibility, quality, execution, etc. really do matter.
So, my advice is to question anyone that claims to be "the" leader in their realm. If they are stretching the truth about that, what else are they stretching?
Wednesday, June 17, 2009
Wednesday, June 10, 2009
Bill Payment +/-
This post is from a user's perspective rather than a provider's perspective. I use both my bank's bill payment service and I have enrolled in a variety of merchant direct bill payment programs. I use the bank approach mostly for the gardner, dentist, etc. I use the merchant approach for my wireless, water, gas&electric, etc.
It surprises me that there is so much inconsistency in the way the "biller direct" models work. I have also signed up for paperless statementing from most of my providers. Regardless of how I get notified that a bill is pending, some statements include the dollar amount and the date that the payment will be processed and others make you log-in to get one or both of those pieces of information.
I am sure that some very smart and well meaning programmers/product managers had good reasons for their individual approach to this, perhaps security concerns about email exposures, and/or the information they needed to populate the fields was not easily available.
It would seem to me that some studying of the Best practices in this area could help to further the adoption of these great programs since consistency is key to massive adoption and reduced costs for customer service.
I personally prefer that I be reminded of three key pieces; How Much, When, What Account (Credit Card or Checking) is going to be hit without me having to log in and probe for that info.
It surprises me that there is so much inconsistency in the way the "biller direct" models work. I have also signed up for paperless statementing from most of my providers. Regardless of how I get notified that a bill is pending, some statements include the dollar amount and the date that the payment will be processed and others make you log-in to get one or both of those pieces of information.
I am sure that some very smart and well meaning programmers/product managers had good reasons for their individual approach to this, perhaps security concerns about email exposures, and/or the information they needed to populate the fields was not easily available.
It would seem to me that some studying of the Best practices in this area could help to further the adoption of these great programs since consistency is key to massive adoption and reduced costs for customer service.
I personally prefer that I be reminded of three key pieces; How Much, When, What Account (Credit Card or Checking) is going to be hit without me having to log in and probe for that info.
PCI DSS (Payment Card Industry - Data Security Standard)
Much has been and will be written about this program. Like a lot of other aspects of the payments industry, there seems to be an endless supply of confusion on this topic. To be fair, it is a somewhat complicated topic. There are so many layers in the eco-system that can touch and/or store cardholder information and there are multitudes of ways that merchants implement their payment systems. During a recent discussion with a merchant client of ours and one of the qualified assessors, the assessor acknowledged that the program was designed for the common mainstream models, both ecommerce and retail, and that this particular merchant's situation did not easily fit. Nonetheless, this merchant, who could also be characterized as a quasi-service provider was faced with a complicated dilemma.
While a lot of progress has been made on key aspects of PCI such as the consolidation of requirements across payment brands, there is no end in sight for a simple PCI for Dummies tomb that will answer all the questions.
Another relevent point for ecommerce merchants to consider is the +/- of allowing your gateway to handle PCI for you through what is called Tokenization and/or a fully hosted order page. In both cases, while the appeal of avoiding PCI is tempting, it is important to make sure that your contract gives you the ability to get your data back if you end up deciding to switch vendors or take the process back in-house. Otherwise, those of you with 1-Click shopping or subscription payments will place your business at serious risk.
p.s. Having been involved in both retail and ecommerce payment infrastructure for close to 30 years, it never ceased to amaze me how much focus was placed on the fear of compromises coming from the Internet channel and little to no concern or governance was focused on retail until pretty recently. At least in the Internet, with the standardization around SSL, the one part of the threat around transport security was pretty well covered. Things really started getting crazy when retail terminals started being switched from communicating over private lines (dial or leased) to using the Internet for transport and neither the terminals or the applications running in them were architected from a security perspective.
While a lot of progress has been made on key aspects of PCI such as the consolidation of requirements across payment brands, there is no end in sight for a simple PCI for Dummies tomb that will answer all the questions.
Another relevent point for ecommerce merchants to consider is the +/- of allowing your gateway to handle PCI for you through what is called Tokenization and/or a fully hosted order page. In both cases, while the appeal of avoiding PCI is tempting, it is important to make sure that your contract gives you the ability to get your data back if you end up deciding to switch vendors or take the process back in-house. Otherwise, those of you with 1-Click shopping or subscription payments will place your business at serious risk.
p.s. Having been involved in both retail and ecommerce payment infrastructure for close to 30 years, it never ceased to amaze me how much focus was placed on the fear of compromises coming from the Internet channel and little to no concern or governance was focused on retail until pretty recently. At least in the Internet, with the standardization around SSL, the one part of the threat around transport security was pretty well covered. Things really started getting crazy when retail terminals started being switched from communicating over private lines (dial or leased) to using the Internet for transport and neither the terminals or the applications running in them were architected from a security perspective.
Wednesday, May 13, 2009
Who needs a Gateway?
I have gotten this question frequently in recent months so I thought I would take a stab at answering it here. I worked at CyberCash which was the very first Internet payment gateway. (p.s. This was a very exciting time and I still have the receipt from my first transaction at Virtual Vinyards!!) The purpose for a gateway at that time was very clear. The only way to connect to your payment processor was through a dial-up or dedicated communication line known as a leased line. CyberCash acted as the protocol converter by enabling merchants to connect to us via IP and we translated that into the communications protocols that the processors were capable of supporting over leased lines out the other side of our systems. For the various start up companies that were pioneering selling over the Internet, the concept of not being able to use the Internet to connect to the processors was ridiculous and therefore a new business was launched. During the lead up to the bubble (& ultimate burst), new payment gateways came out of the woodwork on almost a daily basis. Eventually, as with most similar situations, there were too many and most are now gone. Eventually (about 5 years went by), the various payment processors began adding their own IP gateways and now all of the major payment processors have their own. Of course, the few remaining independent gateway providers were not standing still during these years. They added a variety of value added services to differentiate themselves such as fraud screening, sale tax calculation, alternative payment types, international payment support, FX capabilities, PCI compliance, etc... In today's market, often (as with Vindicia) the gateway function is there simply as a means to an end (delivering a comprehensive value added subscription billing and chargeback management service) rather than the defining capability. The other major reasons to use an independent third party is the fact that no one payment processor has everything a merchant typically needs and since most companies that have embedded gateway capabilities connect to multiple payment processors the merchant is empowered to switch (or as is sometimes necessary connect to multiple processors simultaneously) much more easily if for whatever reason their needs change.
Tuesday, April 28, 2009
Enrollment - the kiss of death for a new payment method
Tonite I was reading about one of the newest alternative payment players, Moneta and as is my calling, I decided to check it out. I went to the site and although they only have a few merchants functioning, one being Delta Air, I went ahead and enrolled. It was easy enough, the website was well designed, etc. (Note to them - one lame thing is the password challenge questions - they ask you to identify your favorite ____________ which is a bad idea since people's favorites change all the time. Alas, this is a very common mistake.) However, it is not an instantaneous process. They are going to deposit a few small transactions in my checking account which will take 1-2 days and then I am going to have come back and go through a verification process. This is a sound, but not particulary convenient method, to verify that I actually own this checking account.
If I was not a payment geek, I doubt I would go through this effort to enroll, remember yet another username/password and then what is the likelyhood that I will remember to use this method at some point in the future. Delta Air already has my credit card on file and they actively promote their own co-branded American Express card. And, what about my miles/cash back, etc.? Consumers that are concerned about not building up add'l debt can simply use their Visa/MasterCard branded Debit card. And, unless Amazon embraces it (which is unlikely), they are toast.
The inertia any of these new payment methods have to overcome is huge and a multi-step/multi-day enrollment method is one of the many speed bumps. But, with BillmeLater getting acquired for almost $1B by eBay, there will be no shortage of folks trying. One of the beauties of BillMeLater was they figured out how to move the enrollment to the back end, after you already made your purchase. That was brilliant.
If I was not a payment geek, I doubt I would go through this effort to enroll, remember yet another username/password and then what is the likelyhood that I will remember to use this method at some point in the future. Delta Air already has my credit card on file and they actively promote their own co-branded American Express card. And, what about my miles/cash back, etc.? Consumers that are concerned about not building up add'l debt can simply use their Visa/MasterCard branded Debit card. And, unless Amazon embraces it (which is unlikely), they are toast.
The inertia any of these new payment methods have to overcome is huge and a multi-step/multi-day enrollment method is one of the many speed bumps. But, with BillmeLater getting acquired for almost $1B by eBay, there will be no shortage of folks trying. One of the beauties of BillMeLater was they figured out how to move the enrollment to the back end, after you already made your purchase. That was brilliant.
Saturday, April 18, 2009
Alternative Payment Defined
So what is an alternative payment? Do e-wallets qualify? There are various projections out there that say "alternative payments" will represent n% of all ecommerce payments by "n" date by such well respected research firms such as Javelin Strategy. Unless we define the term, these projections can easily be mis-understood and overstate the actual change underway. Some seem to believe that any payment where the consumer does not directly enter their credit/debit card number into the check-out form qualifies as an "alternative payment". In my opinion, Google Checkout, for example, is not an alternative payment. PayPal transactions that are funded by a Credit Card are not an "alternative payment". BillMeLater and eBillMe are clearly alternative payment. Taking Google Checkout and Credit/Debit card funded PayPal transactions out of the projections would reduce them dramatically.
What do you think?
What do you think?
Thursday, April 9, 2009
What is a micropayment?
The answer - it depends on who you ask.
My definition is - a payment of $1.00 or less.
I would like to propose a new term (just what we need, right!) - Minipayment.
What is a minipayment? My definition is - a payment of between $1.01 and $5.00.
Then we would have a plain old "payment" which I would define as anything above $5.00.
There has been a lot of attempts to solve the micropayment problem. They go by the names; Digicash, CyberCash, MagnaCash, PepperCoin (all dead and gone) and the latest incarnations; SpareChange, PayByCash, etc. PayPal has toyed around in this area as well but without much success.
The problem is that if the consumer pays by Credit or Signature Debit (see earlier post), the cost of the transaction includes a flat fee of ~.20-.30 plus some % of ~2%. On a $5 transaction run through PayPal's (& now Google Checkout's) standard pricing, the fee works out to be 9%.
The "solution" has been to have the customer fund a larger amount, say $20 (works out to a 4.5% fee if a typical SMB merchant is using PayPal/Google Checkout). The problem with this are; a) the % of consumers willing to commit that larger amount on the hope that they will use it at one or more merchants that support it, b) the economics for the provider and the merchant of providing customer service around these very low value payments and c) for the credit card companies, the % of these transactions that result in disputes at a very high cost. Other solutions are individual game currency, pre-paid cards, mobile payments but each of these have a variety of issues whether it is; utility, accessibility, cost, fraud, etc.
I do not have a magic bullet for this one, I know too much about how all this works and therefore the challenges. I am always intrigued to observe the volume of noise on this issue and the amount of VC money that finds it way to the latest attempt.
p.s. The biggest challenge is not any particular technical issue. If the credit card companies or PayPal wanted to offer a viable solution, they could. It is the Incumbent's Dilemma in spades, however, since in order to price a micropayment service in the realm of what the merchant would desire, it would undermine the pricing models for the higher value payments since the fact is, it costs about the same to process a $1.00 transaction as a $100.00 transaction and at the volumes the big guys are processing, that incremental cost for the next transaction is pretty low. The other guys that are trying to solve it are faced with all the chicken & egg start-up costs whereas the incumbents are already at scale.
Feeback welcome!
My definition is - a payment of $1.00 or less.
I would like to propose a new term (just what we need, right!) - Minipayment.
What is a minipayment? My definition is - a payment of between $1.01 and $5.00.
Then we would have a plain old "payment" which I would define as anything above $5.00.
There has been a lot of attempts to solve the micropayment problem. They go by the names; Digicash, CyberCash, MagnaCash, PepperCoin (all dead and gone) and the latest incarnations; SpareChange, PayByCash, etc. PayPal has toyed around in this area as well but without much success.
The problem is that if the consumer pays by Credit or Signature Debit (see earlier post), the cost of the transaction includes a flat fee of ~.20-.30 plus some % of ~2%. On a $5 transaction run through PayPal's (& now Google Checkout's) standard pricing, the fee works out to be 9%.
The "solution" has been to have the customer fund a larger amount, say $20 (works out to a 4.5% fee if a typical SMB merchant is using PayPal/Google Checkout). The problem with this are; a) the % of consumers willing to commit that larger amount on the hope that they will use it at one or more merchants that support it, b) the economics for the provider and the merchant of providing customer service around these very low value payments and c) for the credit card companies, the % of these transactions that result in disputes at a very high cost. Other solutions are individual game currency, pre-paid cards, mobile payments but each of these have a variety of issues whether it is; utility, accessibility, cost, fraud, etc.
I do not have a magic bullet for this one, I know too much about how all this works and therefore the challenges. I am always intrigued to observe the volume of noise on this issue and the amount of VC money that finds it way to the latest attempt.
p.s. The biggest challenge is not any particular technical issue. If the credit card companies or PayPal wanted to offer a viable solution, they could. It is the Incumbent's Dilemma in spades, however, since in order to price a micropayment service in the realm of what the merchant would desire, it would undermine the pricing models for the higher value payments since the fact is, it costs about the same to process a $1.00 transaction as a $100.00 transaction and at the volumes the big guys are processing, that incremental cost for the next transaction is pretty low. The other guys that are trying to solve it are faced with all the chicken & egg start-up costs whereas the incumbents are already at scale.
Feeback welcome!
Subscribe to:
Posts (Atom)
