Billforward FAQs
Subscription
Back to home

Testing and Integration

Billing logic is an integral part of any software solution. Platform access, features and even getting paid on time all stem from correct integration of the billing stack into your platform.

Using BillForward, you can:

  1. Integrate quickly and effectively
  2. Simulate billing scenarios
  3. Build integration tests into your CI stack
Time Control API documentation

Integration

Integration begins by defining the pricing and packaging for the products you will sell. This is done by defining products and rate-plans in Billforward.

The next step is to define the life-cycle of a typical customer on your platform, for example:

  1. Initial sign-up
  2. Recurring billing
  3. Upgrade flow
  4. Non-payment
  5. Billing account management
  6. Cancellation

Let’s walk through one of these scenarios.

Non-payment

Commonly a process of payment retry (dunning) is performed by the billing platform. This allows the customers payment to fail a number of times before removing their access. The process may be as follows:

  1. New invoice generated on the 1st of the month
  2. Payment fails on first attempt
    1. Email sent to customer warning them of failed payment
    2. Display in-app banner warning customer payment was unsuccessfully
  3. Payment fails again on the 5th of the month
    1. Another email sent to customer warning them of failed payment
    2. Display in-app banner warning customer their service will be disconnected
  4. Payment fails again on the 10th of the month
    1. Disconnect customers service
    2. Send failed subscription email

If you look at the above steps you may realize that there are a few events and actions that need to be performed over the life-cycle of this non-payment flow. How can we make sure our application correctly handles these actions?

Simulations

The steps to building a billing integration test are similar to creating a typical unit test. A number of steps are set up and assertions defined at each important logical step.

Assertions: When creating a simulation assertions should be defined to check that the simulation is functioning correctly. When an assertion fails, you know something is going wrong. You now have a tested scenario!

For the above scenario, let’s create a subscription that starts on the 1st of March

Step 1: Create plan

Create a simple pricing plan for $5/month.

The plan will be to re-use this plan, so feel free to create it via either the UI or the API.

Note down the ID of the plan.

Step 2: Create an account

Create an Account to purchase the subscription using the plan created in step 1.

This time create the account via the API. Make sure you note down the API call you did!

Step 3: Issue credit to the account

To simulate a Non-payment we need to have a subscription which has had at least a single successful billing period. Rather than adding a card we can just add enough credit pay for the first billing period.

Issue $5.00 of credit to the account from Step 2 via the API.

Step 4: Start a subscription

The next step involves creating a subscription and generating an invoice for it. The subscription should automatically become paid using the credit issued in step 3. Use the API to start the subscription.

Billing Assertion: The subscription state is paid
Application Assertion: The account now has privileges only enabled for paying customers

Step 5: Fast forward till 1st April

Now we have created a subscription and we know it is in the paid state. Let’s create it’s next invoice. To do this we use the time control API and fast-forward one billing period.

Billing Assertion: The subscription state is AwaitingPayment AND
                   The subscription has totalPeriods == 2    AND
                   The subscription has dunning == true
Application Assertion: The account has privilege for paying customers AND
                    The account has a warning message enabled saying payment has failed

We now know that the subscription has failed to be paid and has entered the next billing cycle

Step 6: Time control till 5th April

We will now fast forward the subscription to the 5th of April using the to property of the time control API call.

Billing Assertion: The subscription state is AwaitingPayment AND
                   The subscription has totalPeriods == 2    AND
                   The subscription has dunning == true
Application Assertion: The account has privilege for paying customers AND
                    The account has a warning message enabled saying payment has failed and will be downgraded on the 10th

Step 7: Time control till 10th April

We will now fast forward the subscription to the 10th of April using the to property of the time control API call. If only a single dunning attempt has been configured the subscription will now fail due to non-payment.

Billing Assertion: The subscription state is Failed AND
                   The subscription has totalPeriods == 2    AND
                   The subscription has dunning == true
Application Assertion: The account has privileges paid-for disabled

Constant Integration

If the above steps have been performed via API they can then be added into the testing cycle for every release.

Was this article helpful?
YesNo