Testing your Advanced Billing Implementation

Introduction to Testing Create Subscription Invoice and Payment Collection Signup Page Billing Portal More

---

Testing is important to your success. As a rule of thumb, you'll want to test your implementation from start to finish. In other words, for each use case you have, simulate the customer signup all the way to the customer's subscription end. Within this chronological testing, you'll uncover the nuances of your signups, subscription management, invoices, payment collection, and more. If anything seems off, make the necessary changes.

In this guide, we'll provide you with some testing steps for the most common testing scenarios.

How to Test - Create Subscription

Feature

Subscription signups

You Need

A completed implementation, for your given signup method(s)

Code

None

Difficulty

◉◎◎◎◎

---

1. Create a Subscription

This test subscription should mirror all aspects of your real use case, and it will be used for each subsequent step.

Important

• Create this subscription with your implemented signup method

Use Real Data

• email address (make sure you have access to this email address)
• shipping address
• billing address
• products/components
• discounts
• custom fields
• Include any other elements, for your specific use case, that you need to verify
  
  

2. Review the newly-created subscription

Below is an image of a Subscription Summary page. Marked in red are the most common data points to check for accuracy. In addition to these, check anything else that is important to your implementation. 

How to Test - Invoice and Payment Collection

Feature

Invoices

You Need

A completed implementation

Code

None

Difficulty

◉◎◎◎◎

---

1. Review a Signup Invoice

Using the same test subscription you created, view the first invoice. Click 'Invoices', then click the specific invoice, then review the common fields highlighted in red. For any settings-based fields that seem off (such as company address), go back and modify as needed. For any customer-based fields that seem off, check your implementation to find the cause, and then make the necessary changes.





Check these most common fields. Additionally, other fields (not pictured below) that you might want to check on an as-needed basis are Custom Fields, VAT display, Tax display, Coupons, Service Credits, Prepayments.

2. Preview the next invoice

You'll want to preview the next invoice as well. Click 'Preview Proforma'. The intent is to ensure all monetary values are correct. Once you preview the invoice, now make changes to your subscription to simulate monetary changes that are relevant to your use case (record usage, upgrade a component, apply a service credit, etc). Each time you make a change, preview the invoice again -- does it match your expectations? Repeat this exercise until you are sure everything is set up correctly.

How to Test - Signup Page

Feature

Signups

You Need

Access to test your signup process

Code

None

Difficulty

◉◎◎◎◎

---

1. Test your signup process for all use cases

In this exercise, you'll test each of your use cases by simulating the signup process from start to finish. Depending on the signup method you implemented, use the corresponding grid below to test. For example, if you use Public Signup Pages, simulate a Signup Success and a Signup Failure, then examine the results of each category as needed.


Simulate a successful signup, and test the following as needed:
      - Payment: Payment page loads properly in your workflow
      - Workflow: User is redirected to the right page
      - Emails: Signup Email received
      - Your App: Database, User Access, Webhooks
      - Integrations: Data sent to 3rd party system

 Simulate a signup failure (typically a payment decline), and test the following as needed:
      - Error handling: Error message shows properly
      - Emails: No emails sent
      - Your App: Database, User Access, Webhooks
      - Integrations: Data sent to 3rd party system

Test Cards
See a list of success/decline card numbers

How to Test - Billing Portal

Feature

Billing Portal

You Need

A Billing Portal link

Code

None

Difficulty

◉◎◎◎◎

---

1. Test the Login Flow

Your login flow is based on your chosen implementation method. Here's a list of the options.

2. Review the Portal

When viewing the Portal from the perspective of your customer, can you perform the actions you expect? Compare your Portal view to your Portal Settings. Make settings changes as needed.

3. Update the Subscription

Let's simulate an update. You'll want to test each update your customer may make. In this example, let's simply change a plan.

First, click Change Plans:


Choose the Plan to change to. In this example, we're downgrading from Premium ($29/mo) to Pro ($15/mo).



Review the monetary values. This change will apply a prorated credit. For one use case, that may make sense. Let's say for yours, it doesn't. We need to change a setting.


In the Billing Portal settings, we can see that the Product Change Strategy is set to '`Prorated upgrades and downgrades'. Let's change it to 'Instant product change, no proration'. 



When we refresh the Billing Portal Confirm Plan page, the new price shows:


This exercise is an example of how to test, refine, and re-test. Repeat this process as needed.

More Testing Ideas

Feature

All

You Need

A finished implementation

Code

No

Difficulty

◉◎◎◎◎

---

Testing your Implementation

You've likely been testing most of these throughout your implementation -- this list will help as a final checklist of ideas to test. For each step below, test all of your use cases exactly how you expect them to function with your real customers.

 

1. Make changes to the subscription

With your test subscription, you can now test subscription management, from both your staff and end-customer's perspective. This testing should mirror all aspects of your real use case.

Important

• Test with your implemented subscription management method
• Test login method

Monetary actions

• Product Changes
• Component quantity changes
• Apply Service Credits
• Apply Prepayments
• Manual payment of invoice
• Any other action for your use case

Non-monetary actions

• Billing date changes
• Updating Payment Profiles
• Subscription Holds/Cancellations
• Custom Field changes
• Any other action for your use case

2. Invoices, emails, and dunning

Next, you’ll review and test your invoice presentation, emails, and dunning strategy. Through the testing in steps 1 and 2 above, you have already triggered a variety of emails, and in this step you will create more test emails. Test the following, as applicable:

Invoices

• Invoice presentation
• Invoice emails (both remittance and automatic subscribers)
• Invoice email language

Emails

• New Signup Emails
• Receipt emails after a successful payment
• Cancellation emails - Test by cancelling a subscription
• Expiring Card emails - Test by setting a card expiration date for the same month as the current month when testing
• Payment Update emails
• Any others, as needed

Retries & Dunning

• Dunning emails - Test by deleting a card on an automatic, already existing subscription, or by triggering a 0 net invoice generation on a subscription

3. Test integrations

This section of testing is the most open-ended. In this step, you’ll validate all incoming and outgoing data that needs to populate CRMs, GL integrations, your app, and external data storage/externally hosted pages. 

Native Integrations

• Test all relevant workflows, for any installed integrations
• Subscription creation/activation in CRMs (you tested this in step 1)
• Any other relevant items

External Systems

• Validate all incoming data is accurate
• Validate hosted data related to financial operations and reporting
• Any other relevant items

Your Application

• User access and paywall(s)
• Subscription state changes and app access (eg: canceled and past due subscriptions)
• Invoice viewing
• Any other relevant items