anchor.diff:  
   When retrieving entitlement/overdue status, the web site could be implemented to take all kinds of actions such as displaying warning message, degrading experience, emailing customer, ...
   
  -
   === Custom Plugins
   
   In the previous section, we discussed a possible implementation where the web site queries the billing system to figure out the entitlement story attached to a customer (when he logs-in for instance). Another pattern is to create a custom notification plugin that will listen to `Overdue` events and take appropriate action. The plugin would need to handle the `OVERDUE_CHANGE` event. 
  
positive.code: * Ensure that you have gone through the https://docs.killbill.io/latest/userguide_subscription.html[Subscription UserGuide] and are familiar with catalogs, invoices, payments and other concepts.
  * Ensure that you have https://curl.haxx.se/[cURL] installed. If you are on Windows, we recommend that you use https://git-scm.com/download/win[Git Bash] to run the `cURL` commands.
  
  === Scenario
  
  Let's assume you want to build a website where your customers can subscribe to movies (similar to Netflix). For simplicity's sake, we will assume you only provide one $10/month plan for unlimited streaming. The plan will contain a 10 days trial period during which customers have unlimited access.
  
  We now want to configure the overdue system (dunning) to take some actions when users don't pay:
  
  1. The system should be configured to retry failed payments 4 times: the first payment retry should happen 1 day after the payment failure, the next attempt should happen 8 days after previous attempt, the third attempt should happen 4 days after the previous attempt and the last one should happen 7 days after the previous attempt
  2. The system should notify the user when an invoice has not been paid after 10 days (during which time the system already automatically retried 2 times)
  3. The system should block the entitlements associated with the account after 14 days
  4. The system should automatically cancel the subscriptions after 21 days
  
  Additionally, we want to prevent users from changing plans (e.g. upgrade) until they clear their balance.
  
  == Overdue and Payment Retry System Overview
  
  Before we understand how to implement the above scenario, let us understand some high-level concepts.
  
  Kill Bill has two distinct built-in mechanisms that come into play here, these are the *Payment Retry System* and the *Overdue System*. Though separate, these two systems work in close conjunction with each other.
  
  The *Payment Retry System* is a system that retries failed payments as per a defined schedule. The schedule can be defined via a property in the Kill Bill configuration file or can be uploaded on a per-tenant basis. The scenario above states that the system should be configured to retry failed payments 4 times. So, the Payment Retry System needs to be configured accordingly. 
  
  The *Overdue System* defines the flow that the system must follow when an account is overdue (that is, has an unpaid balance). It can be configured via an XML file. The XML file can be specified via a property in the Kill Bill configuration file or can be uploaded on a per-tenant basis. The XML file defines the various _states_ that the account must go through, the _change in the user's entitlements_ when the account is transitioned from one state to the other and the _period_ after which the state is re-evaluated. The scenario above states that the entitlements should be blocked after 14 days and the subscription should be cancelled after 21 days. So, this needs to be configured in the overdue XML file.
  
  It is important to understand that the *Payment Retry System* and the *Overdue system* are *independent* of each other. So, the *Payment Retry System* attempts payments as per its retry schedule while the *overdue system* moves the account from one state to the other as per its configuration.
  
  Having said that, most business cases would require using both the systems in conjunction with one another. Even the scenario defined above requires attempting the payment 4 times as well as taking some actions when the balance is unpaid. Thus, both the systems come into play.
  
  Although the payment retry system and overdue systems need to be configured independently of each other, it makes sense to *align payment retries with overdue states*. This allows retrying the payment on the boundary of each overdue state and thus prevents transitioning from one state to the next if the payment gets retried successfully. In the scenario defined above, the 2nd payment attempt is after 9 days (just before the first overdue state), the 3rd payment attempt is after 13 days (before the second overdue state) and the final payment attempt is after 20 days ( before the last overdue state).  
  
  Let us now understand how to to configure both the *Payment Retry System* and the *Overdue system* in order to implement this scenario.
  
  
  == Configuration of the System
  
  
negative.code: * Email/Notify user about the new state (We already have a Java  https://github.com/killbill/killbill-email-notifications-plugin[email notification plugin] which can be extended to handle `OVERDUE_CHANGE` events)
  * Take action to modify the experience (based on the state name): for instance to degrade the service, modify the login flow to prompt for payment, ...
  
  
  == Additional Resources
  
  