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

TransSwipe - Merchant Services and Credit Card Processing

Archive for the ‘API’ Category

FiSync and the Federal Reserve’s role in faster payments

The last week marks some memorable things:

  • 1 million accounts will have been created through the Dwolla platform
  • Billions of dollars will flow through Dwolla this year
  • 30% month over month revenue growth for nearly a year

Frankly, the third is what I’m most proud of. Releasing our white label products has been a great accelerant for our business and our customers’ businesses. Our focus has been to provide companies and organizations with an API to help move money more easily and get their new products to market faster.

This work, and all of the work that precedes it, has given us the opportunity  to contribute a detailed proposal (it’s 164 pages) to the Federal Reserve’s Faster Payment Task Force.

Advising on a better payment system

Last year, the Fed called on the industry to get its act together and join the rest of the world by creating an improved payment system for the United States. Over 500 stakeholders, payment experts, consumer groups, and regulators raised their hands and the Faster and Secure Payment Task Forces were formed. With the Fed’s help, the industry has created an effectiveness criteria and process to assess new payment systems—this is what Dwolla submitted to last Friday. A better payment system is also what we’ve always cared about building.

Why we choose to contribute

The industry is in a much different spot than it was 4 years, 2 years ago, even 6 months ago. The Task Force’s submission process hopes to help drive a kind of singularity in payments, where disparate innovations, ideas, and motivations converge to provide a new platform for money movement in the United States. When the Task Forces releases their final report early next year, they will have helped create a new market virtually overnight.

dwolla fisync federal reserve faster paymentsOur submission lays out some straightforward ideas for a faster payment system in the U.S. We know how this works because we already built one. It’s called FiSync and many of you may have already used it. Our submission reveals a lot about how FiSync works today and how it could work tomorrow inside an improved national payment system. I’m particularly excited about the path it paves for financial institutions to enjoy the type of platform growth we’ve seen over the years.

FiSync is a great technology. It assures real-time availability of good funds 24/7/365 to end users and is a tremendous leap forward in speed and security over today’s bank transfer system. Building it allowed us a very useful role in the payments world and forwarded an agenda we care about most: building the ideal way to move money.

Still the real-time payments landscape hasn’t accelerated like we thought. Maybe it’s our tech-centrism, but, we/I thought that if we built the best technology everyone would just use what we built. Instead of hoarding a technology that may or may not be relevant tomorrow, we believe sharing our ideas through the proposal will bring about a market for it to thrive. The more we listen and collaborate, the sooner everyone gets faster and more secure payments.

The thing about innovation is that it tends to occur and reoccur in the places that are built to nurture it. It’s time we hand off and share this innovation with the Task Forces in hopes that it accelerates how fast the market delivers faster payments at scale. We’re appreciative of the Fed for giving us the opportunity to help and the forum in which to do so.

For the time being, we’ve made sure our branded products at Dwolla.com and our white label APIs are ready for additional faster payment connections. So as new systems come online everything just gets faster without requiring those building on Dwolla to change a thing.

My final thought

One of the most exciting days in this company was getting FiSync to work for the first time. I wasn’t convinced originally I was looking at a production system until it was redone a few times and I took the time to log into my Veridian account. This was the first time we actually realized the money was moving faster than the website would load.

That feeling is something I’ll never forget. Equal parts fear and excitement but a healthy realization that this is just how it should work. Payments should be this fast and we think this step is the best way to get faster payments to everyone.

I thought, on a day like today, I’d be celebrating a million accounts and the billions of dollars customers are moving  through Dwolla, but in reality I’m just appreciative of the opportunity and am hopeful that all of this gets us one step closer to the ideal way to move money.

If you’d like to learn more, check out a couple links about Dwolla’s FiSync, the state of real-time, and the Fed’s Faster Payment Task Force:


Bank account balance as an API endpoint

Posted in API, API help, Blog, Developers, Dwolla developers, endpoints, Product Updates on April 12th, 2016

We’re making a new feature available for white label customers that lets them ask for users’ permission to check the balance in their bank account.

Dealing with returns is one thing and we can appreciate that but there is a great deal of applications where this can be valuable for a business or developer:

  • Mitigating risks when pre-funding. Some businesses make the choice to pre-fund accounts before the transaction clears. If that is done the balance endpoint can provide a view into the risk the business is really taking.
  • Mitigating risks in trading environments. One of the problems in a trading environment is reconciling what someone says they have when they make a trade, and what they actually have. Many times the accounts for trading purposes are segregated and intended to be sacrosanct but programmatically checking the balance of the associated account that provides liquidity for trades has previously been incredibly hard.
  • Other things we haven’t thought of yet. It’s important from our perspective to give developers and businesses a platform to innovate with. Users of white label software platforms can grant this permission if they find it valuable to do so given the features associated with the platform they’re using.
  • Following the trend that the bank account is transforming into the pre-loaded account. This feature gives software developers the ability to check the bank account balance the way pre-funded account balances are checked, similar to how checking a balance in a Dwolla account works in our V1 APIs.

So how does it actually work?

Once a software application gets the permission from the account holder and the funding source is added to a white label application through instant bank verification, the developer gets a GUID that represents the account. It looks like this:


That is utilized in the /funding-sources/ endpoint to request balance for that authorized funding source:


By adding ?balance=latest to the end of the request the application is requesting the latest balance. Additional data is returned to the API call as a result. Here is a sample of what that additional data looks like:

"balance": {
    "value": "107.28",
    "currency": "USD",
    "lastUpdated": "2016-04-09T00:12:43.527Z"

The full response would look something like this:

  "_links": {
    "self": {
      "href": "https://api.dwolla.com/funding-sources/692486f8-29f6-4516-a6a5-c69fd2ce854c"
    "customer": {
      "href": "https://api.dwolla.com/customers/36e9dcb2-889b-4873-8e52-0c9404ea002a"
  "id": "692486f8-29f6-4516-a6a5-c69fd2ce854c",
  "status": "unverified",
  "type": "bank",
  "name": "Test checking account",
  "created": "2015-10-23T20:37:57.137Z",
  "balance": {
    "value": "107.28",
    "currency": "USD",
    "lastUpdated": "2016-04-09T00:12:43.527Z"

This new feature will be made available to white label customers who are in our custom package.

Think you could make use of this new technology? Drop us a line and we’ll help you get started.

Drop us a line

We’ll help you get started with better payments.


Thank you

A Dwolla representative will reach out to you within one business day.


There was an error and your the form was not submitted.

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

How We Did It: Inside Our Developer Portal Redesign

This post is an introduction to a longer piece co-written by Brent Baker, Dwolla’s VP of Product, and Melissa Cooper, Dwolla’s Director of UX. To learn more about the new Dwolla API and the developer portal redesign, read the full post on Medium.


Last week, I mentioned that we are rolling out a complement to the latest version of the Dwolla API—a deeply integrated developer experience within the entire Dwolla website—and the relaunch of our developer portal is now live. Our new API is the foundation of a revised Dwolla narrative and we knew how important it was to bring the developer experience to the forefront.

The developer portal relaunch effort spanned nearly four months and required a herculean effort led by our Director of UX, Melissa Cooper. Our UX, Design, and Developer Relations teams played major roles in this relaunch, and we’ll peel back the curtain in this post to share our process.

With a redesign project, it can be tempting to throw out everything and start fresh. But when you do this, a lot of insight can be lost. Don’t start with the new—establish a baseline of the known.


Our developer relations team constantly interacts with developers on the Dwolla platform, answering questions and gathering feedback. So we had plenty of information about what developers wanted, but our design team still had a lot of questions. Particularly, we wanted to speak with developers who were less familiar with Dwolla, especially those who weren’t actively reaching out. We developed our user research plan very early in our process, conducted in-person and remote interviews, then synthesized and shared our findings.

From this, we gained insight into the needs of less-experienced developers and the expectations of experienced developers. We observed friction points encountered by first-time visitors attempting to complete a lightweight integration from scratch. We also spotted similarities in the ways developers of all experience levels sought information.

In parallel to the user research, we performed an audit of content on our existing developer portal. The extensive audit allowed us to understand what content was applicable to the new version and how developers consumed existing content.

Our third piece of research was to look at best-in-class developer portals that have been rightly praised for their developer documentation like Twilio, Firebase, and Github. We familiarized ourselves with standards that have been set by the industry and reviewed around twenty portals to determine what resonates best with Dwolla’s brand and intent.

To learn more about the process behind the developer portal redesign, read the full post on Medium.

Visit the new developer portal now


APIs and the power of collaboration for innovation

API collaboration gears

Web-based APIs have been around for 15 years allowing businesses to provide their products as services. This approach allows for partnerships between companies with little human interaction. When development is complete, one company’s program talks to another company’s API—often the end user has no knowledge that the features at their fingertips are provided by multiple businesses working together.

Since the inception of web APIs, their usage has continually evolved. There are APIs designed to be public and open, while others are provided more restrictively through strategic partnerships.

APIs provide the building blocks for developers to easily construct new, enhanced tools by clearly defining how to interact with the system. This allows those developers to combine their own offerings with another company’s free of active collaboration.

Most API implementations are still passive partnerships—one company provides an API and another decides to adopts it. The power is realized when two companies actively work together, securely connecting their systems, to create something entirely new.

This is accomplished by each partner providing a private API opening up access to internal data and functionality that otherwise would take tremendous time and resources to expose and integrate.

The right collaboration on this level can fundamentally change an industry.

Public APIs

Most of the APIs we see are public, specifically designed to spread notability and product usage by allowing others to innovate with the company’s technology.

A public API serves as a proof point for a company’s value, or that same API could be combined with another business’ to build a more tailored solution of greater value. This approach has proven successful and is growing. When Amazon began offering cloud computing services like S3 and EC2, the API became a first class citizen—inseparable from the product itself.

Dwolla has had a public API since the early days—our open API has spawned quality tools of all sorts to improve the Dwolla platform. Some of these tools were developed by outside individuals interested in the platform, while others were created by businesses looking to leverage the Dwolla network to enhance or support their own product.

The current feature set continues to expand; it now includes transactions, scheduled payments, and MassPay. All of these tools are powered by our open API.

Private APIs

Private APIs work on the same principles as public; however, they are provided as part of specific partnerships and often expose more sensitive—or business critical—information. These APIs are designed to allow developers within the organization as well as close partners to leverage existing systems in a uniform way.

Example: The white label API provides the ability for partners to transfer money to their users via the Dwolla platform while maintaining control over the look and feel of the experience. Partners gain the benefits of fraud protection and security while avoiding compliance headaches.

Another example is our recent partnership with BBVA Compass. It is a collaborative endeavor—BBVA Compass uses our FiSync API to access real-time transactions, while we utilize BBVA’s (also private) API to access applications much closer to their banking core.

The BBVA Compass/Dwolla FiSync partnership was designed to open the possibility for anyone within BBVA’s banking network to instantly send and receive money. By designing our software in conjunction with each other’s APIs, we created a seamless, secure passage for our two distinct financial industry businesses to work together in a powerful new way.

Discovering the value of API partnerships

Providing a private API for the FiSync network reduces the cost of entry for banks and simplifies the complexity of business integration. The private API also provides security through established standards of authorization, tokenization, and encryption. Without even considering innovation, this approach to business collaboration has immediate value.

According to Gartner, 75% of the top 50 global banks will have launched an API platform by 2016. A trend that shows even slow moving banks see the value in trying to make use of APIs.

The benefits of this newer, more technologically-open banking remains to be seen, but it is a first step toward modernization of a huge industry.

Having an API is not enough, and turning that interface into innovation is more easily said than done—only time will tell who can effectively transform an API into business value.

There is nothing industry-specific about this approach. The value of two-way API relationships is not tied to the financial industry.

APIs help businesses integrate more seamlessly with each other by creating a common language and platform for communication, breaking down potential barriers.

This next phase of API collaboration isn’t a new concept, but its value and potential are still in explorative stages. Current indicators, as well as our own experiences, suggest that identifying ways to collaborate smoothly and painlessly via APIs will lead to exciting opportunities—opportunities to simultaneously increase security and productivity, add value to existing products, and extend market reach.


To get started with the Dwolla API, head to the developer portal. If you’re interested in understanding more about Dwolla’s powerful payments tools and API, reach out to sales@dwolla.com.

Reach out to learn more

2015-09-17This blog post shares insights from Daniel Shaefer, a software developer and technical lead for the devops team at Dwolla where he has worked on various accounting related efforts and helped build FiSync. Most of his free time is spent with his wife and three kids; he considers himself a developer, gamer, writer and sometimes ninja philosopher. He embraces a wide spectrum of ‘geek culture’, backs tons of Kickstarter projects, trains in Karate(Ryu Kyu), and enjoys a good game of ultimate frisbee. 

Homehey: Property Management Portal, Accepts Dwolla

You need a place to live. It’s a no-brainer. But how do you find that next home? How can you find a landlord that you actually want to ask to check out your lighting problem? The answer is HomeHey, a new, free real estate marketplace connecting property managers, realtors, and future tenants.

HomeHey for TenantsHomeHey is empowering people to make better decisions when it comes to choosing an apartment by giving them a portal to peruse and inquire about listings. For landlords, HomeHey serves as a secure, interactive platform that allows them to manage everything from individual tenants to rental payments.

What’s in it for the tenants?

Like most rental platforms, tenants are able to browse listings, as categorized by location, specs and price range. What makes HomeHey unique is their feature for rent bidding. If you find the listing you like, you have the opportunity to compete for it using HomeHey’s “Bidrent” offering.

Additionally, HomeHey  provides landlords with the ability to accept online payments—no more mailing checks. To make it ever easier, you have the option to pay for your monthly rent charge via Dwolla, so the payment is taken straight out of your connected bank account.

Rental Payment for Tenants

Through HomeHey, the renter can track their current and upcoming payments. Even more convenient is the ability to request and track service requests with the landlord online to ensure prompt and efficient service.

Leasing Service

What’s in it for property managers?

As a free software, HomeHey performs many of the functions required of property managers. First, you’re able to list a variety of properties in one place, provide a cost and description, and track how that listing is performing.

Property management system

Within HomeHey’s platform, realtors and property managers can view rental applications and qualify their potential renters using their social tenant screening system. HomeHey uses Facebook and LinkedIn in the application process so screening is a breeze and tenant acceptance is improved.

Most convenient: HomeHey’s ability to collect and manage rent payments online. They’ve built Dwolla right into their system so landlords don’t lose income to credit card transaction fees or valuable time processing paper checks.

Read More: The Cost of Checks in Small Business Payments

Property Management System

HomeHey also has the ability to generate reports for tracking purposes, so all the moving pieces stay where they belong.

HomeHey was built in partnership with Dwolla’s open API as an easy-to-use tool for property managers and the tenants they serve. Visit HomeHey.com to try it out or head to our Developers Portal to get started with your own Dwolla integration.


Dwolla @ Empire Startups FinTech API Panel

Posted in API, Blog, events, featured, fintech, Startups, Tech on September 18th, 2014


A couple Wednesdays back, we were invited to speak on the NY FinTech Startups panel hosted by Latham & Watkins to discuss all things API.  A special thank you to Derek Webster for moderating the discussion and thanks also to Empire Startups for organizing the event!

Joined by Christine Loredo (Yodlee), Sunil Madhu (Socure), Stephane Dubois (Xignite) and Melissa Stevens (Citigroup), we had an insightful conversation about our various API strategies and best practices.

There was a lot of great insight provided; to give you a feel for what was covered that evening, check out a recap of the night on Twitter below.

Lenore Kantor also wrote up a superb recap of the discussion – check it out!

Introducing Dwolla Direct

Checkout with Dwolla Direct in just a few clicks, no Dwolla account required.

At Dwolla we are always looking to create new ways to make payments faster and easier, not just for our customers but for all customers. We believe speed and convenience aren’t luxuries, they’re necessities. That’s why we’re proud to introduce Dwolla Direct, a new payment experience that allows individuals or organizations to send money to a business directly from their bank or credit union without requiring an existing Dwolla account or linked bank. That’s right, with Dwolla Direct you don’t have to have a fully registered Dwolla account to use the networkand most users won’t even need to provide their routing or account numbers to make a payment. We offer a streamlined process that can instantly verify bank information and allow first-time users to make a payment in as little as 15 seconds.

securely send online bank transfers with Dwolla

We believe sending money shouldn’t require gambling with your sensitive account information. Using Dwolla Direct is like putting a username and password on your checkbook. Your sensitive account information is never sent to the receiver of your payment, and you have a digital receipt of the transaction. No more checks lost in the mail, no more exposure of your personal financial network. Plus, you can reuse your username and password to send payments any time. No more re-entering your payment information. Leave the checkbook in the drawer and say goodbye to the postman, Dwolla Direct has you covered.

What does this mean for our users?

Nothing. All of our “no-tech” payment tools, like Form Builder tool, shopping cart plug-ins, invoicing options, and Dwolla Buttons, as well as our Off-site Gateway API, will automatically update on June 25th. We’re announcing it today to give our businesses and merchants time to understand the improvements.

How does it work?

Create a username and password, authenticate your bank credentials, and you can complete your payment directly from your bank. It is as simple as sending a check, but with the visibility, security, and speed of a digital payment.

Send online payments without a Dwolla account

Dwolla’s mission is and has always been to build the ideal way move money. For us, this means making payments seamless, safer and less expensive.



For Developers: An open source mobile wallet built on the Dwolla Network

Posted in API, Blog, developer, Developers, dwolla, open source mobile wallet, wallet on October 31st, 2013

Our evangelist team Gordon & Michael constantly create new libraries on github for the community to get up and running with Dwolla’s payment network more quickly.

Today, it’s getting a little easier to build mobile wallets/applications for the Dwolla Network with an open source mobile wallet.

Here is what it looks like:

Nick Schulze who interned at Dwolla a year and a half ago built a native mobile application leveraging our API that supports the following functionality:

  • OAuth (login)
  • Deposit
  • Withdraw
  • Search businesses
  • Search people
  • Show people around me
  • Show businesses around me
  • Show businesses map
  • Show requests
  • Pay requests
  • Add note
  • Save note
  • View available balance
  • View transaction history

The application’s graphic assets can be easily swapped out with your own branding but here’s the existing “Dwolla” theme:

IMG_5284 IMG_5283

photo (3) IMG_5279

IMG_5278 IMG_5281

If you decide to fork this project and release your own flavor of it, you’ll need to apply your own brand to it.  As a developer building a new application it’s also important to work and promote best practices with merchants confirming payments in retail environments.

For merchants, the Dwolla Kiosk is an incredibly easy way to confirm all payments in a retail location regardless of the application used to make the payment in store. Remember, 100% of payments on the Dwolla network can be easily and instantly confirmed. It’s also simple to add to your existing POS system.

Get the code on GitHub here

Sunsetting Old APIs

We’ve been hard at work developing our API and keeping our servers as fast, secure, and efficient as possible. While this job usually includes the development and additions of new APIs, at times this will include the deprecation of older API sets as well.

As such, we have decided to sunset our old REST “AccountAPI” and are recommending anyone not using our current API version to switch. In order to give you some time to adjust to our new REST API set, we’ll be keeping the “AccountAPI” alive for another 30 days and will be fully deprecating these calls on May 31st, 2013.

We’ll also be holding developer office hours, every Thursday at 6pm EST starting today, to help anyone that has questions about switching.

These endpoints include the following:

You may find our current API documentation at developers.dwolla.com. If you need any assistance migrating your code over to the new API, please don’t hesitate to contact me at michael@dwolla.com.

©2018 TransSwipe


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