anchor.diff:  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, or modify the login flow on a website to prompt for payments, ...
  +* 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, ...
  
positive.code: 
  When a customer attempts to use the service, the web site *could* verify if the customer is entitled to receive the service:
  
  1. It should first retrieve the overdue status (at the account level) using the `GET /1.0/kb/accounts/{accountId}/overdue` api,
  2. It should then retrieve the subscriptions associated with the account `GET /1.0/kb/accounts/{accountId}/bundles`, or if the subscriptionId was cached it could use `GET /1.0/kb/subscriptions/{subscriptionId}`
  
  The endpoint `GET /1.0/kb/accounts/{accountId}/overdue` will return the following json:
  
  [source,json]
  ---
  {
    "blockChanges": true,
    "clearState": false,
  
negative.code: 
  === Good Customer
  
  Let's assume he is a good customer, and after the `WARNING`, he updates his credit card:
  
  * Day 15: customer updates credit card and pays his unpaid invoice(s) (more details below). The system brings back the overdue status to `CLEAR`.
  
  