Warning: session_start() [function.session-start]: open(/home/content/30/7423630/tmp/sess_h0lusvmdrv6i17aeo0cft8a4i3, 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
Blog Entry Archive - TransSwipe - Merchant Services and Credit Card Processing

TransSwipe - Merchant Services and Credit Card Processing

Archive for the ‘Blog Entry’ Category

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

Facilitator fees are now free to use

Facilitator Fee

In June 2015 Dwolla rolled out new pricing. We removed transaction fees and started offering value added features and controls to our business clients.

In these new packages we focus on making the banking system, and largely ach transfers, easier for developers and businesses to use.

When our new pricing was introduced we bucketed some older functionality and some new functionality. As a company, we made 1 decision in that process that we’d like to apologize for and make a change to.

The facilitator fee was moved into the $1500+ package as a paid feature and today we’re making it free again. While I could go into the rationale behind the original decision, it doesn’t matter and it just needs to change.

What matters now is making a fix and making sure budding developers, who are getting companies off the ground, can make use of the feature.

The facilitator fee does a few things well:

  • It allows developers to build fees into their applications.
  • It allows developers to charge a fixed fee or a percentage fee for any transaction passing through their application.
  • It allows developers to build software that leverages ACH transfers, Dwolla balance transfers, credit transfers, and anything else someone could use on the Dwolla platform to move money and charge an appropriate fee.

Fees might sound bad but a tremendous number of non-payment companies charge small fees to cover operational costs or as a part of the service they provide. Many times it’s not charged to the end user.

Here are a few places we’ve seen facilitator fees used successfully:

  • Some organizations have small service charges as a part of transactions. $2 for example on each transaction keeps their technical team staffed and kids getting lunch cards loaded on time.
  • Software developers building software for third-party companies can actually build their fee into each transaction rather than charging upfront. This helps more companies get to market without loaded up-front costs.
  • Software marketplaces where the marketplace may take 10% of the original purchase price for a service ordered. This has become more and more common. We help the marketplace split the payment as the money moves.

There are some other key benefits for businesses operationally with this structure:

  • When your software application takes a facilitator fee, your company account only receives the fee and you can route the rest of the money to the person receiving the transaction. This happens regardless of whether or not it’s a bank transfer, balance transfer or credit transfer.
  • When you only receive the fee and the other party gets the rest of the money directly, that means you’re never holding your customer’s money for the purpose of transmitting it to another party. That’s a positive thing!

In closing, we put Facilitator Fees into a package when it shouldn’t have been. This is a feature that wants to be free—you want it to be free and we’ve heard you loud and clear.

Go build something great with Facilitator Fees.

Cutting out the busywork for developers with better design


 It’s easy to joke that when a bar is set low the job of the design team is that much easier. But in truth, fixing problems in design only makes the experience satisfactory, it doesn’t make it delightful.

When’s the last time you had to read instructions in order to get your job done? Were you excited about it? Likely not.

No matter your daily responsibilities, most of us have been there and done that—muddling through sites only to be left with low expectations on finding what you’re looking for and comprehending domain specific gibberish. On top of this, you’re only reading this documentation in an effort to get something else done. Sigh.

Being delightful calls for exceeding expectations. The trick is to identify expectations, flag the let-downs and improve.

Defining experience goals

Experience goals articulate how you are going to meet the business objectives, satisfy customer needs and inspire creative direction for concept development. Every designer has goals, not everyone writes them down and shares them with their team. Writing experience goals down, provides team focus and serves as a benchmark to evaluate design ideas against. I like to capture them as they come to me during discovery and then formalize them with the team at the end.

Being open to insights during discovery allows the goals to come to you.

Define experience goals for any given project early in the process—during the analysis and discovery phase—by making a note of the ‘ah ha’ moments, insightful observations of the team and customer feedback.

A few examples of our experience goals convey what is important to us as a team as we’re developing our documentation:

  • Ensure the developer documentation is a core part of the .com experience
  • Ensure it is easy to navigate and simple to find what you are looking for
  • Deliver how-to instruction that is easy to evaluate and follow
  • Clean, clear and elegant reading experience.  

However, none of these goals delight; done well, these elements should go unnoticed by a developer interacting with our page.

For us, during our developer interviews, we uncovered the importance of delivering delight.

Reduce the busy work

So how did we deliver this delight to take our portal beyond what was just expected?

Look for moments where developers expect things to be tedious and instead wow them by removing the busy work, make the processes seamless.

Developers are the first people to notice when a manual process could just be automated. Unfortunately, performing up-front tasks to get to the heart of what you’re trying to do is all too often part of the job.

Crafting and maintaining your documentation is an important foundation for a positive developer experience. Making information easy to find, understand and digest quickly is a relief, but it is the little things that go above and beyond that make a difference.

Visit our developer documentation and the first thing you will see is the code for a transfer request in the various languages that we support. In doing so we’re communicating the heart of our platform as quickly as possible—a positive first impression.

But here is what sets us apart, providing that ‘Ah! Cool’ feeling:

  • Our copy button so you can grab the code you need in one click


  • Global language selector, enabling fluid selection


  • Step-by-step guides which clearly outline the need-to-knows

GuidesWith developers, cutting out the busy work with improved design is what will make for the best possible experience.

We are never done.

As we aim to delight, reducing the busy work is the most critical experience goal for our developer audience. It pushes us to go the extra mile as a team and provides direction for how we’re going to make our platform easy to use.

Over the coming months we’re going to continue to work on making our developer experience as good as it can be. If you have feedback on our developer documentation or on how we can better improve Dwolla’s developer experience, I’d love to hear from you.

View Developer doc

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


Get to market faster with Dwolla’s bank transfer API

Invest in an integrated payment solution for your platform that allows you to maintain control of the customer experience, while reducing your compliance and processing headaches.

Screen Shot 2015-12-21 at 1.06.22 PM

Retail marketplace Jane and mobile fintech app Sweep.co were faced with a number options when selecting a solution that addressed their unique ACH processing needs. Ultimately each elected to go with Dwolla’s feature rich, easy to integrate API for one overriding reason: time to market. In addition, each placed a premium on controlling the payments experience through Dwolla’s white label service and valued Dwolla’s guidance in managing the compliance requirements. Both Jane and Sweep are able to achieve funds transfers via a trusted partner, allowing them to focus on their core business.

The same rationale applies to anyone who is looking to transfer funds electronically.  Whether you’re looking for a straightforward disbursements solution or a more holistic, end-to-end payments experience—including instant bank verification and managing compliance requirements—Dwolla’s robust payments platform allows you to facilitate payments from, to, or between your customers.

Phase 1 – Funds transfer wrapped inside of 4 endpoints

We took a phased approach to the latest version of our API. The first phase allowed platforms to process bank sourced transfers in a white label capacity, and in many cases, not requiring re-collection of the customer data already on file. It’s a perfect solution for payouts, an integration consisting of only 4 endpoints.

“We’ve seen exponential growth, and Dwolla has handled disbursements for our platform every step of the way.”

Mike McEwan, CEO of Jane

Phase 2 – Customer verification

At the completion of phase 1, moving money was limited to the receipt of funds by a customer—a perfect use case for disbursements. The second phase extended the current, phase 1 customer onboarding flow. Now, with the same #customers endpoint, we were able to provide our partner with an automated identity verification solution, accounting for the CIP data elements required for both customers sending funds and allowing a customer to hold funds.

“Dwolla was able to offer the exact service our customers wanted whereas traditional financial institutions either didn’t understand how to do this or couldn’t move fast enough.” 

Jackson Gates, CEO of Sweep

Phase 3 – Bank verification

The third phase focused on bank account verification. We released Dwolla.js—a powerfully simple integration that partners can leverage to embed an instant account verification process within their platform, or securely collect account and routing numbers. With Dwolla.js, sensitive customer financial data never touches a partner’s servers. All this, in a few lines of code.

We are never done. While we continue to migrate additional functionality over to the white label experience, such as an improved mass payment flow, we ask that you provide feedback and suggestions on the v2 Dwolla API.

Is navigating the complex world of building your own payment platform pushing your launch date back? Let Dwolla help you get off the runway.

Get started now.

Contact and integration specialist

Building tools out of blocks (at Dwolla)

This blog post comes from Devangelist, David Stancu. Check out his work on GitHub or hit him up at Awesome IT

building tools, blocks

Here at Dwolla we are building an innovative way to move money. However, thinking differently poses a challenge: we need to also create unique solutions that are best suited to our mission critical objectives. How can we do this in a time effective manner while still reaching all of our goals? The answer lies in open source software.

API V2 and SDK Support

The API team took a very data-centric approach in their decision to use the Swagger ecosystem. This let our internal engineering team focus on the API’s data and behavior first before forcing them to make considerations with regards to implementation. After they were finished, the Developer Relations team was handed the task of designing end-user SDKs for this version of the API (aka ‘V2’).


As the Developer Relations’ engineering lead, I researched the Swagger ecosystem and quickly came across the swagger-codegen project, which would use templates to generate end user SDKs in over 10 languages for any API modeled in accordance to the Swagger Spec. I immediately cloned the project and attempted to generate some SDKs for a few languages popular with Dwolla developers; namely, Ruby, Python, PHP, and Java.

There were a variety of problems with generating SDKs using swagger-codegen. To highlight a few:

  • Generated code often included syntax errors
  • Data in nested containers could not be or was improperly serialized
  • HTTP 201 requests displayed no data to the user
  • Requests that replied with an HTTP 200 and no data would throw exceptions even if the request would complete
  • No implemented OAuth stubs for Ruby or Python

Problems Shouldn’t Discourage

It is easy to see why it may have been more simple for me to just say, “well, this is going to be hell to fix, I’ll just write the SDKs individually myself.” I thought this same thing, but after taking a step back, there was no good reason as to why I couldn’t use the building blocks available to me. The strategy was to review, fix, and improve more than it was to reinvent.

Developers often feel intimidated when they read another person’s code—and even more so when they have to use that code for their own production purposes.

Even very good changes can be scary at first.

Doing two good things at once

As a developer, your problem may feel unique unto yourself, but that does not mean that the problem doesn’t share components with solutions being attempted by others. Simply put, if something is useful for you it may be useful for many. By submitting fixes to the swagger-codegen project I’ve helped not only Dwolla, but the other organizations using this software.

Swagger-CodeGen Quote

For example, OAuth is one of the most popular authorization standards for RESTful services. By adding support to this project for OAuth to certain languages, I enabled that software to help more people than it did before—it’s about community

It’s an interesting time for programmers in the workplace. The ‘open source movement’ has produced a smarter developer; one that is not afraid to look around, ask questions, and share their knowledge. This “intellectual crowdsourcing” is essential to writing robust, stable and well-audited software—and this is what we do at Dwolla every day.

Excited by what we’re talking about? Head over to our developer portal and play around.

Go to the developer portal 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

©2018 TransSwipe


Warning: Unknown: open(/home/content/30/7423630/tmp/sess_h0lusvmdrv6i17aeo0cft8a4i3, 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