anchor.diff:  "http://127.0.0.1:8080/1.0/kb/accounts"
   ----
   
  -[start = 3]
  +[start = 4]
   . Add the payment method (assuming `60035793-cbe5-472a-8bd8-3c67cc3beaf4` is the accountId):
   
   [source,bash]
  
positive.code: 
  === 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. In order to create a Java plugin, you can refer to this https://docs.killbill.io/latest/notification_plugin.html[tutorial]. If you would like to create a Ruby plugin, you can refer to the https://github.com/killbill/killbill-hello-world-ruby-plugin/blob/master/lib/helloworld/user_listener.rb[Hello World Ruby Example].
  
  The plugin would need to filter for `OVERDUE_CHANGE` https://github.com/killbill/killbill-plugin-api/blob/master/notification/src/main/java/org/killbill/billing/notification/plugin/api/ExtBusEventType.java[events]
  
  Such plugins can be used for the following purpose:
  
  * Email/Notify user about the new state
  * 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, ...
  
  
negative.code: 
  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.
  
  