Implementing the billing system plugin

If you want to use a billing system other than BillingCenter, create your own class that implements the billing system plugin interface: IBillingSystemPlugin. The billing system plugin is the main interface between PolicyCenter and its billing system.

Note: If you use BillingCenter, the base configuration plugin implementation handles these tasks. You do not perform the tasks in this topic.

Your plugin implementation must implement all the methods defined by the plugin interface. This plugin handles a wide variety of billing-related tasks.

The most important thing to know about implementing the billing system plugin is that PolicyCenter billing requests typically happen asynchronously. The typical flow of a billing request is as follows:

A user changes something in PolicyCenter. This change causes a messaging event to fire. Possible messaging events are:
- A custom messaging event that some code triggers, for example, completing a policy change.
- Automatic messaging events that trigger because of changes in Guidewire entity instances, for example, PolicyPeriod or Contact.
As a consequence, PolicyCenter rule sets trigger.
The Event Fired rules detect what changed and creates event messages representing what type of change happened and submits them to the messaging event queue.
As the bundle for the original change commits, the messages commit to the database.
In a separate task on the batch server only, messaging plugins send messages. In the case of billing, message transports specific to billing attempt to send each message. The way it sends a message is to call methods on the currently enabled IBillingSystemPlugin plugin implementation.
Your billing system plugin method must perform its task synchronously with respect to the caller of the plugin method. However, the call typically happens inside messaging transport code, which runs asynchronously with respect to the original change in the PolicyCenter user interface and the application database.
Important: Your billing system plugin code is called as part of an asynchronous task that the messaging system manages. It is not called as part of the original database transaction for the change that triggers the call to the billing system.
Your plugin code must always act on the PolicyPeriod passed to it. Because this is asynchronous, theoretically multiple changes might happen to a policy before all the messages are processed by the messaging system. By the time your plugin is called, it might actually not be the most recently bound version of the policy. However, you must always handle the requests in the order you receive them. Just use the PolicyPeriod reference that is the method parameter, and it is possible you might get additional updates or changes in future calls to your plugin.