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.

Spreedly offers a test payment method type, which we call Sprel. It is only recognized by our test gateway, and is especially useful in building Offsite Payments workflows.

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.

It’s important to note that test API calls in trial accounts are free. Test API calls in production accounts, however, are metered and billed. Any threshold management or alerting must be handled programmatically by the customer.

Gateway Sandboxes

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.

Production gateways can be created in sandbox mode. Using sandbox mode on a production gateway can help uncover integration issues in complex scenarios by processing simulated card data and transactions in the authenticated environment. We only recommend sandbox mode in situations where the gateway integration is difficult and where you don’t want to execute real transactions. It is important to be aware that a gateway sandbox account may behave quite differently from the real production account.

We strongly recommend using a separate environment and gateway token only for sandbox testing. See the API Reference for details on creating a gateway token.

Note: On production accounts, API calls to gateways in sandbox mode are billable.

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.

Load Testing

Most of the time you spend waiting for a transaction to complete in a production context is the time that the gateway is processing the transaction (in other words, you’re not waiting on Spreedly). With the Spreedly Test Gateway, you’ll get nearly instantaneous responses, which are not representative of transacting against an actual gateway. With no “real-world” delay, the accuracy of the load test is greatly diminished, or potentially non-existent.

One suggested workaround that you might consider: with your unit tests, it might help to simply mock out Spreedly calls with a delay you’d expect from a given gateway (perhaps 2-5 seconds).

We understand that testing high loads before releasing a new feature or going into production is an important process for some organizations. However, it is crucial to remember that Spreedly reserves the right to throttle or prohibit testing that we deem to be excessive. We want to keep our core services up and running for everyone, and we prioritize production transactions over test ones. If you’re planning on performing high amounts of load testing through our test gateway, please contact Support to start the conversation.

Test Environments

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.