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

TransSwipe - Merchant Services and Credit Card Processing

Archive for the ‘Get educated’ Category

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


Your tips for better information security

In this post Ben Schmitt, Dwolla’s Information Security Risk Manager, explores tips for improving your personal information security. Read more from Ben on security here

Screen Shot 2015-12-03 at 9.50.33 AM

The holiday season is here which may increase the likelihood for online scams and phishing attempts. For better protection, certain InfoSec back-to-the-basics practices are worth repeating.

Be cautious with emails:

Don’t click on unsolicited and mysterious email links. This is a judgment call and you may want to consider the following:  

  • Check to see who sent the email—If you don’t recognize an email address, don’t click.
  • Hover over the linked content to discover where it will direct you—If you aren’t familiar with the destination address, don’t click.
  • Check the signature to see if matches the sender’s standard or expected format—If it is out of place, don’t click.
  • Check the email header—If it doesn’t match the sender’s name, don’t click.

Be a helper and report suspicious spam or phishing emails. Email providers often provide a way to flag and/or report an email as spam.  By reporting, you may help prevent others from falling victim.


Enable Two Factor Authentication (2FA) wherever possible. Dwolla provides 2FA to our customers and many other services you may use do as well (Twitter and Amazon for example).  Using more than a single ‘checkpoint’ for authentication may be one of the best things you can do to protect your information and prevent Account Take Overs (ATOs). In the event your credentials are stolen or guessed, an attacker only has something you know, not something you physically have.

Use a password management tool. The age-old problem of too many passwords remains a pain for everyone, however all hope is not lost as a password management tool can help with generation, storage and use of credentials.  A password management tool can help limit reuse by using unique passwords across platforms and can keep easily obtained information out of your password/passphrase by generating them for you. Excellent solutions exist to manage these high-security, complex passwords—try LastPass, 1Password or KeePass.  

Maintain your software:

Remember to patch and/or update your operating system and applications. This is a basic and expected maintenance activity just like changing the oil and refilling the windshield wiper fluid in your car. You can even automate these tasks to make life easier.

This includes complex software such as Adobe Acrobat Reader/Flash and Java. It is not enough to patch just the operating system. If you don’t need it, delete it.  For example, you have a choice in PDF readers and now that HTML5 is here, Flash may well be optional (FYI, YouTube works fine without Flash).  If you can’t live without Flash, enable click to play as a mitigation.

Ensure endpoint protection:

Endpoint protection (aka anti-virus) remains critical to your security, although it should not be your only layer of protection. Endpoint protection software must also be updated; failing to update endpoint protection software is marginally better than running with no endpoint protection at all.

Device firewall enabled:

Enabling your firewall is an easy step to protect your device.  By default, most device firewalls will deny inbound traffic but allow outbound traffic. This simply means your device is allowed to connect to other locations but doesn’t offer any services by default. A good example of why this is important: a coffee shop. Typical coffee shops use commodity wireless networks which are massively shared and rarely monitored. If your laptop is not running a firewall, you may expose vulnerable services such as Windows file sharing, Secure Shell (SSH), etc.  Refer to Apple OSX Firewall Guidance or Microsoft Firewall Help to learn more about how to enable a device firewall.

Secure your network:

Consider using a network security provider such as OpenDNS. This service is free for home/personal use and helps to provide safe browsing by blocking known phishing sites, improving speed and even offering parental controls. This solution can be applied at your network router which is really powerful. Why? Because all devices course through the router for policy and DNS. This means that every tablet, laptop and Smart TV in your house benefits from DNS protection without having to secure each individual device.

Backup, backup, backup:

Modern backups can be done in-home with a small storage device (such as an Airport Time Capsule or personal storage device) or via a cloud service.  In the event of a hardware failure or accidental deletion, your data should be available to restore via a backup.

Aside from the obvious advantage of being able to restore data, a backup can be a blessing in the event of ransomware.  Ransomware is a specialized form of malware which uses strong encryption to encrypt your valuable data (think of all Office documents being lost) and hold it ransom.  A backup solution allows for a data recovery without negotiating with attackers.


The above are a collection of leading InfoSec practices which may be applied broadly to help improve end user protection.  It is important to stress that security is a process and there is no list available which removes all risk. Similarly, security is process without a defined end—we hope these tips help you on your journey.

At Dwolla, we are never done building, and that holds true for security as well. We are never done building a more secure way to move money. Learn more about security at Dwolla now

What I’ve learned in designing for developers, the discovery phase


Earlier this month we wrote about our end-to-end process in recreating our developer portal.

A number of people have asked us to elaborate on lessons learned from our user research when designing the developer portal and how research directly impacted our solution.

In reflection, I think there are three parts to this question:

  1. What did we learn during our discovery phase and how did it apply to our approach?
  2. What was changed when we validated our concepts?
  3. How will we continue to build on what we have learned?

Honestly, that is a lot of ground to cover. Let’s tackle question #1 first: explaining our findings from the ‘discovery phase’ and how this was applied to our approach to building the product.

Why dogfooding is not enough

Dogfooding is awesome. Nothing motivates you to improve an experience than personally being affected by the impact of its flaws. However, if you’ve been at your company for a while, chances are you aren’t looking at things with fresh eyes anymore.

Bringing in outside developers who have little to no experience with Dwolla or our API was key. It enabled us to separate our internal knowledge and hypothesis from the real world impact of first time users. Exploratory research helps develop empathy, prioritize known issues, uncover issues you didn’t previously see and generate new ideas.

The biggest take-away from upfront exploratory research was defining task driven personas, guiding our information architecture and our design principles.

Understanding motivation

Traditionally, you might think that there is an overarching decision making evaluating product fit and looking at product pages, and a separate developer leveraging documentation to get something done. We found it isn’t so cut and dry. Decision makers, product managers and developers are all interested in the what and the how of an API company. So, we decided to develop task orientated personas to inform our process.

Here is a quick overview of the personas we defined:

Personas of Developers searching for an API
Each of these roles—searcher, implementor, maintainer, hacker—will have varying degrees of experience developing products, and any given individual may play multiple roles at any time.

Thinking through these roles and their motivations directly fed into how we organized the information on the portal. We used what was discovered in the research phase to map out our plan and portal.

Tactical vs. Topical Content

Our previous developer portal was very topic driven. For example, we had one document for oAuth and another for batch payments. The downside was that in order to get anything done—you needed to read multiple documents. Time and again we observed people opening information in new tabs to keep track of where they had come from only to be swamped in a sea of tabs.

This simple observation led to very powerful design considerations.

We have launched with three main sections on the site: guides, resources, and API docs.


Our guides are our comprehensive how-tos that focus on our core use cases. They are designed to support the implementor and seeker quickly and easily get up and running.

Resources allow people to dive deeper into a topic, such as the options available for customer verification. This section is ideal for implementors or hackers, but is valuable for any of the four given personas.

API docs, of course, are where you go specifically to reference every parameter and detail of each endpoint—an important tool for extending on what you’ve achieved in the guides and useful for maintainers as well.

Skim, read, skim… skim.

Developer portals should make it easier to get the job done. Lets face it, this is work. Whatever you can do to make it easier to get something done is greatly appreciated by the dev community. There were a number of key objectives we wanted to achieve when creating our content.

Be comprehensive, but keep it simple.

For our guides, we created a step by step experience which provides an overview of how the product works, the process and context of the task ahead. Our steps also broke our guides into manageable chunks simplifying the end-to-end experience of the task.

Wherever possible, let the code do the talking. Reduce the words.

When it came to the content, we frequently observed developers reading the code first on any given document. Supporting content was predominately read if they had a question.

Avoid hyperlinking as a courtesy and only use when it is important.

Lastly, remember all that tab opening we talked about earlier? Hyperlinking content was largely to blame. Linking to special information that someone may or may not need is a nice gesture, but it is more likely that you are distracting them with content they are not sure they need.

Cross functional collaboration is key

Being closely involved in the discovery phase empowered the entire team to bring their talent to the table. We worked closely on these observations, sharing ideas and defining our direction as a group. This ensured every last pixel, every snippet and every letter written had the developer in mind from beginning to end. And of course, the journey continues…

If you have any feedback you’d like to share on the developer portal comment below or join the discussion on discuss.dwolla.com.

Join the discussion

Building with Microservices and Docker

Below is a blog post from our engineering team explaining our use of Docker at Dwolla. With Docker, we’re able to package applications and their dependencies to run within “containers”. To hear more from some of our engineers follow them on Twitter at @bpholt, @skylernesheim, and @mtravi.

API collaboration gears

Dwolla’s system started like many other startups. The team built a monolithic app that served business needs and was manageable for the team size. As the business and team grew, it became apparent that the monolith would have to be divided. The development team evaluated options and chose to move toward a microservices architecture hosted on Amazon Web Services. This architecture was selected because it allowed the team to independently build, deploy, and scale pieces of the system.

How we did it:

We started by building microservices as standalone applications running on their own EC2 instances, with multiple instances of services behind a load balancer. This structure works well in production, but we still observed a couple of sub-optimal areas.

  1. Running microservices on low-end generic VMs results in a large number of machines that needed to be monitored and managed. Managing several microservices running manually on a smaller number of larger instances was not ideal either.
  2. Inter-service dependencies make it a challenge to develop locally on this architecture.

About eight months ago, Dwolla’s platform team started looking at Docker alongside Amazon ECS. Most of the VMs running our microservices were not highly utilized, and rolling out new instances took longer than we wanted because we had to provision entirely new VMs.

Mesosphere and ECS were both good candidates for running containers in production, and both have distinct advantages. For our set of requirements, both were comparable in latency and throughput performance, so our focus quickly turned to cost and manageability. Dwolla runs on Amazon Web Services, so it was a natural choice to utilize a resource already within the ecosystem, and ECS’ integration with CloudFormation made it easy to integrate into our current CI pipeline. While there is a lot of innovation in this space, we decided that we would revisit the cluster technologies when our needs require it.

Amazon ECS is a good selection for the a majority of our services, but we run some services in an alternate environment. These services have higher security or IO requirements that make them less suitable for a shared environment. Because Docker does not provide complete process isolation, we deploy these services on their own instances running separately from the majority of our services.

Our end goal is to migrate all services to Docker, for improved management and monitoring automation. As we continue to develop our Dockerization process and tools we’ll be learning and sharing that knowledge on the blog. Stay tuned.

Read more from our tech team

5 things to do before investing in a custom payment system


There comes a point as a business when you realize it’s time to improve the sophistication of your payments processing. No longer is a complicated ACH interface or a simple credit card payment button the right option—you need payments that are seamless, efficient and safe.

Our Director of Strategic partnerships, Robert Rutherford, explains that ‘the devil is in the details’ when selecting your business’s payments provider in this article from The Business Journals.

In five steps, Rutherford explains that there are considerations and costs that come with ramping up a new payments process. These considerations are not initially obvious, but must be fully understood before making a critical, business-impacting decision and investment:

  1. Map out your flow of funds
  2. Understand the regulatory requirements
  3. Calculate risk vs. reward
  4. Test for long term effectiveness aka ‘future-proof’
  5. Make a decision

To get the full explanation and context for these five steps, read the original article posted by The Business Journals.

Read the full article

Interested in exploring how Dwolla can help with your business payments needs? We’d love to talk to you.

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. 

Breaking down real-time: Secure Authentication

As part of our new series, Going Real-Time, we sat down with Dwolla’s Information Security Risk Manager, Ben Schmitt, for a behind-the-scenes look at FiSync, our real-time bank transfer protocol for banks and credit unions, and its pioneering application of “secure authentication and authorization” for bank transfers. The following technical Q&A explores some of the security principles, benefits, and considerations that make up Dwolla’s real-time DNA.

How does secure authentication work to protect users?

Secure authentication is a method to ensure a user is who they say they are over an encrypted channel, using more than a single factor (i.e. just a password). Secure authentication methods protect a user’s identity and provide the foundation for secure communications and a broader security architecture.

Relative to FiSync, Dwolla has developed a secure authentication method for linking and enabling FiSync within bank accounts, in partnership with its newest partner, BBVA Compass. For the first time, we’re removing a customer’s need to provide sensitive payment information to anyone, even Dwolla, in order to make a payment.

By default Dwolla never shares your sensitive financial information with recipients, but FiSync takes this a step further. Pioneering new Secure Authentication and Tokenization practices, FiSync-enabled accounts are able to validate account ownership, authorize privileges, and initiate bank transfers—all without providing Dwolla bank account and routing numbers.

Basically, the customer doesn’t have to share their sensitive financial information with a third party, banks worry less about customers’ financial information being exposed or stored, and Dwolla is happy that our users are able to keep their information safe while taking full advantage of the Dwolla network.

Can you explain how authentication and authorization differ?

Authentication does not provide access to resources, rather, it only proves a user is who they say they are.  After authentication, authorization is the follow-on process of assigning access to data based on rules or roles which, in the case of FiSync, is achieved through OAuth scopes.

Authentication and authorization are similar but distinct actions. Authentication gets you in the front door of the hotel, whereas authorization provides you access to your specific room and no one else’s.

BBVA Compass Security

Relative to FiSync, how does authentication improve security?

FiSync was designed to allow for secure authentication between a financial institution and the Dwolla network as an enhancement option within the API—this is best demonstrated by the use of a one time password.

When linking a bank account, a user is challenged via a one time password with strong cryptographic controls and an out-of-band communication. Building a secure session is a combination of secure authentication including a one time password (OTP) and the implementation of 3-legged OAUTH2 for management of authorization within FiSync.  Lastly, transactions are tokenized including a nonce such that replay attacks or interception are mitigated as the speed of the transaction (seconds) reduces the window of opportunity for an attacker.

Fi Sync Real Time Payments Authentication Security

Technically speaking, what are the principles that make secure authentication so valuable?

The principles include multiple factors (something you know and something you have), a secure and trusted communications channel, standards-based cryptography, and time-based tokens such as a one time password (OTP).

Cryptographic ProtectionsStandards-based cryptography is critical—it means some of the world’s best cryptographers have reviewed, attacked and approved secure implementations of encryption and hashing. Implementing standards-based cryptography allows for proper security of data both in-transit and at rest.

Network DesignSecure and trusted communications can be further enhanced with a network designed to limit the attack surface. Initiating communications to trusted partners only, positions a network to have a “stateful security model.” Basically, this means communications initiated from a secure network will allow a response from a trusted partner, but deny all other connections reducing entry points.

One Time PasswordsAs an additional factor of authentication, a one time password (OTP) provides an out-of-band enhancement to the process. One-time passwords are time-sensitive, usually lasting a minute, severely limiting potential misuse.

Security by Design:

Our guiding principle as we build and iterate upon FiSync is that it is smarter and more effective to build security into a solution rather than adding it on after corelogic and services are built. FiSync is our flagship, real-time payment tool for financial institutions and with it, we’ve focused on security by design, following the principle of tokenization, performing threat modeling, creating a highly available network with a cryptographically sound web service design, and committing to data security.

We are never done building, and that holds true for security as well. We are never done building a more secure way to move money.

Infographic: How your money and your happiness are related

We all spend time worrying. We worry about catching the bus on time, we worry if we left the oven on, or whether the person in the car next to us is paying attention to the road.. Above all, we spend time worrying about money.

It’s only natural to be concerned about your finances. It’s why we share content to help improve your personal and business finance knowledge on the Dwolla Blog. From tools to track your finance, to the best ways to do some financial spring cleaning, we’ve covered a range of ideas to keep your money in line.

What we don’t spend nearly enough time talking about is the relationship of money and your happiness—how can we put our funds to work for a more satisfying life? In this infographic, we explore that idea, putting our money to work for our happiness rather than just the purchase of more things


©2018 TransSwipe


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