A successful payments integration can help companies take their services and functionality to the next level. Having a delightful payments process can be an invaluable addition to the services a business provides its end-users.

In this blog post, we’ll share valuable perspective from a pair of Dwolla’s Developer Advocates—Cory Anderson and Spencer Hunter—to understand what goes into a successful payments integration process, once the contract closes.

Both recommended dedicating time to read and understand the developer documentation guides and resources along with the official software development kits (SDKs).

“If you nail step one and two, the subsequent steps three, four and five will just be a breeze,” Anderson says.

Here are those five steps for a successful payments integration with Dwolla once a contract is signed and your application has been approved:

Step 1 – Understand the requirements

Spencer: Plan or estimate, based on your contracted funds flow, what end points you’ll be calling and how it all fits together. This is mapping out each interaction they need to take.

Cory: As an example, due to compliance or contractual agreements, we only allow for a certain funds flow to have a certain type of Customer.

Occasionally, we have contracted API Customers start by creating the wrong Customer type which may have consequences later during their integration. As long as you are not spinning your wheels on step one and you’re are able to determine the correct requirements, that’s a win right off the bat.

Step 2 – After application approval…setup a sandbox account

Spencer: Setup a sandbox account and get familiar with the API documentation, where you can go to ask questions or answer the things that are outlined in your contract as to how you will use the API.

So it’s just familiarizing yourself with the intricacies of the API and getting setup.

Cory: And taking a look at our helper libraries, they do a lot of work for you.

Spencer:
What an SDK does is provides benefit in that it abstracts away a lot of the API requests and responses, stuff that occurs so you don’t have to go out and use a third party client to do that, the SDK will handle most of that for you.

Step 3 – Onboard initial Customers

Cory: At that point if you know what your requirements are and you have reviewed our resources at your disposal, then you should be good to start creating Customers via the API.

Spencer: You have to onboard the user to Dwolla. There are different Customer types and the onboard process may be more in depth depending on what Customer types you are using.

We have different Customer types that have various levels of functionality within Dwolla. So if one Customer goes through identification verification, then we know who they are and they are allowed to do more within the Dwolla ecosystem than other Customer types such as a receive only, who can only receive funds into a bank account. With receive only, the only information required is first name, last name, email and add bank account.

Customers that are identity verified can send funds to users with higher transaction limits.

Step 4 – Attach a funding source to initiate a transfer

Cory: So if you’ve created a Customer—but they can’t send or receive money without a bank—so you need to add that bank to the Customer, and that’s where the instant account verification, micro-deposits or Plaid comes in.

Both are tokenized and lightweight bank verification methods. Plaid, however, is more feature rich.

Spencer:
We have a lot of API Customers that leverage other aspects of Plaids API. It pairs nicely, they do bank account verification very well and we assist with the money movement piece very well.

Cory:
So you’ve created a Customer, added a funding source, now you can initiate a transfer based on what your funds flow is. This is probably the easiest step to do.

Step 5 – Webhooks

Spencer: One of the last pieces to understand is how webhooks work. Basically, a webhook is like a call back for things current in the Dwolla system that our Customers would need to know about. Like when an account gets verified, when an account transaction is completed or failed.

The best way of doing that is for us to push data to them. Since Dwolla generates those events internally when those things happen, we push that data to the Customer and they capture it and are required to do something with it. Whether that is update something in their internal system or send an email notification.

Cory:
It’s like a waiter at a restaurant. Instead of checking on the chef every time to see if the food is done—polling the API—you would wait for the waiter to bring you out food. Polling the  API is just inefficient and has the potential to cause stress on our side if you do it too much.

Basically, we push our webhooks to our Customers like a waiter or waitress just in a more efficient manner so you can do other processes.

Spencer: Once you have those, that is the main understanding of how to integrate with the Dwolla API. But then there are intricacies such as handling ACH returns, knowing more about how payments work and how to build that logic into your application and programmatically handle those scenarios is what I would say is the next step.

Cory: Really learn more about the ACH network, read as much as you can in our dev docs or resources to wrap your head around it. We try to stay on top of it if we see something recurring and try to add it to the docs. We have all the resources to keep everything self service.

Final thoughts…

Spencer: Obviously there are things that come up because it is their own brand that is in the forefront, so they are building the UX and experience for the users, and that trickles down to the Dwolla experience and our product offering.

Some products are using us and branching out from what Dwolla does at a base level. So that requires more thought and feedback to us so we can incorporate that into our product. So I would say, iteration on providing feedback so we can continue to improve the experience and their integration.

Cory:
As an API platform, our job is to seamlessly scale along with your business. If we, as Developer Relations/Integration Engineers, are doing our job right, you should feel comfortable reaching out to us if you have any pain points or feature requests. Facilitating a great experiencing post go-live is still paramount to our platform.

Spencer:
We see a lot of smaller businesses coming to us prior to even launching their application. So Dwolla can be heavily incorporated into that. Or they could be using a different provider or ACH from a bank.

I think that is what Dwolla does very well, we make it simple to get you up and out the door.

Talk With Our Integration Experts

Contact Sales