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

TransSwipe - Merchant Services and Credit Card Processing

Archive for the ‘featured’ Category

FiSync and the Federal Reserve’s role in faster payments

The last week marks some memorable things:

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

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

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

Advising on a better payment system

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

Why we choose to contribute

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

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

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

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

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

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

My final thought

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

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

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

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

 

When and where to Integrate ACH Payments, 4 Examples

on-demand-bank-transfer

Credit cards are common, well known and widely used, but their ubiquity doesn’t make them the best payments option for every new application and platform being built. When you’re integrating payments, you have to make the smartest decision on how to move money therein.

That’s where ACH transfers come in, and integrating ACH payments is more functional than ever with Dwolla’s bank transfer API. Whether you’re moving money between users’ bank accounts or paying out thousands of service providers, consider an ACH solution.

But wait, that sounds pretty abstract, right? How do I do what?! Let’s make it more tangible—take a look at some proven examples of integrating with the Dwolla’s ACH API to improve payments.

1- Integrate ACH into mobile applications

slider-mockup-1Consumers are relying on mobile applications more than ever, and new services and apps are being developed to serve this rising trend. We’ve gotten to know a few companies building their own innovative applications, who are also leveraging the ACH network via Dwolla.

One example is Sweep, a mobile application that encourages better savings habits by using various spending ‘buckets’ to track goals, expenses and bills. With Dwolla, Sweep users have the ability to move funds between bank accounts and savings buckets within the app.

Another example is Lenny, which uses Dwolla’s ACH API to send GPA-based micro-loans to students bank accounts , all within the mobile application.

2 – Integrate ACH to deliver payouts to service providers

If you’ve built the best platform tailored to a unique demographic or target audience, be sure you’ve also integrated the best option for that audience to get paid. Consider college referees for example…

Hundreds of sporting events take place every week, but have you ever stopped to think about how those refs get paid? The folks at Blue Zebra Sports did. Their platform is a one-stop-shop for managing refs and officials, from scheduling to payments.

review-games-screenshot

They chose Dwolla to deliver payouts to refs—here’s why:

“The reason we decided to use Dwolla is that it fit perfectly with making things easy for officials. To get paid, they enter their bank account information in Dwolla, and then they can get paid. It’s also easier for our conference clients; they connect a bank account and make payments directly from their checking account—no managing wire transfers or ACH deposits into a third party account before being able to pay officials.“

Jeff Wigal, Founder and CTO

3 – Integrate ACH to improve your marketplace

Similar to paying out service providers is paying out sellers in a marketplace. We have a wide variety of partners that use our ACH API to deliver payouts to their vendors. One of our favorite examples comes from boutique marketplace  Jane.com.Jane.com Blog Header

By building bank transfers right into their platform with our  API, Jane.com is able tohey programmatically deliver payouts to thousands of boutique sellers. The the boutique’s sales are paid right to their bank account.  

Another example of using ACH for payouts is Wunder, a solar energy investing platform. Their investors and investees are paid out solely via Dwolla’s API. To invest in solar energy, just connect a bank account.

4 – Integrate ACH to offer an additional payment option on your platform

Finally, a simple, yet smart addition of ACH payments is as an additional payments option, right alongside credit cards. For businesses, there is supreme benefit to encouraging adoption of ACH over paying with a credit card—you keep more money because you cut out those pesky percentage-based transaction fees.

WODTogether did just this. They’ve built a platform for better gym management and integrated Dwolla’s bank transfer technology (in two weeks) to save its users money in collecting recurring membership fees.

WODTogether dashboard

Whether you’re looking to move money in a mobile application or make payouts to the thousands using your platform, tapping into the ACH network is always a smart option to explore.

For more information on how you could improve payments processes, contact an integration specialist today. Just drop a line in below.

Get started with ACH transfers

We’ll help you design your ideal payments experience.









Loading...

Thank you

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

Sorry

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

Dwolla’s Open Sourced Developer Documentation Portal

Dwolla’s developer docs have gotten pretty darn good. We’ve discovered some really cool things that are working well and wanted to make these best practices available to anyone who might find them useful.

We’ve open sourced three repositories on GitHub today that we hope are helpful to developers building on top of Dwolla’s APIs and make it easier to suggest changes to the docs.

Our Developer Portal

Screen Shot 2016-02-16 at 2.36.53 PM

One of the challenges we’ve had in the past is producing an intuitive experience that isn’t only developer documentation for code. There needed to be a section for getting started guides, how-to’s, SDKs, and more.

The technical documentation typically needs to function a bit differently than other content, so we made that a supporting element to the primary portal.

You can see the live docs here – https://developers.dwolla.com/
You can find the Github repo here –https://github.com/Dwolla/open-source-developer-portal

v1 Documentation

Screen Shot 2016-02-16 at 2.45.12 PM

Powered by Slate, we’ve made a great deal of changes. The v1 documentation is largely focused on our OAuth API for developers building on Dwolla.com’s platform and applications.

You can see the live docs here – https://docs.dwolla.com/
You can find the Github repo here – https://github.com/Dwolla/v1-payment-api

v2 Documentation

Screen Shot 2016-02-16 at 2.46.12 PM

Powered by Slate, we’ve made even more changes to this one to live inside of the primary developer portal. Currently, the v2 documentation is largely focused on white label ACH integrations.

You can see the live docs here – https://docsv2.dwolla.com/
You can find the Github repo here –  https://github.com/Dwolla/v2-ach-api-docs

Have any changes you’d like to see made? Go to our GitHub profile and submit your feedback or pull requests.

For those of you interested in learning more about our ACH API for implementing custom white label integrations, contact an integration specialist or get started in our sandbox environment.

reach out now

On-demand Bank Transfers, made easy

on-demand-bank-transfer

In 2011 we released an OAuth API that made it easy for developers to request transfer permissions from their customers with our Dwolla-branded platform.

Today we’re making the ability to bill your customer later available for our Dwolla White Label customers in our v2 API.

It’s called On-Demand Bank Transfers.

Developers using our white label APIs can enable their payers to authorize transfers for variable amounts from their bank account using ACH at a later point in time for products or services delivered. It’s one simple additional step—a quick authorization from the customer when they instantly verify a bank account. This is great for companies like:

  • Cloud computing services. Fees can be different every month, requiring ongoing authorization so a customer can easily pay for a service, and the company can easily bill for the service.
  • Utilities. A water company bill is rarely the same each month. Same with electrical, and gas. The amount collected at the end of each month is usage-based, or metered.
  • Ride sharing or asset sharing platforms. The amount a customer is charged for a ride across town depends on a variety of factors. We make it easy for sharing companies to bill their customers, while reducing the hassle for the end customer on each trip.
  • B2B services that bill on a variable basis. Some orders may require a bank transfer on NET terms and others may be fulfilled once the goods are delivered. Either way, both should be possible.

The instant bank verification and on-demand authorization occur with Dwolla.js to make it incredibly easy to add to your software. It adds an extra step to the bank transfer process when verifying the bank to acquire the permission for the account holder.

On-demand payments from Dwolla

Once you have collected all of the authorizations required for a bank transfer, including the additional authorization from the end user for on-demand bank transfers, your software application kicks off a transaction that looks like this whenever the customer needs to be billed:

{
    "_links": {
        "source": {
            "href": "https://api-uat.dwolla.com/funding-sources/5cfcdc41-10f6-4a45-b11d-7ac89893d985"
        },
        "destination": {
            "href": "https://api-uat.dwolla.com/customers/C7F300C0-F1EF-4151-9BBE-005005AC3747"
        }
    },
    "amount": {
        "currency": "USD",
        "value": "225.00"
    },
    "metadata": {
        "customerId": "8675309",
        "notes": "Payment for January 2016"
    }
}

As usual, there are no per transaction fees for either party in the transaction, and with our white label services your brand is front and center. If you’re a developer and have more questions, head to our API Support discussion board and post your questions. Our engineering team regularly reads and responds on the board.

The cost and complexity to make bank transfers better isn’t unknown and it affects new fintech companies, large established business, and even big VC’s… We all have the same problem.

We didn’t either and that’s why our team has spent the last 5 years focused on bank transfers. It’s why we feel on demand bank transfers are so incredibly valuable for our customers.

There is a better way and we’re excited to be a part of building the future making bank transfers easier for businesses and developers.

Contact us to enable for your application

5 Things you may not know about Dwolla’s ACH API

5 things blog post

As we develop our partnerships, we’re seeing exciting new ways that our ACH API is being put to use. With that, we wanted to share some items that may not seem obvious—read on to learn 5 things you may not know about Dwolla.

Did you know…You can build account-to-account transfers into your consumer application with Dwolla

The fintech revolution is here, look left and right and you’ll see new applications and platforms enabling smarter use of money, be it for investment, savings or simply paying back friends. When Dwolla was first developed we focused on putting our mobile app in the hands of users to pay their favorite businesses. Things have changed.

Today, we’ve realized the value of our API is in what others can build with Dwolla powering ACH transfers.

For example, fintech startup, Sweep needed a solution to allow its application users to move money between two bank accounts. They integrated Dwolla into their application. Now, whether a user wants to move funds from Bank of America to Wells Fargo or from Wells Fargo to a Chase bank account, they can. Better yet, Sweep will let you do this as often as possible since there are no per-transaction fees.

Summary: If you’re building an application, Dwolla’s API can enable a peer-to-peer funds transfer function between various bank accounts.

Did you know…Dwolla plays well with other payments technologies and APIs

If there’s one thing Dwolla does well, it’s bank (ACH) transfers. Programmatically or electronically bringing traditional ACH processing into the 21st century is our jam. Where do bank transfers perform best? Often times in investment platforms  or paying out vendors or contractors that fuel your marketplace or on-demand service model.

We don’t mind if you use other payment vendors to accept credit or debit card payments. We’ve partnered with a number of large marketplaces that use Dwolla exclusively for paying out their vendors, while using other payments APIs on the front end to process credit cards.

Did you know…Dwolla offers a  highly customizable White Label integration

Another value-add to partners is the extent to which you can customize a White Label payments integration. Dwolla can help you facilitate bank transfers via the ACH network for your customer through your own platform. Imagine a payments experience that feels and looks just like your website or portal—we’ve got that.

With our customizable stylesheet, one partner’s integration can look vastly different from the next. Change the fonts, alter the button colors, it’s all up to you.  We’ve built a demo of our dynamic bank verification experience so you can play around with it.

Did you know…We are compatible with mobile apps and interfaces

Mobile apps appear to be taking over the world. Sure you build a website, but the number of users accessing your application while on their phones is on the rise. Dwolla plays well here, too. Our API works with mobile seamlessly.

Sweep, who we mentioned above, built a fintech mobile application and easily integrated Dwolla to provide a bank transfer functionality. More and more, we’re seeing partners with similar needs, and Dwolla has proven a good fit for their payments.

And for our developers:
Did you know…We have RESTful API which implements the HATEOAS constraint

I repeat, we have a RESTful API which implements the HATEOAS constraint.

What does this mean? We use hypermedia, basically links & link relations, to tell you about all the actions that can be performed on the current resource, allowing you to traverse the API from a single entry point.

The entire API is discoverable starting from the root URI, documentation is not needed!

If you’ve learned something new about Dwolla’s API for bank transfers and want to learn more, reach out to one of our knowledgeable integration specialists.

Send a harmless email

Fake it as you make it: why fake services are awesome for developers

 

This blog post comes from Shea Daniels, a developer here at Dwolla. When Shea isn’t busy building awesome new things, you can find him out for a run. api-blue

It’s often said in life that we “stand on the shoulders of giants.” This rings especially true now that we’re in an era of abundant open source software and SaaS providers. Now, more than ever, we build applications by relying on tools and services that others have made. This may even be standard practice inside your own organization as other teams deliver functionality through a microservices architecture.

Building software by composing services is extremely powerful, but it can still be a rocky road. Several factors can make it difficult to write and test your code:

  • Complex scenarios may not be easy to test with real data
  • Running elaborate business logic may consume resources
  • Sandbox environments may not exist for 3rd party APIs

Just fake it

So what can be done to mitigate these issues? The answer is to fake it while you’re making it!

You can see this in everyday life. Whenever the real thing is too expensive or impractical, we sub it out with something fake as a stand in—think movie props or mannequins for tailors. This is also a fairly common engineering practice; my favorite examples are the boilerplate capsules used to evaluate rockets and other space hardware.

In the software world, if you practice TDD you should be familiar with the use of test doubles (mocks, fakes, and stubs) for dependencies in your unit testing code. Used instead of the real implementations of objects, fake dependencies isolate the code under test by providing predictable results given certain input. This isolation is useful for tracking down issues and fully exercising your code without complicated setup.

The same concept can be applied when developing an integration with a third party service. By building a fake copy of the web service, you gain the same advantages of isolation and repeatability as you test your application. This is especially useful if the service you’re depending on is being developed in tandem and has yet to be fully implemented.

There are some existing tools for quickly standing up your own fake services, such as Nock and Frock. But with Node.js and a few NPM packages, it’s easy enough to build your own from scratch.

In this post we’ll include:

  • An actual example
  • How to get started
  • Possible scenarios
  • Some of the downsides

A real example

Let’s break down a real example that Dwolla has recently open sourced: Nodlee. You can see it in action by checking out our instant bank account verification demo—here it’s used as a backing service.

blog---dwolla.js-final

Getting started

Nodlee is a simple web server written in Javascript and run via Node.js. It depends on the following NPM packages, which you can see in the package.json file:

minimist – argument parser library

If you haven’t used Node or express before, there are a ton of great tutorials, or you can read through the Nodlee source code to get a feel for it. The readme has a lot of great info and the code entry point is app.js.

Responses

The first thing to do when building out a fake service is to look at the documentation for the real API and experiment with the service to discover how it works. With that knowledge, you can figure out which endpoints need to be mocked and what the responses should look like.

For a simple example, here’s the Nodlee health check endpoint response: health.js

module.exports = function (req, res) {
  res.json({ healthy: true });
};

These responses can be as simple or as complicated as needed. If returning the same canned response every time isn’t enough, consider scanning the request for sentinel values that you define. Then you can use those values to decide which data to send back. You can even use a templating language like Handlebars for generating your responses if you want to get swanky.

Complex scenarios

For the instant account verification product we were building, even sentinel values and templating weren’t quite enough. We found that we were constantly editing multiple files in the fake service code to set up complex scenarios.

The first step to making this easier was to consolidate all of the possibilities that determined a particular scenario into a single list of options in the code: scenario.js

module.exports = function Scenario() {

	this.contentServiceId = 0;
	this.isMfa = true;
	this.mfaTimeout = false;
	this.mfaPass = true;
	this.mfaTypes = ['q'];
	this.refreshesSet = 1;
	this.refreshesLeft = 1;
	this.errorType = 0;
	this.accounts = [
		{
			routingNumber: '222222226',
			accountNumber: '5031123001',
			accountType: 'CHECKING',
			accountHolder: 'John Wayne',
			accountName: 'Your Account #1',
			balance: '1000'
		}];
}

This object can then be checked in all of the service endpoints in order to determine the appropriate response. With this in place, developers could set up the flow to behave however they wanted just by editing this single file.

Sentinel values on steroids

We have local development covered now, but what about testing in sandbox environments where we can’t edit the fake service code? Not only that, but what if we wanted coverage of our flow with automated UI tests (e.g. Robot Framework)?

What we need now is a service with a memory longer than a single web request and a way for automated tests to trigger whatever scenario is needed. This is where the minimist and node-cache NPM packages come into play.

With minimist, we are able to take certain inputs in a web request and treat them as if they were command line interface options. Those options can then be translated into order to set the properties of the Scenario object we’ve just discussed: 

var scenarioData = optionsParser.parse(req.body.someInput)

optionsParser.js

exports.parse = function(options) {

	var data = new Scenario();

	if (options.indexOf("-") < 0) {
		return data;
	}

	var args = parseArgs(options.split(' '));

	if (args['nomfa'])
		data.isMfa = false;

	...

	return data;
}

Now that we have the options set for the scenario we want, we use node-cache to persist it across web requests: scenarioManager.js

var cache = new NodeCache({ stdTTL: 900, checkperiod: 300 });

exports.set = function(...) {

	...

	cache.set(userSessionToken, scenarioData);
	return scenarioData;
};

Now we can use the cache to access the scenario that’s currently being tested at any point we need to build a response: getMfaResponse.js:

module.exports = function(req, res) {

    scenarioManager.get(req.body.userSessionToken, function(scenarioData) {

        if (!scenarioData.mfaTypes) {
            ...
        } else if (scenarioData.mfaTypes.length < 1) {
            ...
        } else {
            ...
        }
    });
};

The downsides

As with anything, fake services are not a silver bullet. There are a few caveats to keep in mind:

  • Are you sure you understand the real service well enough to build a fake version of it?
  • Watch for edge cases where you may not be duplicating the behavior of the real service
  • If you do find edge cases, be sure to cover them with appropriate tests; manual testing with your fake service is not a replacement for good test coverage with unit/integration tests
  • Plan for regular maintenance of your fake to keep up with any changes in the interface or behavior of the API you depend on
  • Using a fake does not relieve you from the task of running your code against the genuine article

The last bullet point is important since there’s a large difference between “should work” and “actually works.” At some point in your workflow you’ll need to test the full production stack!

Conclusion

Here at Dwolla we’re committed to making developers’ lives easier by providing a great API for moving money with ACH transfers. We’ve found the concept of fake services to be invaluable in making this happen. If you found this useful, please share this article and comment with your own experiences. Happy building!

Check out the documentation

Dwolla Case Study: How Sweep Uses Dwolla ACH API for Bank Transfers

How Dwolla’s White Label ACH API quickly allowed fintech platform, Sweep to get to market.

Download the case study as a PDF
.

slider-mockup-1According to Center for Financial Services Innovation, consumers who have regular savings habits are 4X more likely to be financially healthy than those who don’t. Unfortunately, 57% of Americans still struggle financially and more than 72% suffer from stress and anxiety related to money (American Psychological Association). Sweep hopes to fix that.

Problem: A consumer fintech platform wanted to offer its customers an automated savings product using bank-to-bank  transfers.  The company needed to meet all regulatory and compliance requirements in an aggressive timeline.

Results: The company integrated Dwolla’s White Label payments API to facilitate ACH transfers in around 40 hours and successfully announced product on-stage at Money2020.

The Situation

How Sweep Uses Dwolla ACH API for Personal Financial Planning App

Sweep was created to help young, millennial consumers save and stay ahead of their needs.  After downloading Sweep’s mobile app, users connect the platform to their bank accounts and then organize their funds into “buckets” for goals, expenses and bills.  

From the very beginning, the vision and roadmap included automating these savings behaviors to fill those buckets and grow savings according to the user’s needs.  For example, a user who created a “Wedding” bucket would be able to automatically transfer $100 from her main checking account at a multinational bank each payday to a savings account associated with the goal—in this case, say, at her local credit union. Unfortunately, Sweep encountered a number of regulatory and technical hurdles that prevented them from including and automating bank-to-bank transfers in its initial launch earlier in 2015.

The Challenges

Lacking this functionality to programmatically transfer funds meant users had to visit separate online banking portals and manually transfer funds between banks to fulfill their savings goals. Automating the process was critical for millennials and they didn’t have it, yet. 

FinTech Application Sweep Uses Dwolla API for Bank Transfers

“Unfortunately, our ideas were too new for the banks and traditional payments processors. We considered building our own payments gateway but the banking relationship and compliance requirements would have blown up our roadmap and crippled our product plan.  We needed an innovative technology partner with a proven banking relationship.”  

CEO and Co-founder, Jackson Gates

Jackson - Sweep

Time to market

An end-to-end payments solution would require a direct banking relationship and 3-6 months of development time, not including the upfront compliance and regulatory hurdles.  Other payment gateways were working on new banking relationships but couldn’t guarantee a timeline or necessary functionality.  Sweep needed an immediate solution.

Solution: Unlike other payments solutions, which used non-descriptive and difficult to parse XML, Sweep leveraged Dwolla’s “clear and concise API documentation and excellent engineering and customer support” to build the solution in around 40 hours.

Outcome: With Dwolla’s White Label API, Sweep was testing live payments within days, and completed all production testing in-time for its Money 2020 announcement.

Regulation and compliance concerns

In addition to the time and cost associated with compliance and regulatory requirements, the uncertain and shifting regulatory climate made it difficult to predict the mid- to long-term needs of supporting a proprietary payments infrastructure.

Solution: Through Dwolla’s API and built-in processes, Sweep outsourced its payments back end, including bank transfers via ACH, to Dwolla. By partnering with Dwolla, Sweep leveraged Dwolla’s experience for managing the compliance, fraud, and security elements of its payments experience.

Outcome: Sweep launched its automated savings product with fixed and comparatively minimal direct and indirect costs. By leveraging Dwolla’s banking relationships, Sweep avoided holding customer funds or inserting itself in the funds-flow, thereby reducing regulatory and compliance challenges.

Core functionality and user experience

Sweep’s strength is its ability to create a simple, beautiful mobile interface and user experience.  The company was wary of integrating any functionality that would feel foreign to the app or confuse the customer.

Solution: Dwolla’s payments platform helps with handling KYC, customer records, adding bank accounts, and initiating ad-hoc and recurring transfers using event-based webhooks. The white-label API allows Sweep to offer a seamless user experience while maintaining the look and feel of the Sweep app.

Outcome: Today, Sweep users enjoy a full-featured, powerful savings tool embedded in a Sweep branded, beautiful mobile experience.

Screen Shot 2016-01-21 at 12.28.02 PM

Screen Shot 2016-01-21 at 12.27.26 PM

Interested in learning more about an ACH API for better payments? It’s simple. Reach out to an integration specialist to learn more.

Reach out now, green

5 Qualities of a Good Payments API for Bank Transfers

Payments API

There are APIs abound for integrating credit card transactions into your platform or application, but what about an API for ACH transfers? Here’s what you should be looking for when determining if an ACH solution is right for you:

Flexibility

ACH transfers aren’t always a bed of roses, especially if you’ve explored building your own solution with a financial institution. What you save in a relatively low initial integration cost can add up in dedicating months of your time and energy to meeting all of the compliance requirements and building all of the processes necessary to pass any financial industry test. That’s why many companies and developers are turning to software companies that have built and open sourced their own ACH APIs. These APIs allow you to tap into their network of experts and functionality in order to make ACH transfers work for you, in a way that fits with your business and customer needs.

Customizeable

If you have a well-established product, you’ve spent the time, money, and burned the brainpower growing your customer base and brand. You may be leery of introducing your customers to another platform to create another account for making or receiving payments via your app or site. A quality API allows for various customization options and control, and is adaptable for specific use cases and scenarios. The ability for an API to scale alongside your business—whether it’s on the front or backend of your product—can make for a winner.

Intuitive and complete documentation

Nothing is more irritating than searching an entire site or forum for what you need, bouncing between different tabs, and trying to piece together information. Software providers that have removed the busy work, and put in the time to accurately and simply document their APIs in a way that a developer would need to read it while coding alongside is invaluable.

Working examples

Finding a payments API with working examples of its integrations out in the wild is always attractive. The more variety of use cases, the better—these use cases demonstrate the possibilities after putting a little creativity into developing a tailored solution that works best for your unique needs.

Great support

When developing payments into your platform, there may be questions that you just need to float by someone that works on that API for a living. There’s great value in finding a service that is committed to getting you and your product to market before you rip every last hair out trying to Google the answer.

Are you looking for a better ACH solution? If so, we’d like to invite you to contact one of our integration specialists so we can introduce you to a solution that fits your needs. Or, take a tour of our developer portal, where we offer extensive API documentation, starter guides, and other resources to help you begin building.

Let's talk aCH payments

Facilitator fees are now free to use

Facilitator Fee

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

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

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

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

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

The facilitator fee does a few things well:

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

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

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

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

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

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

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

Go build something great with Facilitator Fees.

Cutting out the busywork for developers with better design

blog-post-image-530x239

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

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

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

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

Defining experience goals

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

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

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

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

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

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

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

Reduce the busy work

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

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

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

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

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

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

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

CopyButton

  • Global language selector, enabling fluid selection

GlobalLanguageSelector

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

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

We are never done.

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

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

View Developer doc

©2017 TransSwipe

 


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