Warning: session_start() [function.session-start]: open(/home/content/30/7423630/tmp/sess_b68mcpkmbu1kt2437ogaufkhp2, 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

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

How we’re improving ACH Returns Management

Posted in ach returns management, ach transaction, Blog, updates on October 24th, 2017

At Dwolla, our goal is to make ACH transactions easier for our partners to manage. Managing ACH returns has long been a point of frustration for anyone using the ACH network, let alone for partners using our Access API.

We’re excited to share that we’re leading the way with new functionality making it easier than ever to manage ACH returns. In short, here is what’s new:

  • Within the Dashboard, you can deactivate and reactivate Customers
  • See the Customer verification status separate from the bank account verification status
  • Easily manage the effects of failed ACH transactions and reactivate customers right within a user-friendly interface of the Dashboard

Understanding the situation

In the world of ACH payments, failed transactions are a fact of life. Reasons a transaction might fail can range from the typical (Insufficient Funds) to the obscure (Return of XCK entry). Whatever the specific reason, they do happen.

Currently, in the fintech industry, there are very few truly effective ways to manage these failures—in fact, we’ve heard from our partners that there aren’t really any good solutions. ACH returns are treated as an external, one-off problem, left to the companies using the network to deal with. They have to figure out why it happened, what exactly happened, and even how to fix it.

At Dwolla, we’ve changed that process.

We’ve been doing some research at Dwolla. Our Product and Engineering teams have gone through an extensive process to understand the reasons for ACH failures and determining what actions should be taken based on those reasons for failure. Finally, the last step in the research was understanding the best way to provide Access API Partners with the ability to rectify the situations caused by those failures.

Dwolla is making it easier to manage failed ACH transactions

We’ve made some enhancements to the Access API to improve return code management. These new enhancements allow us to fine-tune actions based on why failures are occurring, in turn, helping reduce risk for our customers, but also provide them the greatest level of business continuity.

Dwolla has enhanced the API to allow Partners to deactivate a customer, but they can also now reactivate customer accounts as well. These enhancements put some of the decision making and control in the hands of our Access API Partners.

We believe that you’re the expert on your Access API integration, and each time we make an improvement like this you get more control and impact on your customer’s journey.

The addition of reactivation gives our partners the ability to resolve many of the situations caused by failed ACH transactions. Now Partners can reactivate an account, get back the money they’re owed and reconcile that user’s account balance.

And the “cherry on top” is that all of this functionality is now available right within the Dashboard!

Easing the process for Partners

Providing this added functionality within the Dashboard means our Access API Partners don’t have to start from scratch in building processes and internal systems to manage returns or failures. Now, based on a customer’s status, Partners can easily activate and deactivate customers as needed.

Additionally, we have split out the customer’s verification status (active or deactivated) from the bank account status (verified, unverified, or removed). This provides a better understanding of a customer’s ability to accept or receive transactions.

We believe these changes will make a serious impact on our Partners’ ability to resolve failed transactions, and in-turn makes their day-to-day payments operation more fluid and effective.  

Stay tuned, these changes are just the start to our ever-pursuant goal of making Dwolla’s Dashboard the standard in ACH transaction management.

Interested in learning more? Contact Dwolla

Announcing new open-source software to help connect poor customers to digital financial services

Posted in Blog, updates on October 16th, 2017

At Dwolla, we have the opportunity to solve for difficult problems and deliver amazing products every day. A few years ago, we were approached by the foundation to assist in building something ambitious—an open-source code for creating an interoperable payments infrastructure that could be leveraged by developing nations.

Today, we’re thrilled to share with you what came from that ambitious idea. Announcing Mojaloop, a completely open-sourced solution.

The teams from Crosslake Technologies, ModusBox, Ripple, Software Group, and Dwolla have come together, with support from the Bill & Melinda Gates Foundation, to create the software for a real-time payments system that can be adapted to serve different countries and customers.

In this blog post, we’ll explain why we found contributing to this project so necessary, and we’ll outline Dwolla’s specific contributions to the project.

A Brief History of the Project

In 2015, the Gates Foundation started with a vision for “designing a new system for financial inclusion.” It was an aspirational endeavor focused on helping the less fortunate across the globe.

In order to accomplish their mission, the foundation published a series of design principles that would shape the open-source payments project and act as a call to action for collaboration across organizations. The design principles include:

  • A push-payment model with immediate funds transfer and same-day settlement
  • Open-loop interoperability between providers
  • Adherence to well-defined and adopted international standards
  • Adequate system-wide shared fraud and security protection
  • Efficient and proportional identity and know-your-customer (KYC) requirements
  • Meeting or exceeding the convenience, cost, and utility of cash

With these principles in mind, the Gates Foundation set out to harness the power and sophistication of a real-time payments system and make it available to financial institutions and commercial providers (e.g. telcos) in developing countries.

Furthering the Mission

Once the development team was assembled, we started the project by understanding how individuals in developing nations currently facilitate payments. This baseline understanding was necessary for moving forward on the problems we were trying to help solve.  Looking back, the breadth of knowledge shared throughout this project is impossible to briefly summarize.

After countless calls, work-sessions, and meetings, the release of the final open-sourced solution today is a true victory for the development of global payments. The adaptability offered by the project evens the playing field, so everyone can benefit from the sophistication of a ubiquitous payments infrastructure.

It’s hard to effectively convey the amount of appreciation we have for this work and the expertise of those who contributed to it. All we can say in a simple blog post is thank you; thank you to everyone who helped us learn, grow, and deliver a great product!

Dwolla’s Involvement

At Dwolla, we saw this project as an excellent opportunity to contribute and share our knowledge and experience building in the fintech space. The potential to positively impact the future of payments on a global scale was captivating.  

You might be asking yourself,Why Dwolla?

In recent years, our focus has been on providing our Access API partners the best solutions and experiences. So how could a B2B, SaaS company provide value to an international payments landscape?

Our involvement in the project focused on leveraging three distinct facets of knowledge:

  1. Reflecting on FiSync–sharing our lessons learned and experiences from implementing a real-time payments system in the domestic U.S. market.
  2. Considering our Fast Payments Proposal–leveraging the ideas serving as the cornerstone of the proposal Dwolla submitted to influence the United States payment infrastructure in 2016.
  3. Channeling lessons learned from building the Access API–learning from our Access API partners to determine how to build a developer-friendly API, critical for an open-source community.

Leveraging Dwolla’s vast experience in payment solutions, our contributions focused on the elements referred to as the ‘Central Services’ of the project. This series of services focused on building an interoperable system of record that would essentially serve as a clearinghouse for the entire system. The Central Services were comprised of four elements: the ledger, the directory, fraud sharing services, and forensic logging.  

The Ledger

In any payment system, the most critical element is the ledger. A ledger is the system of record for funds transfers, ensuring the appropriate amount is sent from one end-user to another.

At Dwolla, we have spent the better part of a decade creating and fine-tuning our ledger. We leveraged this experience by creating a sophisticated ledger for the project with elements that are essential to an international economy:

  • Facilitates clearing funds between providers in real-time
  • Maintains positions for a deferred settlement
  • Collects centralized fees
  • Promotes inclusion via interoperability and flexibility

The ledger is the core of any real-time payments solution.

 

The Directory

User discoverability provides a unique challenge in the current payment landscape. How do customers on one solution find others across a different platform? The central directory focuses on how to leverage existing rails enabling providers to discover users across the world.

The directory allows providers connected to the system to find other end-users by a phone number or an end-user number. The phone number resolution allows a sender to type in a phone number and send funds to another person regardless of which provider they utilize. The directory was designed with flexibility in mind, allowing the community and implementers to expand and include other identifiers as they see fit moving forward.

Fraud Sharing

Real-time payment systems provide a convenient experience for all users. Developing a solution to protect users from the unique risks of a new platform required the team to think about fraud detection differently. In the project, our approach was to build a centralized framework for all participants to promote the recognition of fraudulent activity.

The fraud sharing service is the foundation to promote the overall health of the payments scheme via fraud protection. The fraud sharing service remains adaptable in order to incorporate different rules and solutions customizable to the needs of the governing bodies and participants.

The foundation of the fraud sharing services is a scoring-based system, which all participants can easily access to empower them to reduce the occurrence of fraud.

Forensic Logging

How do you ensure the confidentiality and integrity of audit events across a vastly distributed payment system? The team created a forensic logging system that combines distributed logging with a centralized key management system. The blend of dispersion and centralization makes this logging mechanism able to transcend technologies far beyond real-time payments. It leverages best practices from the security community such as key management and cryptographic protection to ensure integrity across the system.

The events captured across the implementation can help reduce the impact of one bad actor causing issues for all participants in the open-source solution.

Other Involvement

In addition to building the central services, the Dwolla Team’s knowledge and experience were a shining light throughout the project. Truthfully, our passion towards payments and payments inclusion allowed us to represent our portion, and the Gates Team, in various capacities. Throughout the delivery, our expertise was critical in influencing the following:

  • Real-time Clearing and Settlement
  • Fraud Detection
  • Information Security
  • Engineering practices
  • Agile practices

A once-in-a-lifetime opportunity, Dwolla has been fortunate over the past two years to have worked alongside the brightest of minds in philanthropy, payments, and technology–all while working towards an aspirational end goal. The project team came together to form a “dream team” of payments technology. After numerous hours, days, and months of hard work, we’re proud to share the result with you. Being part of something special and impactful, while leveraging our amazing team’s expertise is an opportunity I will personally cherish for my entire life.

As an organization, we are excited to see where the Gates Foundation and the open-source community, continues to strive to find a payments solution for the betterment of the global economy.

Interested in learning more? Contact Dwolla

How great office culture drives great products and partnerships

Posted in Blog, updates on October 10th, 2017

This blog post comes from Cory. At Dwolla, Cory spends his time working with our Access API Partners as a Partner Integrations Engineer.

 

The open world of post-graduation beckons us to explore, discover, and experiment with our career paths. Graduating from college with a Management Information Systems Degree just a couple months ago, it was time to put my education to good use.

So, I thought, why not put my degree to use with a “hip” startup in Silicon Valley? Or Denver? Or, better yet, why not my hometown of Des Moines? Was it even possible to find a company with a progressive culture in the middle of the proverbial field of dreams?

As a matter of fact, it was possible—enter Dwolla.

Coming into a fast-paced company like Dwolla seemed like a great fit culturally, but I knew there would be a slew of challenges to work through. Namely, learning the ins and outs of our core product, the Access API.

However, jumping headfirst into Dwolla’s day-to-day has shown progressive office culture drives the shipping of great products. Since joining the Dwolla team, I‘ve experienced the value of an open and fast-paced culture. If I were to introduce a stranger to our company culture, they would come out with four takeaways.

1. Working at Dwolla means being passionate about Dwolla

First and foremost, the greatest strength of Dwolla is the fact that the team believes in the product and its success. This was evident from my first day in the office—there was a clear sense of “purpose”.  Already, I have witnessed people going great lengths for the company and its partners, whether someone is jumping in to assist a partner or organizing a company-wide potluck lunch.

Both examples, whether business focused or more culture focused, add up to a great experience for both the people building their careers at Dwolla and the people building with our ACH API. Working for a company that you believe in and that fits your values creates an atmosphere of unity and passion.

2. Good office culture facilitates great partner experiences

Our office has an energy where people put 150% effort into their work and give our partners quality service and a great integration experience.

As a Partner Integration Engineer, my work revolves around ensuring a great onboarding experience for our third-party developers utilizing our API. Working with these developers, I assist them in integrating Dwolla’s RESTful API to make sure it meets business requirements. As a team, we take initiative to respond to partner feedback seriously and improve our Access API based on that feedback.

As an organization, we host cross-functional meetings with the sole purpose of simply being proactive about Dwolla’s customer needs. While our office culture embodies the “Iowa Nice” philosophy of diplomacy and collaboration with our partners, we are fierce believers in hard work and dedication to our product.

3. Culture is more than surface-level

Some might believe that work culture is only on the surface, however, I prefer to think of culture as more of an iceberg. There is a surface-level culture consisting of easy-to-see artifacts, alongside a true “beneath the surface” culture that exists within every organization.

Everyone that walks through Dwolla’s front door sees our surface-level culture—the open floor plan, casual dress code, ping pong table, etc. What’s harder to observe is the culture beneath the surface…

In my first month, I have witnessed the “beneath-the-surface” Dwolla culture by observing how people respect one another. The structure of the organization puts decision-making responsibility on the people who understand the product from many different segments of the company.

Read More: What a typical day looks like when you’re selling an ACH API

4. People matter as much as processes

Working to build a robust RESTful API is not straight-forward every day, but working with passionate team members definitely, helps provide buy-in and keep everyone aligned.

Dwolla makes it a priority to put partners first. Working with the teams of our partners requires a level of commitment to not only our API but also to supporting the business and applications that our partners are creating. Ensuring that our relationships remain solid with our partners and third-party developers are paramount to the success of the Access API itself.

Looking back…

Looking back at my first months and the onboarding experience with Dwolla, being the new guy in the office has never felt so welcoming.

From day one, it’s apparent the office culture of Dwolla is something that will not only be a point to celebrate in times of prosperity but a pillar of support for day-to-day activities. It makes me proud to build in Iowa, and I look forward to keeping my roots planted in Des Moines.

Like what you’re reading? Check out Dwolla’s job openings.

Interested in learning more? Contact Dwolla

Detect fraudulent behavior in the Access API with bank account fingerprinting

Posted in Blog, updates on October 4th, 2017

Preventing fraud—the constant battle between the good and the bad actors in payments, with the good always trying to outpace the bad. As a payments company, we understand that fraud exists and acknowledge that fraud prevention is an important piece of any payments process.

In our effort to help Access API partners monitor and prevent ACH fraud, we have created “fingerprints” for bank accounts.

Being in-tune with our partners’ payments needs, we know there are areas we can lend a hand and help them better identify fraud on their platforms, so we’ve created a solution to help identify when the same bank account is tied to multiple user accounts.

Fingerprinting a bank account accomplishes many things:

  • A fingerprint is merely an identifier based on a Message Authentication Code (MAC). It cannot be reverse engineered to decode a user’s bank account and routing number. Since it is only an identifier, we’re keeping sensitive banking information out of the fingerprint.
  • By passing this fingerprint back to our partners, we’re empowering them. They can run any number of tests on their own internal data using fingerprints without needing to rely on Dwolla’s development to identify those bad actors.

Understanding by example

The good: There are situations where having one verified bank account tied to multiple users is completely valid. For example, if a couple shares a bank account, and both create accounts on a platform, it is likely they will connect the same bank account. And there you have it, two users with the same bank account; everything is completely kosher.

The bad: Sometimes bad actors will find a way to defraud a business and exploit that finding by setting up more than one user account, all tied back to the same bank account. As that bad actor funnels money into the bank account—often in small amounts to avoid detection—he or she then quickly move the money out of the network for safe keeping. It isn’t until the ACH file is processed and the resulting transfers fail that our partners understand the true scope of the vulnerability.

Using Fingerprinting

Partners can use this fingerprinting in a few different ways. For example, a partner may develop an internal process that uses fingerprints across multiple accounts along with the frequency of transactions to help determine and identify bad actors. Others might use fingerprinting to help detect and, in turn, deactivate any account as a precaution if it is identified as having the same fingerprint.

With this new feature, we’re empowering our partners to take a positive step towards better ACH fraud detection.  

Interested in learning more? Contact Dwolla

Understanding the ACH returns process

Posted in Blog, Knowledge Base on September 27th, 2017

As a Sales Rep with Dwolla, I often find myself educating others about not only about our tech stack, procedures, and company but also about the logistics of ACH payments. That process usually includes a candid conversation about ACH returns…

  • What are they?
  • Why are they important?
  • How does Dwolla help?
  • And what does that mean for your business?

An Overview

ACH stands for the Automated Clearing House—it’s an electronic network allowing banks and their customers to send funds between one another in the US. NACHA, the self-regulatory body that manages the development, administration, and governance of the ACH Network, enforces a set of rules for when an ACH payment fails, which is called an ACH return.

NACHA rules apply to all participants in the ACH network, which includes not just banks and credit unions, but any entity who originates entries to the network or forwards on entries on an Originator’s behalf. For example, when you pay a utility bill via ACH, your utility company’s sends an ACH debit entry to its Originating Depository Financial Institution (ODFI). The ODFI sends the debit entry to the Receiving Depository Financial Institution (RDFI) that holds their customer’s bank account.  These transactions are settled within a business day; however, if there are insufficient funds in the customer’s bank account, an ACH reject will be issued and passed back within 2 business days of the receipt of the entry.

Most ACH return codes are received by the ODFI or RDFI two to three business days after the transaction was originated. However, other codes—like an R07 and R10—may be filed up to 60 days later (on behalf of a consumer bank account) after the transaction was originated.

You may be familiar with ACH return code R01 – Insufficient Funds, which simply means the available and/or cash reserve balance is not sufficient to cover the dollar value of the debit entry. That is just one example out of around 85 total ACH return codes that can happen.

However, each return code constitutes a different reason a payment can fail: some are administrative in nature like R02 and R03, yet others like R10 or R29 are more likely to be fraudulent in nature.

Here is a full list of ACH return codes

There are so many reasons an ACH payment can fail and logistics behind that payment failure are complicated, so it’s really no surprise I find myself spending a lot of time educating others about this ACH returns process.  

Below is a high-level overview of the complexities behind ACH returns.

Complexities of ACH returns

So what actually happens behind the scenes? What are the logistics of an ACH return?

For starters, remember the ODFI and RDFI I mentioned earlier. The process to move funds between the two institutions is not a one-step process, and if an ACH entry fails, that process becomes more lengthy and complex. Namely, the respective RDFI must initiate a reject and the ODFI then must make the appropriate corrections based on which of the over 85 ACH return codes took place. Further, there are some scenarios, such as fraudulent attempts, which can result in a funds-loss situation, requiring more action. Putting the lifecycle in the absolute simplest of terms, the following occurs. 1. A transaction is initiated. 2. The RDFI notifies the ODFI that there is an issue with the respective entry. 3. The ODFI takes appropriate corrective steps based on the return code. 4. The transaction ultimately fails.

While complex, ACH returns are an important aspect to understanding and implementing ACH payments. Returns can be difficult for any business to decipher while remaining compliant with NACHA rules, regulations, and law.

How Dwolla Helps with ACH Returns

Fortunately, Dwolla is here as a partner for you to help streamline the ACH transaction process. As an expert in bank transfers, we’ve spent the better part of a decade bringing automation and innovation to ACH payments.

Our Access API is incredibly simple—and our partners can attest to that.

All of this is wrapped up neatly into a simple, intuitive API and dashboard to help you monitor everything happening on your platform.

When it comes to helping your business handle ACH payments, ACH returns, and aforementioned complexities, perhaps the most important value we provide our customers lies not in any tangible product or feature, but rather in our overall strategy as a company.

We’re a partner, not just a vendor. And we collaborate and work with our customers, listening, understanding, and building mutually beneficial relationships. Yes, we provide a class-leading RESTful API with beautifully architected code and innovative features, yet we absolutely keep your satisfaction and business needs front and center. Feedback is a part of the process. Your success is also ours. Whether strategizing and building your business from the ground up, or launching a new product line, or perhaps completely re-thinking how your business goes to market, we’re here for you. Leave the complexities and heavy lifting of ACH payments to us. Focus on what you do best.

Interested in learning more? Contact Dwolla

The value of partner feedback and the new CorrelationID

Posted in Blog, Developers, updates on September 21st, 2017

This blog post comes from John Jackovin, our Senior Product Manager at Dwolla. 

 

I love partner feedback.

As a product person, I’ve always been wired that way—and you just have to be.

I especially love partner feedback when I’m able to easily identify trends, hearing the same thing over and over (and over).  Why, you might be wondering?

Because it means there is a common need that our Access API Partners share, and my goal is to make sure real partner needs are met—and met quickly.

Even as we develop new features for our Access API product, I’m always listening to what the partner needs. For example, when we added multi-user functionality to the Dashboard, our partners had a large influence in that.

More feedback, more improvements

One particular ask we have been hearing more frequently from our Access API partners is for the ability to create and use a partner-generated identifier on payment transfers and mass payments. The need to create this sort of ID is compelling—if you think about it, the transaction is initiated by the partner and undoubtedly an ID will be generated by the partner, but not until it is sent to Dwolla will the partner know the ID that corresponds to that transaction. This makes the correlation between the two transactions potentially cumbersome, and our partners were looking for a way to follow a transaction throughout the entire process, from initiation to completion.

In order to help simplify the process for our partners, we have created the CorrelationID. The CorrelationID helps improve the traceability of a transaction, between two systems; it allows you to create an ID and use that ID from the point of origin on, instead of waiting for a response from Dwolla to then get an ID.

This CorrelationID is generated by an Access API Partner and can be used throughout the ACH transaction process to identify both single transfers and mass payments. The CorrelationID is also searchable within the API allowing a much more simple interface to and from Dwolla.

Now, partners can generate and use their ID throughout the flow making the correlation process more efficient.

Our product team is excited to see and learn from how our Access API Partners use this feature. Additionally, as we continue to listen to feedback, I look forward to providing more features that help simplify and streamline the ACH transaction processes.

Interested in learning more? Contact Dwolla

©2017 TransSwipe

 


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