Policy period management

Your plugin’s createPolicyPeriod method tells your billing system to create a policy period associated with a particular transaction. As a method parameter, this plugin method gets the PolicyCenter PolicyPeriod entity instance that represents data in the new policy period. However, the billing system view of a policy period typically is significantly simpler than the PolicyCenter view of the same policy period.

Use the policy period’s policy number and term number to uniquely identify the policy period in both systems. The method contains a second parameter, which is the billing system transaction ID.

The transaction ID is an identifier that PolicyCenter creates. Your plugin must track this billing system transaction ID. If PolicyCenter requests the same transaction ID twice, the billing system or your plugin that represents it must detect that PolicyCenter requested it twice. If you receive the same transaction ID more than once, you must ignore the duplicate requests.

If you have any data model extension properties on the PolicyCenter version of PolicyPeriod, consider whether any are appropriate for your billing system.

PolicyCenter calls this method as part of binding a new policy:

• If you perform a bind and issue as one user interface action, PolicyCenter calls createPolicyPeriod only.
• If you perform just a bind in the user interface, PolicyCenter creates the new PolicyPeriod locally and then calls the billing system plugin createPolicyPeriod method. For an issuance request that occurs later, PolicyCenter calls the plugin’s issuePolicyChange method.

See also

• Billing system notifications of PolicyCenter policy actions

PolicyCenter starts some types of cancellations:

• Cancellation as part of a rewrite request.
• Cancellation at the insured’s request
• Cancellation due to the insured lied in their application or violated the contract
• Cancellation because the insured chooses not to take a renewal and the renewal might already be bound

To the billing integration code, all these cases are the same.

Your IBillingSystemPlugin plugin must handle these types of cancellations.

The billing system starts other types of cancellations. For example, cancellation for non-payment. If the billing system detects overdue invoices, the billing system starts a delinquency process and eventually tells PolicyCenter to cancel the policy. However, the billing information flow is independent of which system starts the cancellation. In other words, whenever the cancellation completes, PolicyCenter sends the billing implications to BillingCenter.

If you implement the IBillingSystemPlugin plugin, your plugin’s cancelPolicyPeriod method notifies your billing system of a policy cancellation. This method’s parameters are a policy period as a PolicyPeriod entity instance and a billing system transaction ID.

The transaction ID is an identifier that PolicyCenter creates. Your plugin must track this billing system transaction ID. If PolicyCenter requests the same transaction ID twice, the billing system or your plugin that represents it must detect that PolicyCenter requested it twice. If you receive the same transaction ID more than once, you must ignore the duplicate requests.

Cancellation can often be a complex process with legally required notification delays. PolicyCenter does not call cancelPolicyPeriod at the time of a request to initiate cancellation. PolicyCenter calls this method after binding the cancellation transaction. Typically, this plugin method sends a cancellation billing instruction or equivalent command to your billing system in whatever way is appropriate. This method returns no value.

To support reinstatement, your plugin’s issueReinstatement method notifies your billing system of a policy reinstatement. It takes the same arguments as cancelPolicyPeriod and returns no value.

See also

• Policy cancellation and reinstatement web services

Your plugin must also prepare for a policy rewrite request and send that information to your billing system. PolicyCenter calls the rewritePolicyPeriod method to rewrite the policy period and rewritePolicyPeriod must send that information to your billing system. Its two method parameters are a policy period (PolicyPeriod) and a billing system transaction ID.

The transaction ID is an identifier that PolicyCenter creates. Your plugin must track this billing system transaction ID. If PolicyCenter requests the same transaction ID twice, the billing system or your plugin that represents it must detect that PolicyCenter requested it twice. If you receive the same transaction ID more than once, you must ignore the duplicate requests.