<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Recurly Blog &#187; Billing</title>
	<atom:link href="http://blog.recurly.com/category/billing/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.recurly.com</link>
	<description>Super Simple Subscriptions</description>
	<lastBuildDate>Tue, 31 Aug 2010 17:00:58 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<atom:link rel='hub' href='http://blog.recurly.com/?pushpress=hub'/>
		<item>
		<title>Top Ten Reasons to Use Recurly vs. PayPal Subscription API</title>
		<link>http://blog.recurly.com/2010/08/top-ten-reasons-to-use-recurly-vs-paypal-for-recurring-billing/</link>
		<comments>http://blog.recurly.com/2010/08/top-ten-reasons-to-use-recurly-vs-paypal-for-recurring-billing/#comments</comments>
		<pubDate>Fri, 20 Aug 2010 00:02:47 +0000</pubDate>
		<dc:creator>Dan Burkhart</dc:creator>
				<category><![CDATA[Billing]]></category>
		<category><![CDATA[Payment Gateway]]></category>
		<category><![CDATA[Recurly]]></category>
		<category><![CDATA[Subscriptions]]></category>
		<category><![CDATA[gateway]]></category>
		<category><![CDATA[paypal]]></category>
		<category><![CDATA[recurring]]></category>

		<guid isPermaLink="false">http://blog.recurly.com/?p=350</guid>
		<description><![CDATA[The short answer is: Flexibility and Total Cost Of Ownership We’re glad you asked &#8211; because this could save you many hours of development, and many curse words before learning the hard way – on your own precious company’s dime. Every payment gateway is designed to handle one-time transactions. Some gateways like PayPal and Authorize.Net  [...]]]></description>
			<content:encoded><![CDATA[<h2><strong><span style="font-weight: normal;color: #333333;">The short answer is:</span> Flexibility and Total Cost Of Ownership</strong></h2>
<p>We’re glad you asked &#8211; because this could save you many hours of development, and many curse words before learning the hard way – on your own precious company’s dime.</p>
<p>Every payment gateway is designed to handle one-time transactions. Some gateways like PayPal and Authorize.Net  offer recurring billing or subscription billing functionality, and while they generally work for simple recurring billing integrations, we’d like to explain what you should expect to receive by signing up with Recurly rather than integrating directly with your payment gateway.</p>
<p>Recurly is designed as a complete billing system for recurring billing. This means that we have put careful thought and consideration into the most common pain-points experienced by business owners handling the day-to-day billing and related customer support issues that can come along with subscription billing.<span id="more-350"></span></p>
<p><strong>Consider this</strong> &#8211; Unlike payment gateway solutions, Recurly lets you handle all of the following scenarios elegantly:</p>
<ol>
<li>Customers upgrade and downgrade between plans easily – Recurly handles proration and customer communications</li>
<li>Billing cycle changes (e.g. customer signs up for monthly plan and elects to change to yearly plan)</li>
<li>Easily issue customer credits towards future service</li>
<li>Create email invoices</li>
<li>Easily process refunds</li>
<li>Process one-time transactions</li>
<li>Customizable hosted payment pages for customers to subscribe &amp; update their billing info</li>
<li>Provide billing support with an account management console for your customer support</li>
<li>Easily change payment gateways without any business interruption. Recurly stores your data safely and securely.</li>
<li>Keep your own systems easily in sync with secure XML notifications and/or emails.</li>
</ol>
<h2>Things To Consider Before Building Homegrown Billing Solution</h2>
<p>Here are some common pitfalls when estimating the work required to build your own solution:</p>
<h2>Customer Upgrades and Downgrades</h2>
<p>Most businesses prefer to offer multiple subscription plans. It’s good practice to create a ‘migration path’ from an easy, no risk trial to the plan with the plan with the maximum expected lifetime value. This is great business practice, but the billing intricacies are non-trivial.</p>
<p>Let’s start with proration, it means prorating the current month&#8217;s charge against the current payment &#8212; this can get complicated quickly once you also factor in trial periods. If your customers decide it&#8217;s too much and want to downgrade, you might want to wait until the end of the current billing cycle &#8212; now you&#8217;re tracking state. These simple tasks can take months to build on your own; Recurly gracefully handles these situations with a single API call.</p>
<h2>Failed Payments</h2>
<p>Recurring billing APIs typically leave you in the dark when a payment fails. On average, 5-10% of your payments will fail every month due to changed credit card numbers, expiration dates, and accounts overdrawn.  (The longer the billing cycle, the higher the failure rate.) As part of offering a subscription service, you need to follow up with these subscribers to keep their billing information accurate. Recurly makes it easy to follow up with your past due accounts and gracefully collect their new billing info which eliminates costly customer service overhead.</p>
<h2>Account Management</h2>
<p>Subscriptions come with customer support requirements. This is a commonly underestimated cost, and Recurly makes it much easier for your company to manage without building out expensive custom solutions. Your customer service dept. can view subscription information, issue credits &amp; refunds, and more. Any change made in Recurly will be pushed back to your web application with our Push Notifications and REST API.</p>
<h2>Employee Retention</h2>
<p>We like the business we’re in, but we’ve never claimed that billing is sexy.  It turns out that many of our customers have come to us AFTER having built homegrown subscription billing solutions. Beyond the expected engineering and customer service challenges outlined above, the net effect on an organization is low employee retention. Engineers typically want to work on the company’s core product. After spending 3-6 months in the “billing department”, many engineers naturally seek new employment.<br />
When you outsource your subscription billing to Recurly, you’ll dramatically reduce your total cost of ownership related to each of these areas.</p>
<ul>
<li>Engineering Development Time</li>
<li>Ongoing Engineering Management and Maintenance</li>
<li>Customer Service and Support</li>
<li>Recruiting and Training to get new (replacement) employees up to speed.</li>
</ul>
<h2><a title="Recurly Sign-Up" href="https://app.recurly.com/signup">Sign up for Recurly</a>.</h2>
<p>It’s free to sign-up, and priced to pay-as-you-go. Your business will thank you.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.recurly.com/2010/08/top-ten-reasons-to-use-recurly-vs-paypal-for-recurring-billing/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Don&#8217;t bill all your customers on the first of the month</title>
		<link>http://blog.recurly.com/2010/04/dont-bill-all-your-customers-on-the-first-of-the-month/</link>
		<comments>http://blog.recurly.com/2010/04/dont-bill-all-your-customers-on-the-first-of-the-month/#comments</comments>
		<pubDate>Thu, 01 Apr 2010 17:44:20 +0000</pubDate>
		<dc:creator>Isaac Hall</dc:creator>
				<category><![CDATA[Billing]]></category>
		<category><![CDATA[Subscriptions]]></category>
		<category><![CDATA[accountants]]></category>
		<category><![CDATA[invoice]]></category>
		<category><![CDATA[prorate]]></category>
		<category><![CDATA[simple]]></category>

		<guid isPermaLink="false">http://blog.recurly.com/?p=196</guid>
		<description><![CDATA[Every so often I hear about a company that wants to bill all their subscribers on the first of the month.  Sure, a lot of companies bill on the first of the month.  This has its roots in the old school manual invoicing days of yore.  In the digital age, there's almost no excuse to invoice on the first of every month.]]></description>
			<content:encoded><![CDATA[<p>Every so often I hear about a company that wants to bill all their subscribers on the first of the month.  Sure, a lot of companies bill on the first of the month.  This has its roots in the old school manual invoicing days of yore.  In the digital age, there&#8217;s almost no reason to invoice on the first of every month.</p>
<p>Ask an accountant if they like to see a steady stream of revenue coming in every single day, or if they prefer giant monthly lump sums.  The answer is that a constant revenue stream is much better for cash flow.  From the user&#8217;s perspective, they would rather see round numbers like $99 on their credit card statement instead of prorated charges like $54.16 that look unfamiliar.</p>
<p>What happens if the user decides to cancel in the first month of service?  If you prorate your monthly dues and the user decides not to renew before the month is up, you&#8217;ve lost some additional revenue that the subscriber already agreed to pay because you did not charge for the full term.</p>
<p>From the developer&#8217;s perspective, it&#8217;s also much easier to deal with whole subscription terms than it is to worry about the shortened, pro-rated term lengths.  At Recurly, we are very big fans of reducing the complexity for programmers &#8212; they should be focused on developing your service, not on edge cases of subscription billing.</p>
<p>But what about services doing usage-based, or metered, billing?  The usage counter would traditionally be reset at the first of every month, hence the need to prorate to first month.  Instead, what if the usage counter was simply reset when the subscription renewed?  Bingo, problem solved.</p>
<p>So make your accountants, developers, and subscribers happy&#8230; keep it simple and forget about billing everyone on the first of the month.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.recurly.com/2010/04/dont-bill-all-your-customers-on-the-first-of-the-month/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>When to collect credit card numbers</title>
		<link>http://blog.recurly.com/2010/03/when-to-collect-credit-card-numbers/</link>
		<comments>http://blog.recurly.com/2010/03/when-to-collect-credit-card-numbers/#comments</comments>
		<pubDate>Sun, 28 Mar 2010 17:00:10 +0000</pubDate>
		<dc:creator>Isaac Hall</dc:creator>
				<category><![CDATA[Billing]]></category>
		<category><![CDATA[Subscriptions]]></category>
		<category><![CDATA[conversion]]></category>
		<category><![CDATA[credit card]]></category>
		<category><![CDATA[freemium]]></category>
		<category><![CDATA[trial]]></category>

		<guid isPermaLink="false">http://blog.recurly.com/?p=236</guid>
		<description><![CDATA[This question recently came up at the Freemium Summit on a pricing panel where I spoke; if you are offering a trial or a freemium service, when should you ask your users for a credit card number?  Asking for a credit card number is a significant hurdle for most people.]]></description>
			<content:encoded><![CDATA[<p>This question recently came up at the Freemium Summit on a pricing panel where I spoke; if you are offering a trial or a freemium service, when should you ask your users for a credit card number?</p>
<p>Asking for a credit card number is a significant hurdle for most people.  High fall off rates are to be expected.  But once someone gives you a card number and starts a trial, they are more likely to convert to a paid subscriber at the end of the trial.  So, if you are optimizing for your conversion numbers from trial to paid, then collect the credit card at the beginning of the trial.</p>
<p>If you offer a trial period and require your users to upgrade before the end of the trial, you will get more people in the door and trying your service.  However, it&#8217;s very difficult to get someone to come back before the end of the trial to enter their card number.  At least the number of total users will be much higher; use this as an opportunity to collect more feedback from your free users, especially the ones that declined to upgrade.</p>
<p>If you are able to offer your users an indefinite, free version, then you can wait to collect the credit card number when the user is ready to upgrade and convert to a paid subscriber.  You benefit from getting the most people in the door and will have the most opportunities to ask the user to consider upgrading.</p>
<p>At the end of the day, you need to factor in the costs associated with the free trial, the viral-ity of your product, and the likeliness of a conversion when deciding when to collect their credit card number.  You&#8217;ll get the highest retention rate when you can reach the customer the most (while providing value, not annoyance).</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.recurly.com/2010/03/when-to-collect-credit-card-numbers/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>How to maximize your yearly subscription renewals</title>
		<link>http://blog.recurly.com/2010/01/how-to-maximize-your-yearly-subscription-renewals/</link>
		<comments>http://blog.recurly.com/2010/01/how-to-maximize-your-yearly-subscription-renewals/#comments</comments>
		<pubDate>Fri, 29 Jan 2010 17:30:36 +0000</pubDate>
		<dc:creator>Isaac Hall</dc:creator>
				<category><![CDATA[Billing]]></category>
		<category><![CDATA[Subscriptions]]></category>
		<category><![CDATA[email]]></category>
		<category><![CDATA[reminders]]></category>
		<category><![CDATA[retention rate]]></category>
		<category><![CDATA[yearly subscription]]></category>

		<guid isPermaLink="false">http://blog.recurly.com/?p=121</guid>
		<description><![CDATA[This past week, I've heard from multiple customers who offer yearly subscriptions.  They took the easy route and implemented it with one time transactions -- in other words, the subscription is valid for a year and then never renews.  When they find out about Recurly, sometimes they want to simulate that behavior and not have the subscription renew because that's what their customers are used to. While Recurly can do that, there's a better way to maximize your retention rate and still keep your customers happy.]]></description>
			<content:encoded><![CDATA[<p>This past week, I&#8217;ve heard from multiple customers who offer yearly subscriptions.  They took the easy route and implemented it with one time transactions &#8212; in other words, the subscription is valid for a year and then never renews.  When they find out about Recurly, sometimes they want to simulate that behavior and not have the subscription renew because that&#8217;s what their customers are used to. While Recurly can do that, there&#8217;s a better way to maximize your renewal rate (or retention rate) and still keep your customers happy.</p>
<p>If your users forget about your service during the year and then they see the yearly renewal on their statement, they&#8217;re going to remember your service&#8230; and not in a good way.  Worse yet, they might want their money back.  That usually means they&#8217;ll ask you for a refund (and you should be willing to issue it if they really haven&#8217;t used the service) or they&#8217;ll attempt a charge-back (and that sucks for you and your bank account).</p>
<p>So right before the yearly subscription renews, remind your users two weeks ahead of time about the upcoming charge.  This gives them plenty of time to opt-out of the subscription.  It also gives you a chance to remind them of the value you provide so they will continue paying for the service.  It&#8217;s just that easy to keep everyone happy and make more money.</p>
<p>And yes, Recurly will be adding this feature before your yearly subscriptions get close to expiration.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.recurly.com/2010/01/how-to-maximize-your-yearly-subscription-renewals/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Lessons learned in online subscription billing</title>
		<link>http://blog.recurly.com/2010/01/lessons-learned-in-online-subscription-billing/</link>
		<comments>http://blog.recurly.com/2010/01/lessons-learned-in-online-subscription-billing/#comments</comments>
		<pubDate>Tue, 26 Jan 2010 19:35:32 +0000</pubDate>
		<dc:creator>Isaac Hall</dc:creator>
				<category><![CDATA[Billing]]></category>
		<category><![CDATA[Merchant Accounts]]></category>
		<category><![CDATA[address verification]]></category>
		<category><![CDATA[billing support]]></category>
		<category><![CDATA[card authorization]]></category>
		<category><![CDATA[credit card]]></category>
		<category><![CDATA[expiration dates]]></category>
		<category><![CDATA[merchant account]]></category>
		<category><![CDATA[payment gateway]]></category>
		<category><![CDATA[pricing]]></category>
		<category><![CDATA[subscription]]></category>

		<guid isPermaLink="false">http://blog.recurly.com/?p=89</guid>
		<description><![CDATA[Pivotal Labs recently invited Recurly to present a TechTalk to a room of developers. Developers are smart people and can quickly figure out how to run credit card transactions using the numerous payment gateway APIs out there. So, we decided to a range of topics that you won't learn from reading documentation -- advice you'll only learn from experience.]]></description>
			<content:encoded><![CDATA[<p>Pivotal Labs recently invited Recurly to present a TechTalk to a room of developers.  Developers are smart people and can quickly figure out how to run credit card transactions using the numerous payment gateway APIs out there.  So, we decided to present a range of topics that you won&#8217;t learn from reading documentation &#8212; advice you&#8217;ll only learn from experience.</p>
<p>In the next several weeks, the TechTalk video should become available.  Until then, let me share a few of the key points with you.</p>
<h2>The Basics: How a Payment is Routed</h2>
<p>The credit card network is a crazy network in and of itself &#8212; lots of banks, credit card networks, and payment gateways &amp; they all need to talk to eachother.  That&#8217;s where your <strong>payment gateway</strong> comes in; your site communicates with the gateway and the gateway routes the credit card transaction to the right credit card company (who in turn routes it to the customer&#8217;s bank).  In the end, there&#8217;s about 5-6 hops before an authorization is made &#8212; see our article <a href="http://blog.recurly.com/2009/08/how-many-companies-does-it-take-to-process-a-credit-card/">How many companies does it take to process a credit card? </a>for more information.</p>
<p>In addition to a payment gateway, you will need a <strong>merchant account</strong>.  The merchant account is best described as a special checking account for your business.  This is where all the money you collect from your subscribers will be deposited.  The payment gateway, through the credit card interchange network, coordinates withdrawing money from the customers bank account and deposits these funds in your merchant account.</p>
<h2>Getting a Merchant Account</h2>
<p>I think of merchant accounts as special checking accounts because they really are special.  Special as in time consuming to open and full of headaches.  When you collect money via credit cards, the transaction doesn&#8217;t end when the money is deposited in your account.  You can be liable for that money for months after the transaction is over because the credit cards want to protect the consumer. For example, if you sell $1 million of goods but then go out of business before you deliver those goods those consumers will ask the credit cards for their money back and all of a sudden you better have $1 million still in your merchant account.</p>
<p>If you&#8217;re working a side project, or your business is going to scale up slowly, then I don&#8217;t want you to waste much time on opening up a merchant account.  Instead, you should look at using a service like PayPal Website Payments Pro &#8212; it combines a merchant account and payment gateway in one, and is easier to apply for.  But if you&#8217;re incorporated and this is your revenue stream, you should open a merchant account with a proper bank.  And, you should budget about a month for the full process of opening a merchant account and getting the credit card agreements in place.</p>
<p>For internet start-ups in the San Francisco area, we strongly recommend <a href="http://www.svb.com/">Silicon Valley Bank</a> for merchant accounts.  They understand start-ups like nobody else.  Recurly spent a month trying to open a merchant account with Bank of America.  Ultimately, B of A denied us because they don&#8217;t understand e-commerce.  This is pretty common among traditional brick-and-mortar banks.</p>
<h2>Payment Gateways</h2>
<p>Not every bank (merchant account) will work with every payment gateway.  If there&#8217;s a gateway you really want to use, make sure it works with your bank first.  Along those same lines, not all integration is equal.  Some banks have first class integration with some payment gateways.  When a bank has a strong integration, you&#8217;ll get access to your money faster, possibly better transaction rates, and better error messages.</p>
<p>One word of advice, be careful signing up for your payment gateway through your bank&#8217;s reseller program.  When your bank resells a payment gateway account, you cannot keep your gateway and switch merchant accounts!  This is so incredibly important.  If you store your credit cards with your payment gateway and your bank decides to close your account for any number of reasons, you no longer have access to your credit card information.  It&#8217;s totally not worth the $200 savings off the payment gateway setup fee.  Seriously, this happened to me and nearly killed the company&#8217;s revenue.</p>
<p>If you&#8217;re looking for a gateway that understand technology well, take a look at <a href="http://www.braintreepaymentsolutions.com/">Braintree Payment Solutions</a>.</p>
<h2>Maximizing Acceptance Rates</h2>
<h3>Address Verification</h3>
<p>Address Verification (AVS) is old school.  Perhaps it works differently across different payment gateways but my experience with Authorize.Net&#8217;s AVS suggests that this is old school 1960&#8242;s string matching technology.  <strong>Zip code validation only works reliably inside the US &#8212; it almost always fails on alpha characters.</strong> So, if you accept international payments, make sure your AVS will succeed on street address matches OR zip code matches, if the customer&#8217;s bank supports AVS.  That setting will help you minimize fraud and maximize acceptance rates.</p>
<p>If you&#8217;re only conducting business in the US, you can turn up AVS more if you like.  This advice is critical if you want to accept international transactions and minimize headaches.</p>
<h3>Expiration Dates</h3>
<p>Here&#8217;s an <strong>industry secret </strong>&#8211; expiration dates usually don&#8217;t matter as long as they&#8217;re in the future.  Several years ago, the credit card companies and utility companies came to an understanding about expiration dates &#8212; it&#8217;s much easier to setup auto-pay for recurring payments if the expiration date doesn&#8217;t matter.  The banks understand that if your card is stolen, they can just change the number &#8212; there&#8217;s no point in having it stop working because of an expiration date.</p>
<p>If you store the expiration date with the credit card information in a payment gateway (e.g. Authorize&#8217;s CIM), that card will stop working after the expiration date.  You cannot move it forward unless you collect the user&#8217;s credit card number again.  But if your billing system is smart enough, perhaps it can try moving the current expiration date forward before asking the user to update their payment details when the card expires.</p>
<h3>1 Cent Authorizations</h3>
<p>If your payment gateway allows you to test a credit card with a 1 cent authorization, don&#8217;t use it.  Seriously.  It will fail 2-5% of the time.  Some banks can&#8217;t believe anyone would want a 1 cent payment so they will deny it for being too small.  Instead, either use a $1 authorization or authorize the transaction for the amount you want to collect in the future (if you know exactly how much that is).  And finally, void the authorization afterwards.  If you don&#8217;t, the credit card companies may hit you with a fine &#8212; this is becoming more common since an authorization effectively puts a hold on funds in the customer&#8217;s account and they want you to release it if you don&#8217;t intend to collect.</p>
<h2>Keep Your Pricing Simple</h2>
<p>If you have a great product, your customers will want to pay you.  But if your pricing is too complicated, three things happen:</p>
<ul>
<li>Your sales guy can&#8217;t explain pricing,</li>
<li>Your programmers (you) will spend too much time figuring out how to bill your users, and</li>
<li>Your customers will complain that they&#8217;re paying too much.</li>
</ul>
<p>Simplify your pricing, perhaps replace overage fees with auto-upgrading tiers, and magic happens:</p>
<ul>
<li>Your sales guys can explain it in a minute,</li>
<li>Your programmers (you) will spend less time on billing, and</li>
<li>Your customers will be happy to pay.</li>
</ul>
<p><strong>Minimize Your Time Handling Billing Support</strong></p>
<p>Billing support will overwhelm you if you&#8217;re not ready.  Make sure your users can self service their accounts the moment you start charging.  If you offer more than one billing cycle or pricing plan, allow your users to change their plan with minimal hassle &#8212; otherwise they&#8217;re going to write to your support and you&#8217;ll have to do it for them, and often.</p>
<p>Make it easy for your subscribers to cancel.  They should not have to contact you to stop paying you &#8212; in the end they&#8217;ll just be more likely to call their credit card company and dispute the charge (that&#8217;s a chargeback).  And if you collect enough chargebacks, say goodbye to your merchant account.</p>
<p>Finally, if you build your own subscription billing system, you&#8217;re going to spend disproportionate amounts of your time handling past-due accounts.  You&#8217;ll get up and running quickly with your payment gateway&#8217;s recurring billing API, but you&#8217;ll spend 10x more time trying to figure out how to handle an account when a payment fails.  That&#8217;s precisely why we created <a href="http://recurly.com">Recurly</a>.</p>
<h2>TechTalk Slides</h2>
<div style="width:425px;text-align:left" id="__ss_2985873"><a style="font:14px Helvetica,Arial,Sans-serif;display:block;margin:12px 0 3px 0;text-decoration:underline;" href="http://www.slideshare.net/Recurly/lessons-learned-in-online-billing" title="Lessons Learned in Online Billing">Lessons Learned in Online Billing</a><object style="margin:0px" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=recurlytechtalk-100125021643-phpapp02&#038;stripped_title=lessons-learned-in-online-billing" /><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=recurlytechtalk-100125021643-phpapp02&#038;stripped_title=lessons-learned-in-online-billing" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed></object></div>
]]></content:encoded>
			<wfw:commentRss>http://blog.recurly.com/2010/01/lessons-learned-in-online-subscription-billing/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>.NET Client Library for Subscription Billing</title>
		<link>http://blog.recurly.com/2010/01/net-client-library-for-subscription-billing/</link>
		<comments>http://blog.recurly.com/2010/01/net-client-library-for-subscription-billing/#comments</comments>
		<pubDate>Mon, 25 Jan 2010 08:39:18 +0000</pubDate>
		<dc:creator>Isaac Hall</dc:creator>
				<category><![CDATA[Billing]]></category>
		<category><![CDATA[Programming]]></category>
		<category><![CDATA[asp.net]]></category>
		<category><![CDATA[C#]]></category>
		<category><![CDATA[client library]]></category>
		<category><![CDATA[subscription billing]]></category>
		<category><![CDATA[VB.Net]]></category>

		<guid isPermaLink="false">http://blog.recurly.com/?p=92</guid>
		<description><![CDATA[As a .NET developer, I am excited to announce that Recurly now has a C#.NET client library well under way!  We polled our customer base and found a large number of our customers are powering their websites with ASP.Net, but they don't have many options today when it comes to simplifying their subscription billing.]]></description>
			<content:encoded><![CDATA[<p>As a .NET developer, I am excited to announce that Recurly now has a C#.NET client library well under way!  We polled our customer base and found a large number of our customers are powering their websites with ASP.Net, but they don&#8217;t have many options today when it comes to simplifying their subscription billing.</p>
<p>Our REST API is pretty easy to consume, yet without an open-source .NET client library to start with, we found that our clients&#8217; integration times took an extra day of effort.  So we started our own.</p>
<p>This lightweight library uses fast-forward only XmlTextWriters and XmlTextReaders along with Stream readers and writers so you can be assured it&#8217;s fast.  It also works great in .NET 2.0 and above.  And finally, it is strongly typed and boasts a wide range of explicit exceptions to help you handle errors.  The library is about 85% completed today and will be finished very soon.</p>
<p>So if you&#8217;re looking for a simple to use, subscription billing service to power your ASP.Net websites, check out <a href="http://recurly.com">Recurly</a> and our open-sourced <a href="http://support.recurly.com/faqs/integration/net-client">C# library</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.recurly.com/2010/01/net-client-library-for-subscription-billing/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>The Challenges of Subscription Billing</title>
		<link>http://blog.recurly.com/2009/08/challenges-of-subscription-billing/</link>
		<comments>http://blog.recurly.com/2009/08/challenges-of-subscription-billing/#comments</comments>
		<pubDate>Wed, 26 Aug 2009 19:27:54 +0000</pubDate>
		<dc:creator>Isaac Hall</dc:creator>
				<category><![CDATA[Billing]]></category>
		<category><![CDATA[Subscriptions]]></category>
		<category><![CDATA[billing service]]></category>
		<category><![CDATA[declined payments]]></category>
		<category><![CDATA[metrics]]></category>
		<category><![CDATA[payment gateway]]></category>

		<guid isPermaLink="false">http://blog.recurly.com/?p=20</guid>
		<description><![CDATA[More than once, I've underestimated the efforts required to create a billing system.  I have yet to find a start-up that budgeted correctly for the time and effort to integrate subscription billing. If your startup is new to subscription billing, there are a few key problems you'll soon encounter.  Knowing about these issues will help you budget your development resources appropriately and help you evaluate your recurring billing options.]]></description>
			<content:encoded><![CDATA[<p>More than once, I&#8217;ve underestimated the efforts required to create a billing system.  I have yet to find a start-up that budgeted correctly for the time and effort to integrate subscription billing.  From the outside, the task seems to be pretty straightforward:</p>
<ol>
<li>Signup for a recurring billing service</li>
<li>Create a signup form that accepts the billing information</li>
<li>Create a page for the user to update their billing information</li>
<li>Allow the user to cancel their subscription</li>
<li>Sell your product or service and money</li>
</ol>
<p>The above will get you up and running with subscriptions.  However, there&#8217;s a lot missing from the above picture that you won&#8217;t realize until you roll out your new billing system.  If your startup is new to subscription billing, there are a few key problems you&#8217;ll soon encounter.  Knowing about these issues will help you budget your development resources appropriately and help you evaluate your recurring billing options.</p>
<p><strong>Declined Recurring Payments</strong><br />
For starters, what happens when one of the recurring payments fails due to a declined or expired credit card?  Will your system know to alert the user and/or cancel their subscription?  Can you get a list of past due accounts?  And, will the system continue billing the user or will it stop until their payment information is updated?</p>
<p>When a card is declined during the subscription renewal, you need to alert the customer and give them a way to update their billing information.  If they update their billing information in a timely manner, then bill them the missed amount.  Otherwise, the appropriate action is to cancel their subscription and transition their account back to a free account.  Unfortunately, many recurring billing APIs make it non-trivial to determine if a recurring payment failed.  And, if the user updates their billing information, verify that the service will collect the missing payment &#8212; this should happen immediately as part of the billing info update process.</p>
<p><strong>Upgrades and Downgrades</strong><br />
If your site offers multiple subscription types, billing intervals, or quantities, then your customers are guaranteed to ask for upgrades and downgrades of their subscription.  If you start offering your subscriptions without a means for the subscriber to modify their own subscription, then you&#8217;ll receive several support requests.  Hopefully your support staff has the tools to modify the subscriptions or else you will miss the opportunity to make more money by allowing your users to upgrade.  And, a few users will be more than unhappy.</p>
<p>Of course, not all recurring billing APIs will allow you to upgrade or downgrade like you would expect.  Typically, an upgrade (additional quantity, add-ons, or service level) should happen immediately.  To do that, the remainder of the current term needs to be prorated and billed immediately.  Not all recurring billing services do this &#8212; some will require you to wait until the renewal to charge a new amount.</p>
<p>Downgrades or billing cycle changes can be just as tricky.  These events typically occur at the end of the current billing cycle, since the customer has already committed to paying for their current term.  These changes are doable with almost all recurring APIs, but most services will require you to perform the calculations to get the changes just right.  Buffer for some development time and lots of testing here.</p>
<p><strong>Customer Service Tools</strong><br />
Does your billing system give your support staff the ability to lookup and modify accounts?  Your subscribers will want you to make changes (either by contacting you with a phone call or email) on their behalf.  If it takes an engineer to make subscription changes because you haven&#8217;t built the tools for your support staff to handle the modification, then you&#8217;re not using your resources efficiently.  Other users will expect your support staff to be able to offer them credits or refunds if something should go amiss.  Your support staff should be able to handle these requests immediately to minimize any chances of chargebacks or upset customers.  I strongly encourage you to give your support staff the tools necessary to support billing requests without involving a developer with database access.</p>
<p><strong>Reporting and Metrics</strong><br />
Are you tracking your subscriber metrics?  Your payment gateway will tell you about the dollars and cents moving through your account but it doesn&#8217;t know anything about subscribers.  You&#8217;ll want to know as much as you can about new signups, upgrades and downgrades, cancellations, missed payments, failed subscribe attempts, etc.  Out of the box, most recurring billing services fail to provide these reports.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.recurly.com/2009/08/challenges-of-subscription-billing/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->