A thorough test plan is the best way to ensure a smooth Chargent implementation. The following steps will help you develop the best test plan for your Chargent rollout. AppFrontier recommends:
Drafting Test Cases #
Test cases are the actions you wish to perform. Make a quick list of all your functional requirements:
- Process credit card transactions
- Refund credit card transactions
- Void a processed credit card transaction
Each of these requirements is a test case that you need to run successfully in a test environment before going live. Keep a list of these test cases in a spreadsheet with a separate column for expected results and actual results so you can track adjustments required and progress.
When all your test cases have passed in your test environment (sandbox), you can deploy changes to production and run through them again before going live.
Testing for Quality Assurance #
AppFrontier strongly recommends testing your implementation for quality assurance:
- Take testing very seriously by running through each of your test cases in a test environment.
- Most successful implementations succeed due to thorough planning.
- Test changes, customizations, and upgrades in a Salesforce sandbox.
Many Chargent customers choose Chargent due to the application’s 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.
Devising a Contingency Plan #
It is best to have a contingency plan in place before you begin any implementation because:
- When mistakes and issues happen, you have a plan to address them before they happen.
- What happens if the system doesn’t work?
- How do you roll back?
- How do you process payments in that case?
It is a reality that mistakes can happen during your implementation for many reasons.
- Not everything was tested perfectly.
- Users begin using the system in ways you didn’t anticipate.
- 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 thank yourself for having an action plan.
Your contingency may be 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.
Running in Parallel #
Running two systems in parallel has many advantages:
- Ensures the new system meets all needs before shutting off the old system.
- By running systems in parallel, you have a more easily executed rollback plan.
If you are migrating data or switching from a legacy billing system to Salesforce with Chargent, we strongly recommend running the two 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 parallel to the legacy system until the new system is fully functional. Once the new system has proven itself, then and only then can you safely decommission the legacy system.
See Also #
Testing Chargent
Gateway Guides
Testing In Your Salesforce Sandbox
