Sundar's Musings

i like to observe how we use software. Then I try to use these observations to make better software.

In dimdim.com a major portion of our revenue was from online subscription business where users could signup for monthly or annual plans by giving us their credit card once and we would bill them every month or year. Users could upgrade from monthly to annual plans as well as upgrade form a lower to higher plan, for example from a pro 50 to pro 100 or webinar account. We used to take care of pro-rata billing so that users never over paid us. We also provided discount coupons which could operate over only the first billing cycle (monthly or annual) or over all billing cycles. We also created what we called as one-click URLs where if a user has already become a paid user, then through a single click upgrade to a higher product SKU was possible.

We did not store the credit card on file on our hardware and all of the transactions was done through Paypal’s payflow APIs. We never had access to credit card information. We had situations where the user credit card transactions would go through fine for few months and then suddenly they would get declined. Some times this was due to the credit card expiry, or change in billing address of the credit card or some other similar reason. Sometimes this was due to the credit card limit getting reached. We had an algorithmic approach to re-trying such transactions to maximise the renewal successes while at the same time minimizing the fees we would have to pay for each renewal re-try irrespective of weather its an success or failure. 

Initially we were reluctant to build the backend systems to support all this. We tried various options like X-Cart, Chargify, Recurly and Zuora. But we didnt find any solution flexible enough to support our needs. For example Zuora could not do (at least at that time) the renewal re-try logic as our algorithms suggested. We even tried multiple payment processors. The re-try algorithms got pretty fancy as we kept tweaking them to give better results. For example, we found out that if a renewal failure happens we should immediately inform the user abt the transaction not going through but not suspend the account but re-try the renewal transaction on the 3rd, 5th, 7th, 21st day after first renewal transaction. This we found out by talking with folks in a  similar position as us in telco/utility companies like AT&T and other subscription businesses like netflix.com, yousendit.com, box.net. They had also faced similar issues and typically through trial and error found out the ways to make this work.  

There was lots of “black magic” here. Lots of undocumented things which even people inside the credit card processing industry were not privy to. This was auto-subscription business and viewed very differently from normal online credit card processing. For example lets say i have a customer whose credit card is expiring on march 15th. S/he signs up for the service using that credit card on Jan 1st. Lets assume the signup goes correctly. So payment for jan is done. Renewal succeeds on Feb 1st and March 1st. But on April 15th (if the credit card details are not updated) the renewal attempt would fail. If we stop re-trying the renewal failure we have lost the customer. If we keep re-trying the renewal there is a high possibility that on May 15th the transaction will go through even if the expiry date still says March 15th (especially for Visa and master cards). It seems the authorizing banks depending on the risk profile of the merchant (and the customer) allow renewal transactions on credentials presented with expired dates if the user has been sent new card with extended expired date (typically done over post) and s/he has used it some where else. But if we have above a certain percentage of attempted transactions (typically 2.5%) as failures we as a merchant run the rist of being flagged as a higher risk category merchant (which is not at all good).

Even with these ways of capturing the renewal failures we would still miss some customers who ended up getting renewal failures even if they wanted to renew. Manually calling them up was the only thing to do even if it was the last resort. These renewal failures would result in decreased customer life time value. For a nuanced view of how customer LTV value gets affected due to renewal rate or retention rate can be found here

We also had several interesting “sand in the machine” kind of situations. Suddenly one day we found out that one of the major card vendors (one of Visa/master/amex/discover) was no longer being supported by our payment processor. This happened without any kind of warning. By the time we fond out this was happening we had lots of users being rejected by the system and these were all customer lost because we were not able to accept their credit cards! We lost hundreds of transactions in those couple of hours. Finally when we were able to navigate through the phone tree and reach a human we found out that the vendor wanted updated office information about our company and we had moved 3 months ago to bigger office space. Eventually we had to supple documents proving many things to them including company confidential financial documentation before they started accepting the transactions. Later on through investigation of the root cause of this issue we found out that our merchant rating was not the correct one to the business we were doing. Once we corrected our merchant categorization this problem was solved. (real reason for this issue: many “adult” companies do online subscription business :-)).

You can find the rest of the series here:

Adventures in online subscription business : Part 2

  1. ssundar posted this