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

TransSwipe - Merchant Services and Credit Card Processing

Archive for the ‘Blog’ Category

Introducing Monetery | March 20, 2018

Posted in Blog, event, monetery on February 23rd, 2018

Monetery is an event about building value. That could mean a lot of things, and we’re hopeful it brings out a number of different opinions.

I tell founders everyday you can build in Des Moines, Iowa, and anywhere else. The Dwolla team knows it (both the west coast and the midwest team members), and so do some of the world’s best minds. When we started discussing how to relaunch events at Dwolla, the thing that kept coming up was the idea of value and building communities that embrace it. We decided to ask some of our friends if they’d be willing to come talk about it. We’re thrilled at who responded, and we hope that you’ll join us on March 20.

We’ve assembled a diverse set of investors to talk to the community. The reason we’ve focused so heavily on investors is that it’s clear that the midwest has some really meaningful divides between Seed to IPO support. While it’s been done, it’s incredibly rare. 

As various midwest ecosystems are getting built, we are excited to hear from people who have built strong ecosystems in their city in the past, or are currently doing so.

We’re fortunate that a wonderful group of people have agreed to come to Des Moines and speak at Monetery.

We’ll also be joined by some tremendous moderators.

The discussion could lead us a lot of places, and we’re excited to see where exactly that is, with you. The structure is really to discuss company and community creation through idea, Seed, fundraising, IPO, and after. We’ve asked each panel to speak on a different phase of building based on its expertise and interest.

Our vision for Monetery, is to create an event that connects people who believe in creating value in the Midwest.  The event is limited to 200 people. You can attend for free or make a donation for preferred seating. All donations will be passed directly to Pi515. Pi515 is a 501(c)3 after-school class that educates Iowa’s underserved population – mainly refugees 7-12th grade students – on basic computer coding with an emphasis on tackling world problems.

Advocate and Supporter tickets are now available and very limited number of general seating opens on February 27.

Grab your tickets!

New Investment

Posted in Blog, updates on February 12th, 2018

We’ve closed a $12M round led by Foundry Group with participation from Union Square Ventures, Next Level Ventures, Ludlow Ventures, High Alpha, and Firebrand.

The funds will be used to meet our growing capital requirements as a financial platform. We’ll also continue expanding our team to service customers. We have more than 40 openings to fill this year.

As we build our team, we do so knowing that the best teams are built by the inclusion of diverse ideas, experiences, and people. If this interests you, we hope you’ll consider joining us.

Ben Milne
CEO, Dwolla

 

Announcing Dwolla’s SOC 2 Type 2 Report

Posted in Blog, updates on January 26th, 2018

We are pleased to announce the availability of a SOC 2 Type 2 Report for Dwolla, Inc.

Built upon Dwolla’s existing internal control framework and focused on the security trust principle, the report provides valuable and independently-verified information for our customers, related to the assessment of approximately 80 security controls over a 6 month period of time.

This rigorous review process, as facilitated by a trusted, independent third-party firm, is now a part of how we do business at Dwolla. The process and initial outcome have been fantastic, enabling Dwolla to rely on its existing security foundation while also delivering continuous improvements and building process excellence.

The report is available immediately and can be obtained to approved recipients by submitting a request to one of Dwolla’s Account Managers or a member of our sales team.

The value of a SOC 2 Report

At Dwolla, we are consistently improving our platform and security program. Focusing on and delivering the SOC 2 Report is another step forward in our effort of continuous improvement.

Dwolla’s SOC 2 Report now serves as an assurance document for our partners demonstrating that we take thoughtful, appropriate steps to protect our systems and data. Adding tremendous value, it is not simply a snapshot of one moment in time, but rather, a comprehensive overview based on observation over an extended period and the performance of our internal controls. It is an integral element of our security program and builds upon our culture of advancing information security.

In order to achieve the SOC 2, Dwolla started with a solid foundation supported by a thoughtfully developed information security program. This program is based on a number of security-first principles such as security by design, strong authentication, and cryptographic data protection, as well as an integrated, independently tested control framework based on the CIS Critical 20.

One example—Dwolla employees are required to use multi-actor authentication (MFA) based on Duo Security and YubiKey. Putting MFA into practice, our VPN solution requires a username and password, an issued digital certificate, and a one-time password provided by a trusted YubiKey. What does this mean? Our practice of multi-factor authentication directly supports the SOC 2 Critical Criteria 5.1 for control of logical access.

Dwolla’s SOC 2 Journey

Dwolla’s SOC 2 journey started in 2016 with the selection of a trusted, national firm to lead the SOC 2 assessment. Next, the platform system description, control frameworks and approach to security were evaluated.

After this evaluation, there was an observation period, which covered the performance of the control frameworks over 6 months through on-site audits, walk-throughs, and documentation demonstrating operating effectiveness. The third-party firm conducted subsequent additional observation periods and then the reporting phase began. This phase is when the final report was given to Dwolla for the authorized distribution to our partners.

We are never done

Dwolla will continue to automate, measure, monitor, and improve as we begin the next SOC 2 observation period in 2018.

Dwolla recognizes that security is never done, but rather, it is a process. The SOC 2 Report is a milestone on our journey but is not a final destination. We are proud of our information security program and our continual focus on providing the ideal platform to safely move money.

To request a copy of our SOC 2 Report, please reach out to one of Dwolla’s Account Managers or a member of our sales team. Or, learn more about Dwolla’s security

Interested in learning more? Contact Dwolla

Case Study: Savings app outpaced transferred funds projection by 20% after integrating with Dwolla

Posted in Blog, use case on January 17th, 2018

Kidfund, a savings app, outpaced it’s transferred funds projection by 20%, aided by an integration with Dwolla.

A 2011 study from the Center for Development at Washington University indicates that kids with savings accounts in their name are 600 percent more likely to attend college. Kidfund is an application that enables and simplifies the contribution of funds directly to a child’s savings account by multiple parties and engages parents, friends & family in growing kids’ funds.

Problem:

With limited developer support to build a socially-powered savings app, Kidfund needed to overcome user onboarding concerns by creating a fluid experience when users are connecting a funding source and sending gifts to children’s savings accounts.

Result:

Kidfund, a socially-powered savings app, integrated with Dwolla to create a seamless user experience, which led to Kidfund exceeding their projected account balances by 20 percent due to 94 percent of their users taking advantage of Dwolla’s Instant Account Verification to add a funding source.

 

The Situation

Kidfund is an app that makes it easy for parents to set up and fund a bank account for their child’s college and other long-term savings. The platform aims to help parents increase the number and frequency of transfers to their child’s account to build a larger fund while enabling family and friends to give cash gifts directly to the child’s savings account.

A savings account is opened for the child to start accumulating savings. Then, parents, friends, and other family members link their checking accounts to the Kidfund app. Within the application, the donors only need to transfer funds from their donor bank accounts to a Kidfund savings account. Likewise, the Kidfund savings account only need the ability to receive funds from many donors, not to send funds.

In the Kidfund app, families can also extend financial empowerment across communities by donating a percentage of their child’s incoming funds to college savings accounts for kids living in low-income households through Kidfund’s non-profit partner, the 1:1 Fund.

The Challenges

The primary challenge Kidfund faced was providing a clean and easy experience when transferring funds. Kidfund recognized that a smooth payments integration enabling immediate donor activity would optimize the experience and increase Kidfund’s retention rates. According to Appboy, after opening an app for the first time, 75 percent of people fail to return the next day. However, consistent early engagement results in 90 percent retention after one month.

A donor on Kidfund’s application is asked to first connect a bank account and then proceeds to actually transfer funds from their donor’s bank account into a Kidfund savings account. Understandably, users can be tentative when providing banking information, so demonstrating security during the onboarding process is the key to overcoming this challenge.

Also, the actual transfer of funds into a Kidfund savings account needed to be simple for donors and accomplished in just a few clicks. So on top of a secure onboarding process, Kidfund needed to provide an enjoyable transaction experience to encourage growth and adoption of the application.

These challenges were successfully tackled by Kidfund with only two developers on staff.

“ACH is not a simple process to understand. If you told me I had to deal with FTPing fixed-width text files to a bank or the Federal Reserve, I would probably run. But Dwolla takes all of that complexity and wraps it up behind a well-documented API that does exactly what it says it does, so all we have to think about in transferring money is ‘who’ and ‘how much.’”

Chris Johnson, Sr. Developer

How Dwolla Helped

Enabling Seamless Onboarding

Any application that requires you to link a bank account must be thoughtfully designed around the user experience. If not, users will simply delete the app before they even get started. Optimizing the conversion from app download to linking a donor bank account can make all the difference in growth and adoption.

Solution: Kidfund utilized Dwolla’s Instant Account Verification (IAV) to link a donor bank account easily and securely. The process involved choosing a bank, verifying the account, and also verifying the user’s identification.

Outcome: Kidfund saw that 94 percent of accounts with funding sources connected had instantly verified using Instant Account Verification.

Simple Funds Transfers

Transferring funds from a donor account to a child’s savings account is a key functionality of Kidfund, and being able to take a variable percentage of the transfer and donate it to kids in need is part of their mission. Building a solution that brought both of these pieces together was necessary for maintaining customers.

Solution: Kidfund leveraged Dwolla to ensure that the process of transferring funds was as simple as tapping a button in their app while providing the necessary functionality of both recurring transfers and taking a percentage of each transaction.

Outcome: With Dwolla, Kidfund integrated the efficient funds transfers that they had envisioned, and benefited from the access to additional items on their “payments wish list” like recurring payments and percentage-based contributions.

Integration Experience

An important aspect of Kidfund’s search was ensuring the solution that they found offered dedicated support and guidance through the integration process and beyond. This was integral because they didn’t have a large development team. Every moment spent integrating a payments API was a moment they weren’t working on the product itself.

Solution: Kidfund conducted their payments solution search with support in mind. Dwolla’s extensive developer documentation and technology-first mindset led them to choose Dwolla as their solution.

Outcome: With two developers and Dwolla’s dedicated support, Kidfund was up and running with Dwolla in 5 months, right within their projected timeline.

Interested in learning more? Contact Dwolla

9 things to consider when searching for a payment integration

Posted in Blog, Knowledge Base on January 9th, 2018

Right now, you’re searching for a payment integration that will not only serve your needs but will also enable a delightful user-experience for those interacting with your application every day. In order to effectively evaluate different solutions, consider the 9 criteria outlined below.

Some items for consideration are obvious, while others are commonly realized only when you’re well down the path of integration with a payment integration.

1. Flexibility & Customization

The most important consideration for any payment integration is functionality. Simply put, can the integration do what’s needed? If every other aspect of the payment integration is perfect, but the solution cannot solve your specific functionality requirements, then it doesn’t help.

Our partners have found that our robust RESTful API can fit most use cases. By setting up a webhook subscription, you can seamlessly monitor Customer and transfer related events. This allows you to seamlessly gather information which you can forward to your Customers, allowing for greater transparency and a robust user experience.

Dwolla also supports multiple SDKs to simplify the integration process, complete with helper libraries.

Flexible Payment Integration

Dwolla offers additional features to ensure that the solution fits most use cases. One example is that Dwolla offers Same Day ACH and Next Day ACH to some of our partners to expedite payments. Expediting payments may lead to better control over cash flow.

Other features for further flexibility and customization include:

When considering flexibility and customization, these features mean very little if you cannot make the integration match your application experience. That is why Dwolla is white labeled. We know that you want the payment integration to fit into your application’s UX seamlessly.

“Dwolla’s API allows us the flexibility that we need to deeply integrate ACH transactions into our platform without disrupting our user experience. From customer identity verification to bank account verification to the transactions themselves, Dwolla takes the complex world of payment processing and wraps it up into an API that is painless to integrate.”

Dave Riess
Wunder CTO

2. Security

An important part of your payment integration search is looking for a secure solution. In a day where user’s trust is paramount, look for a solution that offers security practices you feel confident in.

At Dwolla, security is in our DNA. We practice iterative security with strong cryptography, statistical analysis, machine learning, and continuous monitoring.

Learn more about Dwolla’s security practices.

 Payment Integration Security

3. Pricing that Scales

Once you are confident a payment integration will fit both your use case and security expectations, the next step is making sure pricing fits your business model.

As you grow, your profits and transaction volume will grow as well. Pricing that takes a fee or portion of every single transaction can stifle your profit growth.

If you’re expecting a high number of transactions, often, a per transaction fee on every transaction is not the most scalable pricing model. With that in mind, Dwolla has designed a pricing model to be closer to a licensing fee. This fee structure allows for more predictable costs that do not hurt the bottom line as transaction count rises.

4. Business Analytics

A truly useful payment integration should come with the ability to provide business analytics and other feedback and functionality.

A product that facilitates transactions should allow you to keep a pulse on how the payment integration is performing. Do you know if the number of transactions on your platform is increasing or decreasing each month? What about the total amount of money sent? These are all important indicators that need to be measured and tracked.

Improved insights and tracking are exactly why we developed and continue to develop our Dashboard. In the Dashboard, you can manage your customers, view transactions, and discover trends in your business’s payments.

Payment Integration Dashboard

“When investors are your end-users, support is paramount. The Dwolla Dashboard and Admin helps our team work smarter, making our real-estate investment platform more useful to investors. Everyone from client success reps to legal and compliance teams use the dashboard to better serve our investors. Dwolla has nailed down our needs so effectively that we’ve been able to clear business requests on our roadmap.”

Peter Shankar
EquityMultiple CTO

5. Extended Integrations

As a business, you are wise to think one step beyond the initial problem at hand. For example, today you’re looking for a payment integration that can help you facilitate bank transfers. However, you should also make yourself familiar with how your payments provider interacts with other software.

These extended integrations can help enrich the product and process or provide additional functionality.

Dwolla has integrations with both Sift Science and Plaid.

Sift Science uses machine learning on a global network of fraud data to improve risk management and to predict fraudulent behavior. By offering our partners an easy means of integrating with Sift Science, partners can more improve detect and prevent fraud through real-time risk scoring on transactions. Plus, the integration is as easy as toggling a switch and then entering your API key.

Plaid provides an elegant and secure way to verify bank account ownership without asking for sensitive account or routing numbers. Plaid uses short-lived access tokens, which act as a vault that protects data. When Dwolla needs information, Plaid distributes it to Dwolla without requiring partners to store the information. And just like the Sift Science integration, this only takes minutes to integrate.

6. Ease of Integration

After choosing a payment integration partner, your next step will be integrating that solution into your platform or application. An integration shouldn’t be painful; integrating should be straightforward with resources to help guide you along the way.

Dwolla wants to start all relationships out on the right foot, so we provide top-notch resources to improve the integration process.

Some of these resources include:

Sandbox environment
– A complete replica of our production environment
– Access to API endpoints that you can test with fake transaction data

Developer Guides
– Walks you through everything from getting started to handling webhooks

Developer Documents
– A deeper dive into how to integrate our API code

Developer Community
– Forum for questions for our integration engineers and other community members

Payment Integration Sandbox Environment

“In our search for a solution, it was clear from the developer documentation that Dwolla was a modern in-road to the ACH network. Better yet, from the dedicated support and outstanding tools Dwolla provides, we continued to find new value-adds that really made the solution standout.”

Brian Fritton
Patch of Land CTO & CO-FOUNDER

7. Integration Support

Sandbox environments and developer resources are a great starting point, but going live with your integration is even more critical.

With Dwolla, you get support from both an Integrations Engineer and an Account Manager. Our Integration Engineers know the API inside and out and can help you through questions that you might have. Our Account Managers will be your point of contact throughout the whole process, ensuring your integration checks off all the security and compliance boxes.

When shopping around for a payments integration, frequently people focus on the technical aspects of the integration. However, other aspects are forgotten—information security, statement emails, terms of service & privacy policy. These are all important steps in launching any application with payments functionality, and our Account Management team is here to make sure you get every aspect done right.

“Working with their tech team on our integration was great. They were always quick to respond to questions and very receptive to feedback. A feature that we requested during a meeting with them went live only a few weeks later. This gives us the confidence that as our payment needs evolve, so will Dwolla.”

Matt Moore
PopularPays CTO

8. Ongoing Account Management

The payment integration is an important piece of any platform or application, and dedicated support plays a big role in the success of any payments integration.

Dwolla has an amazing team of Account Managers to ensure a successful integration and partnership moving forward. If problems arise, then your team can reach out. Open communication is a key part of the Dwolla experience and it is something we take pride in.

9. Constant Improvement & Feedback

Your application will be going through constant growth and development, so why choose a payment integration that is stagnant?

With Dwolla, there is no end state. We are constantly improving our product in new and innovative ways while listening to our partner’s perspective at every turn.

Read more: How our Senior Product Manager implements customer feedback.

For example, we added additional functionality to the Dashboard in order to make managing ACH returns easier for partners. The process of managing ACH returns has always been cumbersome, but with the evolution of our product, we’ve simplified the process.

The Decision: Choosing a Payment Integration

After evaluating the points outlined above, you’re better equipped to make an educated decision. We hope Dwolla can be the payment integration for you, but even more importantly a partner you can grow with.

Interested in learning more? Contact Dwolla

Case Study: Bento launches a new product with bank transfers enabled by Dwolla’s API

Posted in Blog, use case on December 14th, 2017

Bento, an expense management provider, launches a new product with bank transfers enabled by Dwolla’s API.

Download the complete case study as a PDF

A third of U.S. businesses declare bankruptcy due to employee theft, and the losses amount to $50 billion every year. Bento aims to solve this with their suite of expense management tools. 

Problem:

Bento needed a payments integration that could provide more control over the customer’s experience in linking a bank account and transferring funds into their Bento account.

Results:

Bento integrated Dwolla’s API, resulting in a completely branded experience as users connected their bank accounts and transferred funds into their Bento account.

Overview

Bento for Business provides turn-key expense management solutions for small- to mid-sized businesses, with its flagship product, the Bento Card. The Bento Card is both a physical and virtual prepaid debit card, allowing employers to control employee spending.

Each employee or contractor gets their own Bento Card, while the employer or admin controls what, when, and how much the respective employee can spend using the card. Bento uses Dwolla’s API to facilitate the transfer of funds from the employer’s banking account to a Bento account.

Bento needed the ability for employers to seamlessly, instantly connect a bank account. This connected bank account would be used to upload funds into the Bento account associated with each Bento Card.

In short, Bento had three requirements of whichever payments integration it chose:

  1. Easy for users to connect a bank account
  2. A white labeled integration, branded to Bento
  3. Ability to transfer funds from a bank account into a Bento account

 

“We were looking for a faster way to onboard our customers to use the Bento platform, and Dwolla delivered. Dwolla was easy to integrate, and providing a white-labeled experience gave Bento a new level of flexibility and capabilities to integrate to the ACH network that we couldn’t find in other providers. We can now give our customers the optimal experience by linking bank accounts and transferring funds.”

Sean Anderson, COO and Founder, Bento for Business

How Dwolla Helped

Delivering on Functionality

At a minimum, Bento needed a payments solution that could verify bank accounts and transfer funds into a Bento account. It was also important to be able to weave these functions into a simple user experience.

Solution: After considering other solutions, Bento integrated Dwolla’s API in order to deliver the required functionality, suited to their branding.

Outcome: Bento integrated with Dwolla’s API, delivering a beautiful user interface and instant bank account verification. Today, Dwolla facilitates transactions for thousands of small to mid-sized businesses on Bento’s platform.

Easy Integration

When launching a product, Bento couldn’t afford to start from scratch; that would require too much time. They were looking for a partner in the payments integration, experts to guide them and shape the facilitation of bank transfers.

Solution: Bento considered three payments providers, and ultimately decided to integrate Dwolla’s API because it reduced the amount of development work for its team and offered dedicated support.

Outcome: Bento integrated and launched Dwolla’s API in less than a month. They enjoyed responsive support, saving the development team an estimated 4 weeks during implementation.

Enabling Growth

As innovators in a new space, Bento is consistently adding new products and features to reach a broader swath of small to mid-sized businesses. They were looking for an integration that could, down the road, support and enable new functionality within their platform.

Solution: After successfully integrating he Dwolla, Bento has been able to plan new ways to diversify and expand the company’s product and platform.

Outcome: Since the first implementation of Dwolla, Bentonow verifies their customers with instant account verification (IAV). The company is also exploring new ways to expand their platform, enabled by Dwolla’s API.

Interested in learning more? Contact Dwolla

Embracing Open Source Development

Posted in Blog, Developers, Knowledge Base on November 29th, 2017

At Dwolla, we are big believers in the power of open source software. We believe that using and contributing to open source makes for better designed and safer software, enabling developers to focus on building tools and writing code that are within their specific area of expertise.

When developing open source software, there are some guiding principles we believe in and can share with you, but first let me provide some background.

Value of Open Source

Open source software has helped drive much of the growth and innovation on the internet in the last few decades. It allows for all companies—or even a couple of developers in their garage—to start from a base of software that is free to use, modify, and experiment with. They aren’t tasked with becoming experts in operating systems or network communication; instead, they can focus on the company they want to build and getting to market much sooner.

With open source software, those same developers also know the software or code they are using has been reviewed by their peers, the greater community of developers. Better yet, if they have any questions, they can see the source code for themselves and make any changes they need. This can lead to software that is safer and stronger and gives more power to small companies and independent developers.

Contributing to open source projects

Image result for mojaloop logo

Recently, Dwolla was part of the team contributing to Mojaloop—the Gates Foundation’s open sourced software for creating interoperable payments platforms. As part of this project, we worked on a project designed to be open sourced from the beginning. This was an exciting opportunity to build something that could potentially be a foundation for payments in developing countries and ecosystems and to see how it could grow and change from where we started.

Building software that you know will be completely open sourced calls for a slightly different set of priorities. We knew this code was going to be openly available, so there were a few principles to consider that are different than working on closed source software.

Principles to Consider

Document Rigorously

First, you have to remember that there will be people using the software that wasn’t part of the original project. This means that you can’t assume they know anything, and you have to document, document, and document some more. You must have clear documentation of the software, including what it does, dependencies it requires, and any configuration options that are present.

While working on Mojaloop, we took these principles to heart. All of the individual initiatives have helpful documentation, including README files, API documentation, example projects, and “getting started” guides.

Provide Examples

Providing examples of the software in use is also a great addition. Examples help developers understand how the software is intended to be used, while also providing an excellent place to start with their usage of the open source code.

A project with an extensive set of examples would be Chefspec. Here, developers can find real-world examples of tests you may write for Chef recipes. These real-world examples can serve as foundational starting points.

Create a Roadmap

You should also create a roadmap for the project since the initial open sourcing of a project is rarely the end state. The project will continue to grow and attract users and volunteers; providing a roadmap gives volunteers an idea of what features can be contributed to. A roadmap not only gives others a chance to see what is coming for the project but also encourages feedback and ideas on how to evolve the software.

A great example of a project with a clear roadmap is Mozilla’s Firefox. This roadmap does an excellent job of highlighting the focus of the project for the year, while also giving target dates and build numbers for when features will be available.

Document Architectural Decisions

In working on Mojaloop, we also documented many of the architectural decisions that were made, allowing those who might be new to the project to understand some of the questions and considerations we thought about and discussed during the initial development. We also created a roadmap that clearly outlines what features need further development and some larger features we would love to see the software support in the future.

Extensible Software

In open sourcing, the software you create has the potential to be used by many people in a wide variety of ways, so it’s important to consider extensibility. From the beginning, you have no way of knowing how others will want to use it or what they will specifically want to do with your open source code.

By designing your software to be extensible, you make it easier for users to adapt it for their projects. Extensibility can also allow for people who are less technical in nature to modify the software through plugins or other options for adding features. WordPress’s fantastic plugin support is a great example of this extensibility.

During the development process, we decided that extensibility was going to be a main feature of Mojaloop’s Central Directory. Serving as a core component, the Central Directory allows a user to be found via search through many different pieces of information. There are endless ways to search for someone, from their name to their email address, to their Facebook account. Rather than designing the Central Directory to store all of this information for a user, we wanted to leverage systems that were already securely storing this data and apply it to search. The Central Directory allows for an expanse of systems to be easily plugged in, so that those integrating the open source project can be found quickly and with no personal data requirements.

Mojaloop & Open Source

Mojaloop was a worthwhile project that allowed the team at Dwolla to really get involved with and contribute to open source software at a deeper level. Open source is something that we use and contribute to regularly, and we believe it is one of the things that helps make it easier and safer to build new and exciting platforms, applications, or infrastructures.

Looking to the future, technology will only continue to become more collaborative and transparent. Open source projects are great examples of giving back to the larger community, allowing those who are experts in specific areas to share their knowledge and perspective and ultimately enabling better collaboration.

Interested in learning more? Contact Dwolla

ACH return codes and how to test for transfer failures in Dwolla’s Sandbox

Posted in Blog, Developers on November 21st, 2017

While progress is being made to modernize ACH processes, the U.S. banking system as a whole is not always straightforward. Truthfully, navigating through the world of ACH can be quite daunting at times. With all the complexities, one would assume that developing an application to facilitate bank-to-bank transfers would be an arduous task. However, with Dwolla’s Access APIyou can integrate technology that helps you facilitate bank-to-bank transfers.

When an application involves facilitating the transfer of money to or from a bank account there is the possibility of transaction failures. This possibility is simply a part of transferring funds within the ACH network. Instead of leaving the handling and processing of ACH errors up to the business, the associated financial institution that rejected the transaction will assign an ACH return code when a bank transfer fails.

Let’s walk through how ACH return codes play out in relation to the Access API. Understanding how the API handles transfer failures in the Sandbox will help avoid unnecessary confusion when you deploy into Production.

When you think about how these failed ACH transactions play out in relation to Dwolla’s Access API, you might have a transfer that ends up failing.  By calling the API to retrieve a transfer failure reason, you will receive a receipt of the return code from the financial institution letting you know why the transaction failed. Transfers facilitated by your application can be returned as failed by a financial institution days, or even weeks after they were initially created. For this reason, you will want to account for and test ACH return codes and scenarios prior to going live with your Access API Integration.  

In the Sandbox environment, Dwolla allows you to trigger various bank transfer failures by specifying an “R” code in the funding source name parameter when creating or updating a funding source for an Access API Customer. When a transfer is initiated using a funding source that has an “R” code assigned to its name, a transfer failure event will trigger and the status will update to failed when you simulate bank transfer processing. Let’s walk through two testable scenarios of transfer failures in the Sandbox environment using two Verified Personal Customers.

R01 — Insufficient Funds

Sometimes there is just not enough money available in a bank account. When this happens, a financial institution can return an R01 return code. For this example, let’s consider how a transaction could play out between two verified Customers in the Access API.  Sam (source) has a questionable bank account. He doesn’t have enough money in his account to transfer funds to Darren (destination), but he initiates a transfer anyways. Since Sam doesn’t have enough money to cover the transaction he initiated, the transfer will fail. In the Sandbox, we can test the transfer to see what will happen during this transaction.

Setting the transaction up in the Sandbox

To test the transaction in the Sandbox, you can create or update a funding source by changing the `name` to R01. You can now initiate a transfer with the Source of the transfer being the R01 bank account.

In a transfer scenario between two Personal Verified Accounts, you can expect these webhooks to be fired.
`customer_transfer_created`
`customer_bank_transfer_created
`customer_transfer_failed`
`customer_bank_transfer_failed`

What Happened?

Sam initiated a request to transfer money from his bank account to Darren’s bank account. However, the money was not moved from Sam’s bank account because Dwolla was unable to complete the transaction; there were insufficient funds. In order to avoid an ACH return the next time, Sam will need to initiate another transaction when he does have sufficient funds. 

R03 — No Account/Unable to Locate Account

Now let’s talk R03 codes. Imagine making a mistake when typing, it’s not hard to do. An R03 Return Code can come up for a couple reasons, but one of the more common reasons is when a bank account number or routing number is mistyped when creating a bank funding source.

For instance, when micro-deposits are initiated, this can still be considered a transfer, as funds are being sent to a destination. If an account number was mistyped and micro-deposits were initiated, these will be unable to clear. Let’s imagine a scenario Sam wants to initiate micro-deposits to his new bank account for the purpose of bank funding source verification. If he ends up mistyping his bank account number, the microdeposits will have no place to settle.  Dwolla will receive an R03 return code and will automatically remove the bank funding source.

Set this up in the Sandbox

To test this in the Sandbox, you can create or update a funding source by changing the `name` to be R03. You can now initiate microdeposits to this bank funding source.

In this scenario, you can expect these webhooks to be fired.
`customer_microdeposits_added`
`customer_microdeposits_failed`
`customer_funding_source_removed`

What Happened?

Dwolla was unable to clear the microdeposits to Sam’s bank, as it was unable to be found. The bank funding source will be automatically removed. The application will allow Sam to add another bank account and try again.

What Next?

Bank transfer failures are not the only things you need to test for when getting started with the Access API. You can check out our documentation for tips on how to simulate transfer all of our failures in the Sandbox.

With a powerful set of tools at your disposal, testing in the Sandbox is intuitive. Remember that the transfer of funds is simply the movement of data, and utilizing Dwolla’s powerful API’s can facilitate quick and reliable transfers for a variety of scenarios.

Interested in learning more? Contact Dwolla

What are ACH Debits and Credits? Understanding the components of an ACH transaction

Posted in ACH credit, ACH debit, ach transaction, Blog, Knowledge Base on November 9th, 2017

At Dwolla, building the ideal API to move money is what we do, but without the Automated Clearing House (ACH) Network, none of it would be possible. ACH is what allows for the electronic transfer of funds between banks to take place in the United States. According to the National Automated Clearing House Association (NACHA), the self-regulatory body responsible for governing the ACH network, there were more than 25.5 billion ACH transactions in 2016 alone.

Whether you’re processing payroll or monthly recurring payments, ACH is there to make it happen. If you’d like to take an even deeper dive into all things ACH, take a look at our comprehensive beginner’s guide to ACH. In the meantime, this post will help you get a better grasp of what is taking place for ACH credits and ACH debits during an ACH transaction.

Here’s how it all happens:

What is the ACH debit process?

Let’s imagine that you’re setting up an automatic monthly payment for your car payment. To begin, you’ll provide that company with your checking account information and authorize it to withdraw funds from your account for the payment each month. When the due date rolls around, a new ACH entry is created by the lender’s bank. That entry is then sent to your bank, which debits your account for the amount of the due payment. The ACH entry is then credited to the lender’s bank and the transfer of funds is complete.

What is an ACH credit?

When you’re on your bank’s website there’s a good chance that you have seen a ‘pending ACH credit’ listed on a statement entry line. One of the most common pending ACH credits that people encounter is through the employer’s direct deposit. Think of an ACH credit as money coming to you, rather than being deducted from your account.

How long do ACH credits and debits take?

Both ACH credits and debits can only take place on days that banks are open, and typically take several days to process. While ACH payments are not real-time like wire transfers, NACHA is implementing Same Day ACH in phases to address the speed of ACH credits and debits.

NACHA has rules that these timelines were created based on, but it is important to note that once the receiving bank gets the money, there could be a holding period, making the total delivery time vary.

More questions on ACH? Check out this blog to learn more about ACH.

Interested in learning more? Contact Dwolla

Mobile savings app integrates Dwolla Access API, improved margins by 10 percent

Posted in Blog, use case on November 2nd, 2017

After switching payments providers, Qoins, a mobile debt-repayment and savings app, improved margins by 10% with Dwolla’s Access API.

Download the complete case study as a PDF

In 2016, NerdWallet reported that the average American household carries $16,000 in credit card debt. Qoins targets that problem; the app rounds up spending and applies that amount to pay off a user’s debt.

Problem:

Qoins needed to facilitate the distribution of funds from users’ verified bank accounts on a monthly basis to apply towards debt. It called for a payment API that could scale and be integrated seamlessly.

Results:

Replacing a previous payments partner, Qoins integrated Dwolla’s Access API to facilitate its thousands of monthly transactions, improving its margins by 10%.

The Situation

Qoins is a mobile application that rounds a user’s purchases to the nearest dollar and uses that change to send out payments to pay off the user’s debt automatically.

Within a thoughtfully designed interface, users start by connecting their respective debit cards and then dictates where the “rounded” savings should be sent. 

As the user makes purchases, that spare change is withdrawn and then once a month applied to the designated accounts to pay down debt. On the backend, the application needs to first withdraw the accrued amounts of change from a user’s bank account and subsequently apply that withdrawn amount to a credit card payment.

After its previous partner left them in the lurch, Qoins needed an easy-to-integrate, reliable partner to connect users’ bank accounts and facilitate this transfer of funds.

The Challenges

Qoins was coming out of beta and about to launch its mobile application when its previous payments partner withdrew its ability to support them. The team at Qoins was then left searching for an API that could be integrated seamlessly while reducing the pains of on-boarding for new and current users of the application.

Users were already contributing an average of $50 towards their debt each month, so Qoins was looking for a solution that would scale. To support its growing base of daily active users confidently, it needed to facilitate thousands of transactions each month, and there wasn’t the time or bandwidth to build a payments solution from scratch.

Qoins put its users’ information security at the top of its list of priorities, and the ability to send information off and tokenize it for future use was of the utmost importance.

 

“We needed a reliable payments partner that could deliver an API that simplifies the process and allowed us to deliver the basic functionality our application required. The Access API did just that, and more…and we knew we could count on their team as a long-term partner as we grew our company.”

Nate Washington, Co-founder & CTO


How Dwolla Helped

Improved Margins

In facilitating 5-10 transactions for each user every month, Qoins was paying a per-transaction fee to its previous payments partner. Financially, this was simply not scalable as Qoins continued to see steady user-growth and daily activity; the company needed a solution that was more predictable in costs.

Solution: Upon switching payments partners, Qoins moved away from a per-transaction fee model and instead integrated with a payments partner that offered predictable SaaS-based pricing.

Outcome: Qoins increased its overall margins by 10% since implementing Dwolla’s Access API.

Seamless Transition

Above all, Qoins was looking for an implementation that provided minimal interruption through both the integration as well as in the onboarding of new and existing users.

Solution: Qoin’s developers were drawn to the Access API’s straightforward developer documentation. Additionally, the integration allowed Qoins to facilitate the movement of its users’ money while keeping its brand at the forefront of the process, making for a smooth onboarding and transition for both new and current Qoins users.

Outcome: Qoins was able to transition its payments functionality to Dwolla’s Access API in just four business days. This swift and smooth transition prevented Qoins from incurring any interruption to the application’s service.

Reliable Partnership

Qoins knew all too well the value of a good service provider. The company was looking for a payments partner that was reliable in its support as well as up-time. Qoins required a secure and tokenized process and was very thoughtful about entering a new partnership.

Solution: With guidance from our Account Management team, Qoins integrated the Access API. Additionally, the Access API tokenizes high-value data in the financial transaction.

Outcome: Qoins is able to confidently facilitate thousands of transactions each month, helping its users pay off more than $500k in debt in its first year as an application.

Interested in learning more? Contact Dwolla

©2018 TransSwipe

 


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