Since we entered private beta, one of the most requested features has been PayPal merchant services support. PayPal’s Website Payments products ease the pain of finding a gateway and merchant account, making it simple to start charging customer cards.
This week, we introduced support for PayPal Website Payments Pro in the United States. Next week, we will add support for PayPal accounts in Canada and the United Kingdom. We also plan to support PayPal Payflow Pro in the near future.
As a developer, I tend to like clean, concise URLs that map directly to my RESTful resources. Want to view a subscription?
GET /subscriptions/77
Want to edit it?
GET /subscriptions/77/edit
The URLs for Chargify hosted pages followed this convention. Updating credit card details loosely maps to editing the subscription to change the payment information. So, we had:
GET /h/subscriptions/77/edit/abcdef0123abcdef0123abcdef0123abcdef0123
With the ‘h’ part meaning our “hosted” namespace, and the gibberish at the end being a secret token.
Now, if I were a layperson, and IF I happened to glance at the URL for the page I was about to enter my credit card on, which one of the following would be more likely to give me warm fuzzies?
We’ve just released a new feature that allows you to add “components” to your products which your customers can purchase and be charged according to the quantity chosen. This is great for offering things like the following to your products:
What the heck are components?
We’ve built a new framework that is going to give you a lot of flexibility in defining your products, and we’re calling these “components”. If you think of the traditional “product matrix” you used to see on most websites selling a service, you would usually see their plans (or products) in the columns and row after row of optional and included things. Well, in Chargify these “things” are called “components” - they are the building blocks of your products that you use to add options, upgrades, and add-ons to enhance your offerings.
The following simplified graphic shows what I’m talking about.
In 2010, any company that receives a substantial number of credit card orders faces a grave threat: chargebacks. For those unaware, a chargeback is when a customer reverses an order they made from you and then gets their money back. Originally, chargebacks were created to protect consumers from unscrupulous merchants. Rather than endlessly arguing about unauthorized charges, customers could simply initiate the chargeback and be done with it.
Unfortunately, the ease of initiating a chargeback has created a class of unscrupulous consumers. Increasingly, consumers who have not been wronged in any demonstrable way are using chargebacks heedlessly. Other chargebacks arise from innocent clerical errors. All chargebacks, no matter the source, have the potential to wreak havoc on the cash flow of card-accepting businesses. Below, we’ll explore several ways that companies can protect themselves from chargebacks.
Know Each “Reason Code”
While chargebacks are designed to be easy and automatic for consumers, they cannot simply be executed without reason. Rather, there are four separate “reason codes”, one of which customers must state to their credit card issuer and which they, in turn, are required to provide the merchant.
Venture capitalist Paul Graham expressed an under-appreciated nugget of wisdom in his article on mistakes that kill startups. Unlike “winning an Olympic gold medal, where the problem is well defined”, building a successful company is actually “more like science, where you need to follow the trail wherever it leads.”
Therefore, Graham concludes that the worst person to run a startup is someone who “has some great idea they know everyone is going to love, and that’s what they’re going to build, no matter what.” But while plenty has been written about successful startups in general, little has been said about companies that thrived by changing their strategies instead of clinging to those they started with.
Below, Chargify examines six companies whose flexibility took them to new heights.
PayPal
PayPal, believe it or not, was not founded to be the online payment service that it is today. In her book Founders at Work, Jessica Livingston interviews PayPal founder Max Levchin. During the interview, Levchin reveals that PayPal was originally envisioned as a cryptography company, and then later as a means of transmitting money via PDAs. Only after several years of trial and error (and overcoming user fraud that almost destroyed the company) did PayPal find its sweet spot as the default online payment system of millions.
