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.

Overview

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.

As long as you use a test payment method against a test gateway or receiver, the transactions will be recognized as test transactions and will not be billed nor will they be sent to any remote parties.

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.

Gateway sandbox

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’s 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.

Test environment

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:

https://https-test.spreedly.com/

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.