LessChurn Docs

Getting Started

Did you know we'll do all this for you?

We'll screenshare and walk you through every step! Ask for help.

  1. Understand Live and Test Environments
    • Like Stripe, LessChurn has a live and a test mode. These two modes operate relatively independently from one another.
    • Inviting or removing team members will add/remove them to both environments.
    • When you set up or make a change to a setting or a detour make sure you make the same change in the other environment if needed.
  2. Configure Your Settings
    • Business Name: Your customers will see this. (Business name can only be changed in live environment.)
    • Send emails to: The default email address that detours are sent to when "Notify someone via email" is checked on the Churn Form and the subsequent "Email Address" field is left blank.

      From the Settings Page:

      Settings email
      From the Churn Form
      Churnform email

    • Connecting to Stripe: Stripe will automatically determine if you are in Live or Test mode, so just pick the Stripe account you'd like to use (assuming you have more than one).
    • Webhook URL: The URL on your site that we will (optionally) send a webhook notifying you when a detour has been chosen by one of your customers. NOTES:
      1. All webhooks will be sent to this URL.
      2. Each webhook can be identified by the "Webhook label" you specify for each detour.
      3. You can have a different URL for each live and test environment.
      4. More information.
    • Redirect URL back to your site: The URL your customers will be redirected to once they select a detour. If "Redirect to a custom URL" on the Churn Form is left unchecked, this is the URL they will be sent to. See Lifecycle of a Confirmation for more details.
  3. Configure Your Detours

    Detour Types

    • No Stripe/Braintree Action
      This is the most basic Detour type. It does not interact with your gateway, all you can do with it is send an email and choose a redirect location. Although simple, you can get very creative with this one. Here are a few ideas:
      • Send a request to support.
      • Notify the founders/CEO. This is just like support, but "talking to the boss" has a powerful psychological effect.
      • Ask the most common help support issues and redirect them to your help page on that topic. e.g. "I can't get my bank account to sync."
    • Delete
      This detour will delete the customer from your gateway. Consider pushing them to Cancel instead.
    • Cancel Subscription Immediately
      This will cancel their subscription and prorate their last bill (check the docs for your gateway to see how they handle this on their end). If they don't have a subscription, this detour isn't shown.
    • Cancel Subscription After The Current Billing Cycle
      This will cancel their subscription, but it remains active until the current billing cycle ends. If they don't have a subscription, this detour isn't shown.
    • Pausing
      This action cancels their subscription, and attempts to reconnect it on the specified date. You can set the date to be in a certain number of months or on a specific date. You can choose to cancel immediately or at the end of the current billing cycle. There are additional webhooks that are sent with this action, please see the documentation for pausing for more details. If they don't have a subscription, this detour isn't shown.
    • Downgrade to a Different Plan
      This detour will show you all the plans that are in your gateway. Then you can choose which ones are available choices for your customers. (You probably only want to show active plans). Your customer is shown a list of plans that are less expensive than the plan they are on. If they are already on the cheapest plan, this detour is not displayed.
    • Add a coupon
      You can choose to apply a coupon. You choose the coupon, it can be a discount for a certain number of months, a free month, or anything else your gateway supports. Coupons may only be applied once, so if a customer uses a coupon they cannot use another one later. If they have already applied a coupon, this detour is not displayed.
    • Extend Trial
      For customers still in their free trial (if you have one) you can extend it for a certain number of days. If they are no longer on their free trial, this detour isn't shown.
  4. Set up webhook responders in your app
    • Use webhooks to be notified about events that happen in your LessChurn account. A webhook can be sent for each detour taken by one of your customers. You may want to receive a webhook for each detour or may prefer to ignore certain detours, but you will certainly want to be notified when a customer deletes their account.
    • Configuring a webhook

      There are two places to configure a webhook.
    • Receiving a webhook

      Configuring your server to receive a new webhook is no different from creating any page on your website. With PHP, you might create a new .php file on your server; with a framework like Sinatra, you would add a new route with the desired URL. Remember, with webhooks, your server is the server receiving the request.

      Webhook data is sent as JSON in the request's body. The full detour details are included and can be used directly. You can always resend a webhook from the webhooks page.

      Webhooks are called synchronously when your customer takes a detour. That means that your customers are waiting for your web server to finish responding to the webhook before we redirect them back to your site. If your detour is set to send a webhook, but your server is down, your customer will be waiting until the webhook request times out. We do this to ensure that when your customer is returned to your site, the state in Stripe or BrainTree matches the state in your app. If you don't like this you should set your webhook responses to return a response immediately, before handling the request.

    • Webhook content

      You can view the content for the webhook for each Detour on the Churn Form page. They're all going to look something like this:
                POST
      Host:
      Content-Type: application/json
      Cache-Control: no-cache
      {
        "customer_id":"cus_00000001",
        "label":"will_unpause",
        "action":"extend_trial",
        "api_key": "your LessChurn api key"
        "passthrough_param": "",
        "passthrough_param_another_param": "",
        "redirect_param": "",
        "redirect_param_another_param": ""
      }
      You can send any additional data back to you through your webhook simply by passing data via the passthrough_params. You can find out more about passthrough_params and redirect_params.
    • Receiving webhooks with a CSRF-protected server

      If you're using Rails, Django, or another web framework, your server may automatically check that POST request bodies it receives contain a CSRF token. This is an important security feature that helps protect you and your users from cross-site request forgery. However, it may also prevent your server from receiving legitimate webhooks. You may need to exempt from CSRF protection the Rails route or Django view you use to receive webhooks. Rails:
      class LessChurnController < ApplicationController
        # If your controller accepts requests other than Stripe webhooks,
        # you'll probably want to use `protect_from_forgery` to add CSRF
        # protection for your application. But don't forget to exempt
        # your webhook route!
        protect_from_forgery :except => :webhook
      
        def webhook
          # Process webhook data in `params`
        end
      end
      Django:
      import json
      
      # Webhooks are always sent as HTTP POST requests, so we want to ensure
      # that only POST requests will reach your webhook view. We can do that by
      # decorating `webhook()` with `require_POST`.
      #
      # Then to ensure that the webhook view can receive webhooks, we need
      # also need to decorate `webhook()` with `csrf_exempt`.
      @require_POST
      @csrf_exempt
      def webhook(request):
        # Process webhook data in `request.body`
    • Responding to a webhook

      Unlike Stripe, LessChurn does not check the response your server sends, nor does it resend webhooks automatically until a proper response is received (but you can resend them from the Webhooks page). LessChurn stores the response status and body to help debugging, but other than that the response is ignored.
    • Viewing webhooks

      LessChurn stores every webhook sent and the response from your web server. You can view them on the Webhooks page. If you click on the data column you can drill into that webhook and see the details for each time the webhook was sent.
    • Resending a webhook

      You can resend any webhook by clicking on "Resend" when you're viewing a webhook on the Webhooks page.
    • Pausing

      Pausing has additional webhooks. Please see the documentation for pausing for more details.
  5. Change the delete page in your app (in your staging environment.) Add this to your webpage:
    • You can change height and width attributes if you'd like. Note that the iFrame will automatically resize itself so it fits without scrolling in your webpage.
    • URL Parameters

      • api_key: This is your unique LessChurn api key. It can be found (and regenerated) on the Settings page.
      • customer_id: This is the Stripe or BrainTree customer ID.
      • subdomain: if you want to redirect to a subdomain pass it here. LessChurn will inject whatever you pass into the redirect url, e.g., if your redirect url is "https://my.app.com/dashboard" and you pass the subdomain parameter with a value of "xxx," LessChurn will redirect your customer to "https://xxx.my.app.com/dashboard." This is true for custom redirects too.
      • passthrough_param: This is any data you'd like to be passed through to the webhook. You might use it for a "user id" or some other bit of data. You can have as many passthrough_params as you'd like. Any parameter that starts with "passthrough_param" will be considered a passthrough param and the data will be sent to the webhook. So "passthrough_param," "passthrough_param1," "passthrough_param_1," etc are all valid names for a passthrough parameter.
      • redirect_param: Just like passthrough parameters, anything you send as a redirect parameter will be sent to the webhook, but redirect parameters will also be sent to your server as querystring parameters when your customer is redirected, after they select a detour. This can be very useful if you need to redirect them to a subdomain.
      • Tracking User IDs: If you supply a passthrough param with the key "user_id" or "user," LessChurn will store that ID and display it on the confirmations report page.
    • Make sure the iFrame is on a page that only gets loaded when your customer wants to delete her account. Otherwise your statistics will be all messed up.
    • If you're loading the iFrame/script tag via an ajax call it's possible that jQuery will remove the script tag. To overcome this you might use this code in your "success" callback:
  6. Do end to end testing
  7. Change the delete page in you app (in your production environment.) Add this to your webpage:
    • You can change height and width attributes if you'd like. Note that the iFrame will automatically resize itself so it fits without scrolling in your webpage.
    • URL Parameters

      • api_key: This is your unique LessChurn api key. It can be found (and regenerated) on the Settings page.
      • customer_id: This is the Stripe or BrainTree customer ID.
      • subdomain: if you want to redirect to a subdomain pass it here. LessChurn will inject whatever you pass into the redirect url, e.g., if your redirect url is "https://my.app.com/dashboard" and you pass the subdomain parameter with a value of "xxx," LessChurn will redirect your customer to "https://xxx.my.app.com/dashboard." This is true for custom redirects too.
      • passthrough_param: This is any data you'd like to be passed through to the webhook. You might use it for a "user id" or some other bit of data. You can have as many passthrough_params as you'd like. Any parameter that starts with "passthrough_param" will be considered a passthrough param and the data will be sent to the webhook. So "passthrough_param," "passthrough_param1," "passthrough_param_1," etc are all valid names for a passthrough parameter.
      • redirect_param: Just like passthrough parameters, anything you send as a redirect parameter will be sent to the webhook, but redirect parameters will also be sent to your server as querystring parameters when your customer is redirected, after they select a detour. This can be very useful if you need to redirect them to a subdomain.
      • Tracking User IDs: If you supply a passthrough param with the key "user_id" or "user," LessChurn will store that ID and display it on the confirmations report page.
    • Make sure the iFrame is on a page that only gets loaded when your customer wants to delete her account. Otherwise your statistics will be all messed up.
    • If you're loading the iFrame/script tag via an ajax call it's possible that jQuery will remove the script tag. To overcome this you might use this code in your "success" callback:

Did you know we'll do all this for you?

We'll screenshare and walk you through every step! Ask for help.