anchor.diff:  ----
   
   
  -[start = 3]
  -3. Create a subscription to trigger some invoices and (failed) payment. 
  -
  -Note: The current date in the system is set to `2015-12-30` (date at which this experiment was conducted). You will need to either configure your system to use that date (using endpoint shown below) or translate to some dates of your choice.
  +[start = 4]
  +. Create a subscription to trigger some invoices and (failed) payment. 
   
   [source,bash]
   ----
  
positive.code: -H "Content-Type: application/json" \
  -H 'X-Killbill-CreatedBy: demo' \
  -X POST \
  --data-binary '{"CONFIGURE_ACTION":"ACTION_RETURN_PLUGIN_STATUS_ERROR", "METHODS":"purchase_payment"}' \
   -v 'http://127.0.0.1:8080/plugins/killbill-payment-test/configure'
  ----
  
  You can then refer to the  https://github.com/killbill/killbill-payment-test-plugin/blob/master/README.md[plugin documentation (section Global State Configuration)] to configure the plugin and trigger failures. 
  
  
  [start = 6]
  6. Move the clock to the next month and observe first failed payment
  
  
  [source,bash]
  
negative.code: 
  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 two payment retries should happen 1 day after the last attempt, the third one should happen 8 days after previous attempt and the last one should happen 6 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 3 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 in-built mechanisms that come into play here, these are the *Payment Retry System* and the *Overdue system*. Though separate, the Overdue system and the Payment Retry System 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.
  
  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.
  
  Let us now understand how to implement the above scenario.
  
  == Configuration of the System
  
  === Catalog Configuration
  
  First of all, you will need to create a catalog. Your catalog will contain a plan entry that specifies two phases, one for the trial period of 10 days and one for the recurring monthly charge of $10:
  
  [source,xml]
  ----
  