AppFrontier

☰ Menu

Testing Salesforce Implementations Chargent


Testing Salesforce Financial and
Billing Systems like Chargent


 

Overview

Testing is recommended for any software implementation or IT project. But when it comes to implementing Salesforce financial and billing systems like Chargent, testing is even more critical.

Chargent Payment Processing for Salesforce provides billing and payment functionality, connecting your customer database (Salesforce) and payments provider (payment gateway / merchant account).

Whether you are moving an entire legacy billing system to Salesforce with Chargent, or just using Chargent for some of your staff to capture occasional payments, the importance of testing cannot be overemphasized.

Here are 3 testing plans that we strongly recommend you develop and execute as part of your Chargent implementation.


Quality Assurance Testing Plan

  • Take testing very seriously.
  • Most failed implementations fail due to lack of planning.
  • Test changes / customizations / upgrades in the Salesforce sandbox.

Contingency Plan

  • Mistakes and issues happen, have a plan to address them before they happen.
  • What happens if the system just doesn't work?
  • How do you roll back?
  • How do you process payments in that case?

Parallel Systems Plan

  • Ensure the new system meets all needs before shutting off the old system.
  • By running systems in parallel you have a more easily executed roll back plan.

 

Quality Assurance Testing Plan

Many Chargent customers choose Chargent due to the application stability and ability to build sophisticated billing and payment processing applications on top of it. We strongly recommend that a full battery of carefully planned and vetted test cases are performed in a full copy Salesforce sandbox before promoting the custom work to production.

Steps to test standard Chargent (before code customizations)


  1. Create a Sandbox org

  2. Install, setup and configure Chargent (keep notes on all of your steps)

  3. Connect to a test payment gateway

    • Be sure you are not sending to your live payment gateway, especially if you have created a sandbox from a production org that already had Chargent configured

    • "Test Endpoint" should be checked

    • If your gateway offers separate test / sandbox / developer accounts, we recommend using those for testing (instead of your live account set into test mode)

  4. Send test card and echeck transactions that reflect how you expect the system to be used

  5. Create test cases

    • Think through each and every way that you will need to produce payments.
    • Setup the Chargent Order, Opportunity or Case records in the org to reflect all of the different card types, currencies, and payment methods that you intend to use in production. If you are unsure of the requirements, meet with your business leaders for the initiative to collect them.

  6. Process (Charge/Authorize/Refund/Void) each of these test cases

    • From the Chargent buttons

    • From the recurring batch (Charge Only)
      • Set up Once and Daily transactions to be run tomorrow

  7. Review the transaction records in the Salesforce org to ensure they look as you would expect

  8. Review those transactions in the virtual terminal / web interface for your payment gateway

  9. Once the recurring transactions are validated in the org, review those on your gateway side as well

 

Optional Features: Payment Request and Payment Console

  • Send a Payment Request and complete it with test data

    • Review the Payment Request record and the transaction record in the Salesforce org, then review the transaction in your gateway's virtual terminal.

  • Complete a test transaction with the Payment Console

    • Review the transaction record in the org, then review the transaction in your gateway's virtual terminal.

    • Run an additional Charge from the Chargent Order, Opportunity or Case with the token / payment data saved by the Payment Console

 

Test Data versus "Real" Dirty Data

  • Once you are able to pass all test cases with test data, test with data that clearly represents production data (inconsistencies and all)

    • Keep in mind that production data will generally not be as clean as test data that you carefully created.

    • The best way to do this is to use a full copy sandbox as this data will properly represent your production system and data.

If you have added custom code on top of Chargent, you will need to validate / test each process that the code represents following the above recommendations, including a full-scale batch test.

Additionally, we recommend running scale tests by adding a number of orders that you would expect to be run on high water day of your billing period.


 

Complete User Acceptance Testing (UAT)

UAT should be completed on data that is representative of production data, keeping in mind that production data is usually less clean than testing data as the users of your Salesforce system have likely not been as diligent with their data entry.


Contingency Plan

It is reality that during your implementation mistakes will happen.

  1. Not everything was tested perfectly

  2. Users begin using the system in ways you didn't anticipate, or

  3. Live payment gateways sometimes behave slightly differently than their test versions (though they are not supposed to).

What is not known is where those mistakes will get caught. If they make it to production and get caught during go-live you will be thanking yourself for having an action plan in place.

It is possible that your contingency is as simple as temporarily rolling back to the old way, while the project team hardens the new system. It can be as complex as several weeks of work to rebuild and reattach the old system. Because of this reality, we recommend running the legacy system and the new Chargent based system in parallel for some time. See below for more information on running systems in parallel.

Want to know much more about contingency planning? Please see this article and video.


Parallel Systems Plan

If you are doing a data migration, or switching from a legacy billing system to Salesforce with Chargent, we strongly recommend that you run the 2 systems in parallel for at least a 30 day cycle. We would like to see customers do 90 days, however we understand that parallel systems are not efficient to maintain.

New payment and billing systems should be run in parallel to the legacy system until the new system is proven to be fully functional. Once the new system has proven itself, then and only then can you safely decommission the legacy system. This is an industry best practice and in explained in detail in the following wikipedia article.


Test Versus Live Systems

Salesforce Sandbox

Salesforce makes it easy to create a test environment using the Salesforce sandbox. With the "full copy" sandbox option, you can even create a test environment that has your actual data for more realistic testing.

Be sure to set the following in the sandbox:

  • Always check that your gateway has "Test Endpoint"=True (checked) to make sure you are not sending live transactions.

    • If you are creating a sandbox from a production instance where Chargent is already running, please note that ALL settings are copied exactly from production. So you will need to change the Payment Gateway record to test.

  • You should always use the test credit card numbers recommended by your payment gateway.

  • Disable outbound email from the Salesforce sandbox, or be sure to update the "Billing Email" field in any test records, to make sure that customers do not receive email receipts from any test transactions.

 

Payment Gateways

Most of the 20+ payment gateways that Chargent integrates into Salesforce offer developer or sandbox accounts that take just a minute or two to sign up for -- many of them you don't even need to be a customer.

These accounts are different than setting your production payment provider account into "Test Mode", and are not connected to your bank or able to capture funds from the test transactions.

Chargent recommends getting a developer or sandbox account at your gateway when doing initial testing, to eliminate the possibility of sending any actual transactions. As a bonus, this also eliminates any possibility of setting your production account into test mode when other users could be submitting real transactions to it.

Your payment gateway will have a list of test credit card / bank account numbers which only work in their developer / sandbox environment that you can use for testing. Some examples of payment gateway sandbox or test account signups follow:


Some payment gateways, such as Stripe and eWAY, have separate test credentials (api keys) but do not have a separate sandbox account to sign up for. You can create a second Gateway record in Salesforce called "Stripe Test" or "eWAY Test" to hold these test credentials.

Other payment gateways, such as Vantiv and Chase, require that you become a customer with an account prior to granting test environment credentials.