anchor.diff:  
   Additionally, we want to prevent users from changing plans (e.g. upgrade) until they clear their balance.
   
  -Note that in the scenario defined above, the 2nd payment attempt is after 9 days (just before the first overdue state), the third 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). Thus, we are configuring the system to retry payments 1 day before each overdue state.
  +So, the scenario specified above requires configuring 3 overdue states. The account should be moved to the first overdue state 10 days after an unpaid invoice, it should move to the second overdue state 14 days after the unpaid invoice and it should be moved to the final overdue state 21 days after the unpaid invoice. 
  +
  +Further, the scenario above also specifies the payment retries in such a way that they align with the overdue states. So, it requires the second payment attempt to be made after 9 days (just before the first overdue state), the third payment attempt after 13 days (before the second overdue state) and the final payment attempt after 20 days (before the last overdue state). Thus, we are configuring the system to retry payments 1 day before each 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.
   
  
positive.code: 
  Before we dive into the details, let us understand some high-level concepts.
  
  Kill Bill has two distinct built-in mechanisms that come into play in such situations, 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.
  
  
negative.code: 
  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 to retry payments several times before blocking the user's access and thus would require using both systems in conjunction with one another. 
  
  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. Further, to ensure that the payment is always retried before the overdue system, it makes sense to configure a payment retry 1 day before each overdue state. 
  
  