Testing on Spreedly
Testing your integration with a remote service like Spreedly can be tricky. Added to this is that Spreedly itself is a proxy to other remote services and you may be wondering what to make of it all. This guide attempts to answer such questions as well as provide a clear process for testing transactions against your Spreedly configuration.
By default, working through the getting started guide creates a test gateway and test payment method in your first environment. These two items form the basis for testing in Spreedly.
The Spreedly Test gateway acts and behaves just like a production gateway and supports both direct and offsite gateway functionality as well as 3D Secure and bank accounts. Creating a test gateway will allow you to test all possible payment flows and is the first step in testing. A test gateway will not let you transact with live data, so you need to create test payment methods to work with the gateway. (The same is true of the test receiver type).
To create a test payment method, use the standard payment method collection process specifying a test credit card or bank account number instead of a real number. These will automatically be recognized as test payment methods by Spreedly and will be allowed to transact against the test gateway.
Once you have your integration working with test data, it should work seamlessly with production gateways and real payment types. If you are experiencing issues against a production gateway or receiver you can use transcripts to understand where the issue is. Though you may be used to further testing against a gateway’s sandbox environment, we recommend against it.
Sometimes we’re asked about using the test environment at a particular gateway. We can certainly understand the request; as a customer, you want to know that a given gateway will work in production. And a typical approach is to run some tests against a sandbox account to make sure everything is kosher. One of the main difficulties though is that for many gateways, the sandbox account behaves quite differently from the real production account. We have found over the years that gateway sandbox accounts can give one a false sense of security.
The real goal is to know your integration is working with the real production account, not a gateway’s sandbox account. We see this as one of the primary goals of our business. It is part of the work we do so that you don’t need to write tests for each of the gateways we support. Our goal is for you to test against our Test Gateway and then know that the code you’ve written should work with any of the production gateways we support.
Unit tests with Spreedly
Testing against a remote service in your automated test suite can be difficult. Do you invoke real API calls within your tests which can greatly reduce their speed of execution? Do you mock out the remote service which in and of itself involves some development work and reduces the efficacy of the tests?
We recommend a hybrid approach, taken from ActiveMerchant library to which we contribute:
- Maintain a set of unit tests that mock out the main Spreedly API endpoints you’re using. These tests execute very quickly and provide good peace of mind that no regressions have occurred with each incremental change to your code base.
- Also maintain a set of “remote” unit tests that actually hit the Spreedly API (using test data). These tests will execute much slower, so the expectation is not that they’re run on every code change. Run them on major milestones to ensure continued compatability, or run a subset of them to verify that the modified portions of your system are still operating as expected.
In Spreedly, there is no such thing as a test environment with special properties. It is a recommended practice to create an environment named “Test” in which you will create a test gateway and run test transactions. However, if you were to add a production gateway to that environment, it would be allowed and real transactions would be executed.
Keep this in mind as you work with environments - all environments are created equal and will allow billable transactions.
Testing SSL connectivity
Periodically, Spreedly will update our SSL configuration due to changing security requirements. When this happens, the new configuration will go live first to the following URL:
When you receive an email regarding an upcoming change, you will want to verify that your browser or client library can successfully negotiate SSL with this subdomain prior to the effective change date in the email.
This test URL supports three output formats, so you can use the one that makes sense with your connection method:
You should see the following message, along with details about your protocol and cipher suite:
Your client successfully negotiates TLS with Spreedly!
If you do not receive this message, consider upgrading your client or contact Spreedly support.