Warning: session_start() [function.session-start]: open(/home/content/30/7423630/tmp/sess_ga682a6l5b47ihc1opd44uipv5, O_RDWR) failed: No such file or directory (2) in /home/content/30/7423630/html/wp-content/plugins/simple-twitter-connect/stc.php on line 33

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /home/content/30/7423630/html/wp-content/plugins/simple-twitter-connect/stc.php:33) in /home/content/30/7423630/html/wp-content/plugins/simple-twitter-connect/stc.php on line 33

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/content/30/7423630/html/wp-content/plugins/simple-twitter-connect/stc.php:33) in /home/content/30/7423630/html/wp-content/plugins/simple-twitter-connect/stc.php on line 33
Knowledge Center Archive - TransSwipe - Merchant Services and Credit Card Processing

TransSwipe - Merchant Services and Credit Card Processing

Archive for the ‘Knowledge Center’ Category

Building your own ACH solution vs. Building with Dwolla White Label

fintech-1 copy

ACH is cheap—at least that’s what you’ll find when you Google for cost comparisons of facilitating bank transfers versus processing credit cards. However, while the transaction itself can cost mere pennies, what does it really take to get up and running with ACH for payments?

While the inexpensive per transaction cost of ACH is the siren call that draws many businesses and developers to the network, its complexities and traditional inflexibility are fraught with hidden costs and requirements that often drive hopefuls away. When you have a product you want to share with the world, you don’t want to spend tedious months building your own ACH payment solution as well.

Building your own ACH solution

One of the most common do-it-yourself solutions requires you to work with a commercial bank’s interface, uploading a CSV file that contains a batched deposit amount with beneficiary account details. Customer and bank verification is a must—and it’s on the business to handle.

Bank account verification can usually be accomplished by making micro-deposits in the customer’s account. For any miskeyed or inaccurate account numbers, error notifications will be generated. You’ll need these to be collected each day, and customers must be notified in order to resolve the issues. Finally, if you are going to handle bank information in the slightest you’ll need to understand SSL and how to properly encrypt your customer’s data.

On top of that you have to handle ACH rejection codes, fraud mitigation, suspicious activity reports, etc.

Do you have the staff to support building and maintaining your own ACH infrastructure, as well as the capacity to expand upon additional feature sets when your customers ask for them?

Dwolla White Label

Dwolla has been working on innovating the way that businesses and developers interact with the ACH network for the past five years. We’ve built a White Label API that allows you to design your ideal ACH solution, with consultative support from our payments professionals and developers each step of the way.

5 Reasons to choose Dwolla for your ACH payments integration:

1. Easy to integrate

The Dwolla API comes with clean documentation and developer resources, as well as an easy-to-use sandbox testing environment. Dwolla plays nicely alongside any existing payments technologies you’re utilizing today.

2. Customize the experience

Enable bank transfers for your application that look and feel like your brand. From account creation to payment notifications, design the ideal end-to-end payments experience for your customers with our White Label API.

3. Security matters

We built our platform with security in mind. Let us help you manage the complexities of compliance, so you can focus on what really matters.

4. Get to market faster

Cut your implementation to a fraction of the time without cutting corners. Our team of payment experts and developers will help you build programmatic payments into your platform so that you can get to market faster.

5. Predictable costs

We don’t charge a per transaction fee, we simply work with you to determine a flat monthly-rate for your custom ACH solution. Paying partners will receive priority support and access to industry professionals every step of the way.

Leverage our team and the Dwolla White Label API to get your own reliable payment experience baked into your platform or application, without needing to hire your own team of in-house payments experts.

Get started today.

5 Things you may not know about Dwolla’s ACH API

5 things blog post

As we develop our partnerships, we’re seeing exciting new ways that our ACH API is being put to use. With that, we wanted to share some items that may not seem obvious—read on to learn 5 things you may not know about Dwolla.

Did you know…You can build account-to-account transfers into your consumer application with Dwolla

The fintech revolution is here, look left and right and you’ll see new applications and platforms enabling smarter use of money, be it for investment, savings or simply paying back friends. When Dwolla was first developed we focused on putting our mobile app in the hands of users to pay their favorite businesses. Things have changed.

Today, we’ve realized the value of our API is in what others can build with Dwolla powering ACH transfers.

For example, fintech startup, Sweep needed a solution to allow its application users to move money between two bank accounts. They integrated Dwolla into their application. Now, whether a user wants to move funds from Bank of America to Wells Fargo or from Wells Fargo to a Chase bank account, they can. Better yet, Sweep will let you do this as often as possible since there are no per-transaction fees.

Summary: If you’re building an application, Dwolla’s API can enable a peer-to-peer funds transfer function between various bank accounts.

Did you know…Dwolla plays well with other payments technologies and APIs

If there’s one thing Dwolla does well, it’s bank (ACH) transfers. Programmatically or electronically bringing traditional ACH processing into the 21st century is our jam. Where do bank transfers perform best? Often times in investment platforms  or paying out vendors or contractors that fuel your marketplace or on-demand service model.

We don’t mind if you use other payment vendors to accept credit or debit card payments. We’ve partnered with a number of large marketplaces that use Dwolla exclusively for paying out their vendors, while using other payments APIs on the front end to process credit cards.

Did you know…Dwolla offers a  highly customizable White Label integration

Another value-add to partners is the extent to which you can customize a White Label payments integration. Dwolla can help you facilitate bank transfers via the ACH network for your customer through your own platform. Imagine a payments experience that feels and looks just like your website or portal—we’ve got that.

With our customizable stylesheet, one partner’s integration can look vastly different from the next. Change the fonts, alter the button colors, it’s all up to you.  We’ve built a demo of our dynamic bank verification experience so you can play around with it.

Did you know…We are compatible with mobile apps and interfaces

Mobile apps appear to be taking over the world. Sure you build a website, but the number of users accessing your application while on their phones is on the rise. Dwolla plays well here, too. Our API works with mobile seamlessly.

Sweep, who we mentioned above, built a fintech mobile application and easily integrated Dwolla to provide a bank transfer functionality. More and more, we’re seeing partners with similar needs, and Dwolla has proven a good fit for their payments.

And for our developers:
Did you know…We have RESTful API which implements the HATEOAS constraint

I repeat, we have a RESTful API which implements the HATEOAS constraint.

What does this mean? We use hypermedia, basically links & link relations, to tell you about all the actions that can be performed on the current resource, allowing you to traverse the API from a single entry point.

The entire API is discoverable starting from the root URI, documentation is not needed!

If you’ve learned something new about Dwolla’s API for bank transfers and want to learn more, reach out to one of our knowledgeable integration specialists.

Send a harmless email

Fake it as you make it: why fake services are awesome for developers


This blog post comes from Shea Daniels, a developer here at Dwolla. When Shea isn’t busy building awesome new things, you can find him out for a run. api-blue

It’s often said in life that we “stand on the shoulders of giants.” This rings especially true now that we’re in an era of abundant open source software and SaaS providers. Now, more than ever, we build applications by relying on tools and services that others have made. This may even be standard practice inside your own organization as other teams deliver functionality through a microservices architecture.

Building software by composing services is extremely powerful, but it can still be a rocky road. Several factors can make it difficult to write and test your code:

  • Complex scenarios may not be easy to test with real data
  • Running elaborate business logic may consume resources
  • Sandbox environments may not exist for 3rd party APIs

Just fake it

So what can be done to mitigate these issues? The answer is to fake it while you’re making it!

You can see this in everyday life. Whenever the real thing is too expensive or impractical, we sub it out with something fake as a stand in—think movie props or mannequins for tailors. This is also a fairly common engineering practice; my favorite examples are the boilerplate capsules used to evaluate rockets and other space hardware.

In the software world, if you practice TDD you should be familiar with the use of test doubles (mocks, fakes, and stubs) for dependencies in your unit testing code. Used instead of the real implementations of objects, fake dependencies isolate the code under test by providing predictable results given certain input. This isolation is useful for tracking down issues and fully exercising your code without complicated setup.

The same concept can be applied when developing an integration with a third party service. By building a fake copy of the web service, you gain the same advantages of isolation and repeatability as you test your application. This is especially useful if the service you’re depending on is being developed in tandem and has yet to be fully implemented.

There are some existing tools for quickly standing up your own fake services, such as Nock and Frock. But with Node.js and a few NPM packages, it’s easy enough to build your own from scratch.

In this post we’ll include:

  • An actual example
  • How to get started
  • Possible scenarios
  • Some of the downsides

A real example

Let’s break down a real example that Dwolla has recently open sourced: Nodlee. You can see it in action by checking out our instant bank account verification demo—here it’s used as a backing service.


Getting started

Nodlee is a simple web server written in Javascript and run via Node.js. It depends on the following NPM packages, which you can see in the package.json file:

minimist – argument parser library

If you haven’t used Node or express before, there are a ton of great tutorials, or you can read through the Nodlee source code to get a feel for it. The readme has a lot of great info and the code entry point is app.js.


The first thing to do when building out a fake service is to look at the documentation for the real API and experiment with the service to discover how it works. With that knowledge, you can figure out which endpoints need to be mocked and what the responses should look like.

For a simple example, here’s the Nodlee health check endpoint response: health.js

module.exports = function (req, res) {
  res.json({ healthy: true });

These responses can be as simple or as complicated as needed. If returning the same canned response every time isn’t enough, consider scanning the request for sentinel values that you define. Then you can use those values to decide which data to send back. You can even use a templating language like Handlebars for generating your responses if you want to get swanky.

Complex scenarios

For the instant account verification product we were building, even sentinel values and templating weren’t quite enough. We found that we were constantly editing multiple files in the fake service code to set up complex scenarios.

The first step to making this easier was to consolidate all of the possibilities that determined a particular scenario into a single list of options in the code: scenario.js

module.exports = function Scenario() {

	this.contentServiceId = 0;
	this.isMfa = true;
	this.mfaTimeout = false;
	this.mfaPass = true;
	this.mfaTypes = ['q'];
	this.refreshesSet = 1;
	this.refreshesLeft = 1;
	this.errorType = 0;
	this.accounts = [
			routingNumber: '222222226',
			accountNumber: '5031123001',
			accountType: 'CHECKING',
			accountHolder: 'John Wayne',
			accountName: 'Your Account #1',
			balance: '1000'

This object can then be checked in all of the service endpoints in order to determine the appropriate response. With this in place, developers could set up the flow to behave however they wanted just by editing this single file.

Sentinel values on steroids

We have local development covered now, but what about testing in sandbox environments where we can’t edit the fake service code? Not only that, but what if we wanted coverage of our flow with automated UI tests (e.g. Robot Framework)?

What we need now is a service with a memory longer than a single web request and a way for automated tests to trigger whatever scenario is needed. This is where the minimist and node-cache NPM packages come into play.

With minimist, we are able to take certain inputs in a web request and treat them as if they were command line interface options. Those options can then be translated into order to set the properties of the Scenario object we’ve just discussed: 

var scenarioData = optionsParser.parse(req.body.someInput)


exports.parse = function(options) {

	var data = new Scenario();

	if (options.indexOf("-") < 0) {
		return data;

	var args = parseArgs(options.split(' '));

	if (args['nomfa'])
		data.isMfa = false;


	return data;

Now that we have the options set for the scenario we want, we use node-cache to persist it across web requests: scenarioManager.js

var cache = new NodeCache({ stdTTL: 900, checkperiod: 300 });

exports.set = function(...) {


	cache.set(userSessionToken, scenarioData);
	return scenarioData;

Now we can use the cache to access the scenario that’s currently being tested at any point we need to build a response: getMfaResponse.js:

module.exports = function(req, res) {

    scenarioManager.get(req.body.userSessionToken, function(scenarioData) {

        if (!scenarioData.mfaTypes) {
        } else if (scenarioData.mfaTypes.length < 1) {
        } else {

The downsides

As with anything, fake services are not a silver bullet. There are a few caveats to keep in mind:

  • Are you sure you understand the real service well enough to build a fake version of it?
  • Watch for edge cases where you may not be duplicating the behavior of the real service
  • If you do find edge cases, be sure to cover them with appropriate tests; manual testing with your fake service is not a replacement for good test coverage with unit/integration tests
  • Plan for regular maintenance of your fake to keep up with any changes in the interface or behavior of the API you depend on
  • Using a fake does not relieve you from the task of running your code against the genuine article

The last bullet point is important since there’s a large difference between “should work” and “actually works.” At some point in your workflow you’ll need to test the full production stack!


Here at Dwolla we’re committed to making developers’ lives easier by providing a great API for moving money with ACH transfers. We’ve found the concept of fake services to be invaluable in making this happen. If you found this useful, please share this article and comment with your own experiences. Happy building!

Check out the documentation

5 Qualities of a Good Payments API for Bank Transfers

Payments API

There are APIs abound for integrating credit card transactions into your platform or application, but what about an API for ACH transfers? Here’s what you should be looking for when determining if an ACH solution is right for you:


ACH transfers aren’t always a bed of roses, especially if you’ve explored building your own solution with a financial institution. What you save in a relatively low initial integration cost can add up in dedicating months of your time and energy to meeting all of the compliance requirements and building all of the processes necessary to pass any financial industry test. That’s why many companies and developers are turning to software companies that have built and open sourced their own ACH APIs. These APIs allow you to tap into their network of experts and functionality in order to make ACH transfers work for you, in a way that fits with your business and customer needs.


If you have a well-established product, you’ve spent the time, money, and burned the brainpower growing your customer base and brand. You may be leery of introducing your customers to another platform to create another account for making or receiving payments via your app or site. A quality API allows for various customization options and control, and is adaptable for specific use cases and scenarios. The ability for an API to scale alongside your business—whether it’s on the front or backend of your product—can make for a winner.

Intuitive and complete documentation

Nothing is more irritating than searching an entire site or forum for what you need, bouncing between different tabs, and trying to piece together information. Software providers that have removed the busy work, and put in the time to accurately and simply document their APIs in a way that a developer would need to read it while coding alongside is invaluable.

Working examples

Finding a payments API with working examples of its integrations out in the wild is always attractive. The more variety of use cases, the better—these use cases demonstrate the possibilities after putting a little creativity into developing a tailored solution that works best for your unique needs.

Great support

When developing payments into your platform, there may be questions that you just need to float by someone that works on that API for a living. There’s great value in finding a service that is committed to getting you and your product to market before you rip every last hair out trying to Google the answer.

Are you looking for a better ACH solution? If so, we’d like to invite you to contact one of our integration specialists so we can introduce you to a solution that fits your needs. Or, take a tour of our developer portal, where we offer extensive API documentation, starter guides, and other resources to help you begin building.

Let's talk aCH payments

6 commonly asked questions about integrating Dwolla, answered

Question Mark

If you’re considering a new payments integration, we’re here to help. We’ve pulled together a list of commonly asked questions so you can better understand how Dwolla will fit into your platform.

If you’re building a platform for investing or an app that needs peer-to-peer bank transfers—we’ve got you covered. Below are some questions to guide you.

1. Do my users need to create a Dwolla account on top of the account they create on my platform?

We offer varying levels of payment integration packages, each with different features.

If you’re interested in a White Label payment solution, then users do not login to a Dwolla branded gateway to create an account; they simply create a Dwolla account on your platform, accept Dwolla’s TOS and privacy policy and link their bank account therein.


Here’s an example of a savings application that uses White Label.

If you’re interested in a co-branded payments solution, then users are directed to establish a Dwolla account to make payments. Our OAuth account creation flow does a great job of getting users onboarded quickly.

Take a look at how this platform for paying referees uses the Dwolla OAuth integration.

2. Can I facilitate transactions between two parties without touching the funds?

Yes, you can. With the Dwolla API you can build an application that allows you to simply facilitate transactions. This means the funds never have to touch your Dwolla balance or bank account as the owner of the application. You’re simply providing the means for the money to be transferred.

3. What are your business day cut-off time for transactions?

4pm CST; we’ve provided clearing times that are very competitive with industry standards.

4. Do you have a testing environment? If so, how do I get set up and how does it work?

We do have a sandbox environment. It’s free to access, and many partners like to play around in it while researching their solution. In the sandbox environment you can do all the same things you would in production, however all data is fake and no actual money is touched or moved.

5. What level of support do you offer for integrations?

Our team wants nothing more than to see the Dwolla API put to use in diverse, innovative ways. We’re always here to help, and recommend starting at the discussion board with a problem. If you want priority, direct access to developers and support, we hook you up with a dedicated account manager in our custom payment packages.

6. What are your integration or set-up fees?

Many SaaS-based pricing models include expensive upfront set-up or integration fees. At Dwolla, we’re just concerned with helping you get your application to market quickly. As mentioned above, we even have a pretty slick sandbox environment for you to start building prior to entering into a contract. Once you’re ready to launch in production, a flat monthly fee will begin.

For more insight on integrating a bank transfer solution, take a look at what partners are saying. If you’re interested in learning more, chat with an integration specialist now.

Drop us a line

For beginners: How do ACH payments work?

ACH for beginners

We mention the acronym ACH quite a bit on the Dwolla blog: ACH payments, ACH Payouts, and API for ACH. But I realize that this term may not be crystal clear for those who don’t deal in payments on a daily basis. We’re taking a step back to break down how ACH payments work.

What Does ACH stand for?

ACH stands for Automated Clearing House.

No, the Automated Clearing House is not a physical place; it’s an electronic network that allows banks and their customers  to send funds between one another in the United States. Basically, when you pay a bill online and opt to use a ‘bank account’ rather than a credit card, your payment is being processed through the ACH network. By entering your account and routing number instead of your credit card number, you’re initiating an ACH transaction.

Other acronyms to know: ODFI or Originating Depository Financial Institution and RDFI or Receiving Depository Financial Institution. These two acronyms refer to the bank or credit union that will eventually send or receive funds.

How does ACH work?

For a debit (such as paying a bill using ACH): Here we’re assuming you’ve previously connected your bank account and routing number, and set up auto-pay. Your utility company’s bank sends an ACH debit entry to their ODFI. The ODFI and RDFI ensure that the funds are available in your bank account and then process the transaction so that the funds are sent to the utility company’s bank account. While the transaction is being processed, the transaction is known as a ‘pending ACH transfer’.

For a credit (such as receiving your paycheck via direct deposit): A credit, or receiving money to your bank account works similarly to the above, except in reverse since you’re receiving funds. You simply provide your account and routing number to your employer, and when payday comes, your employer’s ACH processor initiates the funds transfer (via an ODFI) to your bank account using the ACH network.

For more detail, check out these rules from NACHA.

Who’s using ACH payments?

ACH payments probably creep into your day-to-day life more than you realize. Employers use ACH to pay employees, utility companies use ACH to collect on usage, various platforms use it to pay their contract workers, the list goes on. In 2012 the Federal Reserve reported that about 22.1 billion transfers were made annually.

According to a report from the Federal Reserve, there is less fraud involved in ACH transfers as compared to credit card transactions.

How can my business use ACH payments?

So ACH transactions sound pretty interesting right? You can send funds between bank accounts, and that’s cost-effective and useful. However, building your own infrastructure to handle processing bank transfers, rejections and corrections can be costly when navigating compliance and security requirements. With Dwolla, we make integrating ACH payments into your platform easy and seamless, and we help you manage fraud and compliance considerations.

We have a wide variety of partners leveraging Dwolla in innovative ways to bake ACH payments into their platform:

Curious how you might be able to power payments for your business using Dwolla’s powerful ACH payments tools? We have integration specialists to help.

reach out now


Benefits of using an event sourced architecture

This is a blog post from Corey Oliver, one of our software engineers at Dwolla. To hear more from Corey, follow him on Twitter at @coreyjonoliver or check out some of the work on his blog

API collaboration gears

Where’s the money coming from and where’s it going? The solution Dwolla implemented to answer this question is an event sourced architecture, which has shown adaptability in many use cases.

This post will walk through why Dwolla chose an event sourced architecture over other solutions.


There are two primary approaches or solutions we can consider for tracking money, each with their own pros and cons.

A current-state based architecture is where the application has access to only the current “state of the world.” A good example is storing the balance for an account, say $20, and then replacing that balance with $30 when the account is sent $10. The account balance recorded after each change is the state of the current world aka current-state.

This is the go-to for typical CRUD apps. For one, this solution is well known among existing tools; it is also straightforward making it easy to retrofit to older solutions used by a business.

Now consider events, which signal something that has happened in the outside world. Each event stores its own payload containing information on what happened and at what point in time it happened. The payload is also immutable—it can’t be changed.

An event sourced architecture is one where all state changes in an application are stored as a sequence of events. Many domains in the real world behave like this. Take balancing your checkbook—each debit or credit to your account corresponds to a line in your checkbook. Summing all lines should yield the current balance of your bank account assuming all information is accurate.

Both of these solutions present their own collection of positives and negatives.

As with many things in business, solutions are highly dependent on the problem at hand. For most problems a business will encounter, a current-state based architecture is a solid foundation for building a solution.

But let me emphasize the caveat most. While a current-state based architecture is arguably the most widely used pattern for solving certain business problems, more effective solutions exist.

An event sourced architecture is powerful

event sourced architecutre graphic

Building an event sourced application is less straight-forward than its counterpart, current-state based architecture. It’s also not an option many software developers or product owners are familiar with.

  1. Applications that are less coupled are not as dependent on one another. This architecture property enables Dwolla to do significant horizontal scalability, and can also provide redundancy and resiliency in cases of system failure or degradation.
  2. Using this system, events compose an audit log of actions that have occurred in our system. No change in the system occurs unless an event was recorded. Also, we not only have the ability to provide the current state of the system, but also know how and by what means it got there.
  3. You can build applications on top of events that synthesize into the event data.  Some examples of this include:
  • reconciling user financial data against funds held at  a financial institution
  • identifying fraudulent activity
  • displaying transaction records and payment activity

Why should you care?

Finance is a crucial part of everyone’s life. This includes account holders at Dwolla. Using an event sourced architecture allows us to track financial events and generate the audit log to confirm them. It maintains the integrity of the information.


So where’s the money? Tracking money in a system is a complex endeavor. At Dwolla, an event sourced architecture has proven beneficial over alternative methods for modeling money ownership—organizations should consider their needs and determine whether an event sourced architecture is an effective and competitive solution for addressing their business problems.

Read more from our engineers on Medium

Gym membership payments made easy with platform WODTogether

Gym management platform, WODTogether, integrated Dwolla’s bank transfer technology (in two weeks) to save its users money in collecting recurring membership fees.


According to Forbes, there are now nearly 11,000 CrossFit gyms worldwide, up 22-fold from nine years ago. That’s a massive market that’s only growing larger. With the exploding number of CrossFit gyms and gym go-ers, three friends saw an opportunity to build software to ease running a training facility.

About WODTogether

WODTogether provides software to help run gyms, from membership management and billing features to coordinating group fitness facilities. Self-proclaimed “CrossFitters doing CrossFit, and coding”, Brian Holub, Michael Starich, and Adam Holub have a built a solution that meets all needs.

For a flat monthly fee, registered gyms get the support they need from a gym management software, including workout tracking, scheduling, tools for athletes and billing management.

The Problem

To create a holistic solution, WODTogether needed to offer the best possible payment options for gym managers. They had previously integrated credit card payments, but—as most business owners can relate to—those fees were high and hard to for gyms to manage so WODTogether wanted to provide an additional payment choice.

“The payments industry can be complicated, frustrating, and expensive for our users. We’re always looking for better options, and Dwolla’s fees (or lack thereof) is a game changer. The great API and documentation made it a no brainer.”

Brian Holub, CEO

b headshot - WODTogether

The best option would be easy to integrate, simple for users to get going, and cut out those percentage-based fees gym owners stress over.

The Solution

It was clear WODTogether needed a payment integration that was simple, straightforward in cost, and would allow for payments for both recurring services as well as one-off expenses. Dwolla met these requirements, and then some.

Dwolla’s bank transfer software allowed for:

  • Easy on-boarding of members—entering banking information is easier than inputting credit card information, no need to pull out the wallet and enter a string of 16 digits from a credit card
  • Payment of recurring gym membership fees
  • Collecting on individual expenses like refreshments, supplements, apparel, private training, or special event fees
  • A quick integration turnaround time from the WODTogether teamce

As an additional bonus, WODTogether use Next Day Transfers, so funds are moved in 1-2 business days, which—in their words—“crushes” traditional ACH payments processing times.

WODTogether dashboard

Just like a good CrossFit workout, the team at WODTogether needed an efficient and effective integration. Using Dwolla’s PHP Library, their team was able to integrate our co-branded solution in just a couple weeks. A quick turnaround time for a very lean development team.

Their biggest point of delight: the test environment. They were able to build and test the solution in UAT, allowing a quicker ramp up time.

Now, users simply select to connect their bank account via Dwolla, and are sent through the OAuth flow.

Fast, Simple and Focused

WODTogether touts software that is fast, simple and focused, helping gym managers and coaches keep ahead of their demanding day-to-day. To provide the best possible solution, WODTogether integrated Dwolla.

Now as gyms scale, they can avoid losing valuable profit to credit card fees and they’ll be able to count on their users’ membership payments coming in regularly—thanks to recurring payments in the API.

“CrossFit gyms vary greatly in size, from as little as a few thousand dollars to tens of thousands in monthly revenue. Whatever the size, gyms stand to save hundreds of dollars a month if they accept payments via Dwolla. We’re now able to offer greater value to our members.”

Michael Starich, President (and gym owner)

m headshot - WODTogether

Curious how your payments could improve? Drop our consultants a line.

Read out to Learn more, blue

Arbalest: open source data ingestion at scale

If APIs are the manifestation of products and services that enable innovation and collaboration, open source is the foundation upon which APIs are built.


Open source software development is arguably one of the greatest examples of human collaboration. Since the release of the GNU project in 1983 and Linux in 1991, to today powering billions of mobile devices, open source powers the software around us. From the programming languages we use to how we run software, Dwolla has immensely benefited from open source.

In addition to benefiting from open source software, we are excited to “pay it forward” and contribute back to the open source community. Open source software encapsulates shared experiences and problem solving. We not only want to share what we have learned, but also learn from the community’s feedback and contributions.

Processing event streams

One area we are contributing to is data and analytics. Events are the atomic building blocks of data at Dwolla. We use some great open source tools to process, analyze, and visualize this data. However, we needed a way to query all this data interactively, using the flexibility and scale of Amazon Web Services.

We are excited to release Arbalest, a Python data pipeline orchestration library for Amazon S3 and Amazon Redshift. It automates data import into Redshift and makes data query-able at scale in AWS.

Arbalest is the backbone of our data pipeline architecture and has enabled Dwolla to query and analyze billions of events. In a few lines of code it takes care of:

  • Ingesting data into Amazon Redshift Schema creation and validation
  • Creating highly available and scalable data import strategies
  • Generating and uploading prerequisite artifacts for import
  • Running data import jobs
  • Orchestrating idempotent and fault tolerant multi-step ETL pipelines with SQL


Arbalest is a lightweight library designed to be composed with existing data tools. It is also written in Python, which is arguably a de facto programming language for data science. Arbalest embraces configuration as code. Unlike sometimes unwieldy configuration files, an Arbalest pipeline is only a few lines of code that can be tested, packaged, and reused. Finally, it automates the complicated and potentially brittle process of ETL (extract, transform, and load).

We hope Arbalest enables data analysts and developers to spend less time managing their data and more time answering questions.

Use cases

Why use Arbalest? Arbalest is not a MapReduce framework, but rather designed to make Amazon Redshift (and all its strengths) easy to use with typical data workflows and tools. Here are a few examples:

  • You are already using a MapReduce framework to process data in S3. Arbalest could make the results of an Elastic MapReduce job queryable with SQL in Redshift. You can then hand off to Arbalest to define additional ETL in plain old SQL.
  • You treat S3 as a catch-all data sink, perhaps persisting JSON messages or events from a message system like Kafka or RabbitMQ. Arbalest can expose some or all of this data into a data warehouse using Redshift. The ecosystem of SQL is now available for dashboards, reports, and ad-hoc analysis.
  • You have complex pipelines that could benefit from a fast, SQL query-able data sink. Arbalest has support out of the box (arbalest.contrib) to integrate with tools like Luigi to be part of a multi-dependency, multi-step pipeline topology.

Getting Started

Arablest is not supposed to replace existing data tools, but work with them. In our initial release, we have included some batteries, for example, strategies for ingesting time series or sparse data and support for integration with an existing pipeline topologies. We have described a few use cases, but are excited to see more applications of Arbalest in the community.

For more information on Arbalest, be sure to install the package, check it out and star it on GitHub, read the documentation, or look at our presentation from Tableau Conference 15.

fred galoso

This blog post shares insights from Fredrick Galoso, a software developer and technical lead for the data and analytics team here at Dwolla. Fred has led the creation of our data platform, including its data pipeline, predictive analytics, and business intelligence platform. In his free time he contributes to a number of open source software projects, including Gauss, a statistics and data analytics library.

View Arbalest on GitHub now

Bank account verification and transfers in just a few lines of code


By dropping in a few lines of code, you can now power bank account verification and transfers on your platform as a user of Dwolla’s White Label service.

  <!-- Include dwolla.js on your page -->
  <script src="https://cdn.dwolla.com/1/dwolla.js"></script>


Within seconds, your White Label integration can access Dwolla’s Instant Account Verification process through dwolla.js. Your customers simply select their bank, log in with their bank credentials, link the bank account they’d like to use and they are on their way to quick and easy payments inside your application.

<script type="text/javascript">
$('#start').click(function() {
  var iavToken = '4adF858jPeQ9RnojMHdqSD2KwsvmhO7Ti7cI5woOiBGCpH5krY';
  //Call function to start/render IAV in the container specified
  dwolla.iav.start('iavContainer', iavToken, function(err, res) {
    console.log('Error: ' + JSON.stringify(err) + ' -- Response: ' + JSON.stringify(res));


Not a Dwolla White Label partner? With the release of dwolla.js, you still have the option to securely pass your customer’s account number and routing number to our Funding Sources endpoint without them ever hitting your server. This provides you the peace of mind that your customers’ information is safe while getting set up on your application, and allows you to send payments to that customer.

<script type="text/javascript">
$('form').on('submit', function() {
  var token = 'Z9BvpNuSrsI7Ke1mcGmTT0EpwW34GSmDaYP09frCpeWdq46JUg';
  var bankInfo = {
    routingNumber: $('routingNumber').val(),
    accountNumber: $('accountNumber').val(),
    type: $('type').val(),
    name: $('name').val()
  //Call function to attach bank account using form values
  dwolla.fundingSources.create(token, bankInfo, callbackHandler);
  return false

function callbackHandler(err, res) {
  $div = $('<div />')
  var logValue = {
    error: err,
    response: res


This is a breakthrough for making bank transfers accessible and flexible for businesses and developers everywhere.

Go use it

Interested in building with our Dwolla white label solution? Chat with an integration specialist.

©2018 TransSwipe


Warning: Unknown: open(/home/content/30/7423630/tmp/sess_ga682a6l5b47ihc1opd44uipv5, O_RDWR) failed: No such file or directory (2) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct () in Unknown on line 0