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.
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.
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.
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.
It is reality that during your implementation mistakes will happen.
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.
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.
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:
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.