Creative Construction in the Dwolla Sandbox

Whether you’re looking to build the next game-changing application or simply want to automate your existing business practices away from issuing checks, the Dwolla Platform has many offerings to meet your payment needs.

They say that Rome wasn’t built in a day and, likewise, it will take some nurturing and extensive testing to go from ideation to production-ready. Luckily, with the Dwolla Sandbox, you have the ability to test the functionality and enhancements of your ACH payments integration.

Our extensive sandbox helps provide developers and business units alike with an experience that can help inform decisions when assessing an API for transferring funds. From discovery, to implementation, to post-go-live, the best way to determine if an API integration is right for your business is to try it out.

End-to-End Testing

Engineering teams are key stakeholders in the assessment/buying process for an organization looking to implement new technology. Their feedback can be crucial to the success of newly implemented automation for a company. Because of this, Dwolla takes pride in being developer-friendly through easy to navigate documentation and a flexible payment API. So let’s walk through what a developer might experience through their journey into the sandbox.

Discovery

When considering switching to an API to assist in your funds movement procedures, one must consider that the integration is not only a monetary investment, but also a time investment as it requires engineering time to develop and maintain. With this in mind, it makes sense to try before you buy, if you can.

For this reason, we have tried to make access and the onboarding process to the Dwolla API as easy as possible with a simple sign-up experience and a replica of the production environment. Providing only your name and email address, you can start exploring our API. From here, you can take a look at our developer docs to understand more about the product, browse through our client libraries or get up and running in minutes with our extensive Postman collection.

After taking an initial look at the docs, you may have decided that Dwolla might be a good fit for your company’s use case. Explore every API endpoint and easily create, read, update or delete resources. Being able to build in this manner allows you to effectively test the general flow that your own customers will go through and simulate the behavior of the API. These activities include:

• Creating users
• Adding and verifying bank accounts
• Initiating transfers
• Managing webhook subscriptions
• And more

Being able to make the connection between the developer docs and actually seeing results can help move your project forward.

Thoughtful Testing

While completely understanding how an API fits into your application’s use case is priority number one, you should also be aware of how the API behaves in the sandbox.

Dwolla has a RESTful API, meaning that as a developer, you can expect the Dwolla API to follow best practices for RESTful design. When testing the Dwolla API, we recommend keeping tabs on some important considerations, including the expected functionality, performance, security, reliability and negative testing.

Performance

When you create a request, what is the response time? An API should be able to quickly return a response, as to not hold up further downstream actions.

Functionality

So you’ve received a response from the API, but what if it’s not something that you expected? Since the Dwolla API follows REST principles, you can expect resource creation requests to return a response with a link to the created resource in the location header. You should also expect responses to be structured in JSON format.

Reliability

Being able to repeat actions over and over without failure is paramount to the success of the aggressive growth you are looking to foster within your application. When testing in any sandbox environment, it’s always good to be on the lookout for downtime you may experience. Luckily with Dwolla, we pride ourselves on having 99.9% uptime, so you shouldn’t experience many server errors. Another scenario you can test is expecting and testing what load may be like during peak times in the sandbox, which can also help shed light on the reliability of an API.

Security

When sending sensitive data between your application and Dwolla, enforcing TLS >= 1.2 ensures API clients are communicating over a secure channel. Trust and security go hand-in-hand, which is why Dwolla leverages with OAuth2 protocol for Authentication (identifying who the client is) and Authorization (determines what the client can do). This short-lived tokenization methodology and granular permission scoping decreases the risk of any single authentication token being exposed.

End-to-End Beta Testing

While the Dwolla Sandbox is an entirely separate environment from Production, this doesn’t mean that testing can’t happen. Moving real money and sending real Personally Identifiable Information (PII) can be something that doesn’t need to happen until you’re actually using the API to generate revenue in a live environment. Allowing the sandbox environment to handle extensive tests ensures you’re not actually exposing yourself to potential risk.

As an example, let’s imagine testing an ACH transfer failure generates a return code, such as `insufficient funds.` Thinking through how to test this scenario in real life can be problematic — draining your own bank account balance and incurring an overdraft fee is completely unnecessary when you have access to an environment that can simulate the exact behavior with test data.

Being able to test the resiliency of an API in multiple facets before going live with the product can reduce the amount of friction points that your end users may experience when being onboarded and interacting with your application.

Edge case testing can be covered in multiple ways in the Dwolla Sandbox. Here are a few:

• Simulating various customer identity verification statuses without sending PII
• Adding and verifying bank funding sources using test credentials
• Processing transfers and simulating ACH processing
• Simulating transfer failures and ACH returns
• Negative testing
• And many more

Extra Features

Dashboard

Another tool that can be test driven in sandbox environment and be a value add in the production environment is the Dashboard. The Dashboard allows developers and business units alike to explore created resources within a graphical interface. From managing customers and transfers to managing webhook subscriptions, this tool is a powerful view into the payment activity happening with your application and can be used to manage your integration at a high level.

Integrations

With the launch of integration partners, you can mimic the functionality aspects of the integration.

Looking for a streamlined approach to adding and verifying bank funding sources? Try using the Plaid integration. Wanting to keep your bookkeepers content with the debits and credits of your payouts? Test out the QuickBooks integration. All of these integrations are compatible with the Dwolla Sandbox environment, which can help deepen the level of understanding of how Dwolla’s technology might be able to support your business’ needs.

Building with the Sandbox

The Dwolla Sandbox is a resource that can help you perform many actions. From simply visualizing the API within your application, to helping give more insight to your decision making process, to building a working prototype, the sandbox environment is a flexible resource that can help bring your ideas to life in a more timely and consistent manner.Sign up and start building in minutes.