A successful payments integration can take a company, its service and functionality to the next level. It can be an invaluable addition to the services a business provides its end users.
Join our host Steph Atkin and developer advocates Spencer Hunter and Cory Anderson to learn about the Dwolla platform and get their expert advice to successfully integrating a payments platform.
Steph: Thank you very much for attending Five Steps for a Successful Payments Integration. I am Stephanie Atkin, your host today. Also joining me are Cory Anderson and Spencer Hunter. Cory and Spencer work on our developer relations team as developer advocates. Cory and Spencer, welcome!
Spencer: Thank you.
Cory: Thanks for having us.
Steph: Developer advocates. So, what exactly do you guys do?
Spencer: As a team we focus on connecting with and listening to the needs and wants of developers that interact with the Dwolla Platform. There’s various components involved with that. I think one component being maintaining developer documentation, making sure it’s up to date and contains the latest API information, doing developer outreach through blogs and various content pieces. The last, is focusing on our contracted customers and making sure that they have a seamless experience from first interaction to launching their application.
Cory: Right. I think you really nailed it with that nurturing part. Spencer and I and our developer relations team are there from pre-sale to post-go launch. What I mean by that is even before you reach out to our sales team we are interacting with a lot of our developers and our developer forum and creating guides for them to consume. Post go-live with Dwolla, we are also that support method that you can reach out to at any time
Steph: At Dwolla, we are your connection to the U.S. banking system. Talk to me a little bit about how our customers who need an integration to the ACH network can leverage our API.
Spencer: There is a wide variety of different use cases and ways that you can utilize the Dwolla API. I think one of the biggest advantages is how flexible the payments experience can be customized to fit your business’s needs. We do offer that white label payment experiences. It’s white label in the name and that Dwolla is behind the scenes powering the payments, and it’s your brand that’s in the forefront providing that experience to your end user. So quickly walking through some of the funds flows that we support: sending funds to users, receiving funds from users, facilitating transactions and then that me to me component: sending funds between users’ own bank account.
Cory: If we want to kind of dive deeper into what each funds flow looks like, a send application could be a payroll application where you are only sending funds to your customers. Whereas a receive would be the exact opposite. So maybe receiving dues from a local club from your customers. Facilitator models look something like where customers are sending funds to each other. So, for instance maybe a tenant to landlord application for rental properties. And as Spencer mentioned that me to me component where you are saving from your checking account to your savings account, maybe for a vacation.
Steph: It seems like there are infinite new applications that can be created by leveraging the Dwolla Platform. If we’re taking logical steps to integrate, what do we need to do?
Spencer: The first is really understanding the requirements. Figuring out your funds flow and how it all works with the Dwolla API and Dwolla services. Once you’ve done that you can jump into the sandbox. I think the sandbox is a great environment for testing end to end. Then going on to onboarding your customers, creating customers, adding funding sources, initiating transactions and then tying it all together with handling webhooks.
Steph: Step one, understand the requirements. Spencer, tell me there isn’t a thousand page manual.
Spencer: There isn’t. No, we try to make it as simple and as seamless as possible. But, knowing there are steps when you’re moving money that you have to account for both legal and compliance requirements. Cory and I are mainly on the technical side so that’s what we’re going to dive into here right.
Cory: Right,the technical requirements are fairly simple to understand and we’ll get to these in our next steps. But in terms of why they’re important this is simply due to the flexibility of the platform. So there are a lot of options to take into consideration including customer types, funding source verification methods and transfer features. Choosing the correct ones at the beginning can prevent a lot of unnecessary work as you’re integrating.
Steph: Redoing work can be expensive, where would I go to start learning about these technical requirements?
Spencer: The developer portal is a great place to start. We try to make that very self-service and now we have getting started guides which help you build out that proof of concept. We have additional resources which go into different topics and into more detail. If you want to see things at a high-level such as the various endpoints that are available, we have API reference docs. There are different interactions depending on where you want to start in your level of expertise of working with payment APIs.
Cory: As you read through the guides and resources, you might want to ask a few questions. Feel free to reach out on our developer forum. Here we can help identify the best fit for your business and walk you through the different features that are offered within the platform. As we outlined before, spending a little time working with our business development team and us on developer relations–can really help outline these requirements at the beginning.
Steph: So I know what I want to build in my funds flow, what else can I do to ensure a great integration experience?
Cory: Great question! I think one of the most important but sometimes overlooked procedures is keeping your developer teams and business teams in sync. Ensuring that your cross-functional teams are in full communication with each other will avoid any delay and misunderstanding when going into that integration step.
Steph: That’s great. Thank you very much for those insights. What’s next after defining the requirements?
Spencer: Once you define your requirements, the next step would be jumping into the sandbox and setting up a sandbox account.
Steph: Talk to me a little bit about the sandbox and why you recommend building there.
Spencer: The Dwolla sandbox is perfect for building out anything from that proof of concept application to an entire replica of your application, allowing you to do end-to-end testing with us prior to signing any contract. One of the things that we pride ourselves on is our high availability and uptime. You really experience that sending through transactions, onboarding users and experience what your interaction with the Dwolla service is prior to actually launching your application.
Cory: We find that many of our customers utilize the sandbox as a way to take their requirements that they identified in step one and create something really meaningful. We’ve gotten a lot of good feedback from developers working in the sandbox saying that they were really satisfied with being able to build out their entire application prior to going live. And this really helped beta testing as well.
Steph: What are the different activities you can do in the sandbox?
Spencer: We try to make our sandbox environment as in-depth and complete as possible. What I mean by that is allowing you to do things like creating customers and testing their identity verification states or simulating those transaction failure states. The first step would be creating those customer types, so building out your workflows to support onboarding those users. Then once you’ve onboarded those users, adding bank accounts and going through the verification process. The verification process is an important thing before sending funds from a bank account. So, everything from micro deposit verification to that instant verification process, either using our Dwpolla.js component or using a great service like Plaid, which is a third-party verification provider.
Cory: After you create your customer and add your funding source, you can then initiate transfers and simulate bank transfer processing. We actually have a whole article dedicated to testing edge cases in the Dwolla API as well. You might run into things like insufficient funds or customer identity statuses such as document or being suspended systematically. Being able to simulate these in the sandbox environment is really a powerful tool, it eliminates the need to do this with real data. Let’s take insufficient funds. Testing that out in the production environment would be kind of difficult because you’d have to basically drain your bank account. Being able to test this in the sandbox really allows for a lot of flexibility.
Steph: The sandbox environment seems like a great place for developers, is it free?
Spencer: It is. One of the things that we try to do is eliminate any barriers for entry to people testing out the Dwolla services. So we make our sign up experience very lightweight. It’s good for developers that may live outside the US that don’t have a US address and being able to test that interaction without needing that additional information.
Steph: When would you recommend someone starts in the sandbox?
Cory: Actually, I’d recommend as early as possible. One of the best things about the sandbox is that it is the constant in your journey with Dwolla. You can use this environment to give Dwolla a try, even before you reach out to the sales team. Then, once you sign the contract you will most likely integrate in that environment as well. And, after you go live you can still use the sandbox for things like feature add-ons or testing changes before you push up to the production environment.
Steph: So we’ve got down our requirements and we set up our sandbox account. Now we’re on to step three: on-boarding initial customers.
Spencer: If you nail down the first two steps, it’s really a breeze through the next three. The third step is onboarding customers. There are three main types of customers that you can onboard on the Dwolla Platform: receive only, unverified and verified customer records.
Steph: Can you break down those customer types for me?
Cory: So let’s start out with receive only and unverified customers. I think they’re the easiest ones to create because we only require you to supply the first name, last name and email address in order to create this customer. What makes them different is that the receive only customer, as their name implies, can only receive funds. Whereas, the unverified customer can receive funds as well as send up to five thousand dollars per week.
Spencer: The last customer type would be that verified customer record. The verified customer record really maintains the highest eligibility I’ll say on the Dwolla Platform. In that, you can have things like increased transaction limits, being able to hold a balance and then interact with all different customer types. It’s really key in that facilitator model in that you need at least one user in that model to be identity verified. That’s where the verified customer record comes into play.
Steph: There are a lot of nuances between the different customer record types. To learn more go ahead and click on the link on the screen and we’ll take you directly to our customer record type article in our developer docs.
Steph: We just completed step three, what’s next?
Spencer: Next would be diving into adding a bank account and initiating that transaction. Prior to initiating that transaction, you need to go through the bank account verification process. That’s different from the identity verification process that I outlined previously.
Cory: With bank verification, it is required for the sender. So the sender must have a verified bank, whereas the receiver can just add a bank but doesn’t necessarily need to verify it. But that’s something that you can determine as part of your use case.
Steph: So how can we do Bank Verification?
Spencer: There are three main methods that Dwolla supports. The first would be micro deposit verification. That’s the classic, traditional, initiate two micro transactions to your bank and then check your bank statement and go and then verify those two amounts. The second, would be instant account verification which is powered by Dwolla.js. That’s a Dwolla provided, easy drop-in component. The third is plaid, a partner verification.
Steph: Cory, why would you choose one of those bank verification methods over the other?
Cory: I think it’s really driven by your use case or funds flow. The requirements that you outlined in step one will also cascade down to these funding source verification methods. We actually have a developer resource article that breaks down the pros and cons of each method.
Steph: That’s very helpful. Understanding those requirements in step one really helps us enable step four.
Steph: We are now on to step five, listen and handle webhooks. Spencer, what exactly are webhooks?
Spencer: In easy to explain terms, a webhook is Dwolla’s way to notify you when an event occurs in the Dwolla system. That way you can do things like update your internal system or notify your users of an action, like a transaction completed. A webhook is another name for a callback. So, calling back to your application letting you know that an event occurred.
Steph: What is the biggest benefit for leveraging webhooks?
Spencer: I think the biggest benefit is the efficiency. Which is us letting you know when something occurs so you can then take action on that event. For example, updating an internal state so you can notify your customer that an action occurred or fire off an email and notifying your customer that maybe a transaction completed.
Steph: So it all really comes down to these five steps. Fully understand the requirements, set up your sandbox account, onboard customers, add funding source and initiate transfers and then finally handling webhooks.
Steph: What’s the fastest integration you have seen?
Spencer: The fastest integration that I’ve seen has been around for a few years now. It was a single developer that worked at a company that did payouts to users that were selling on a marketplace and they did it in as little as seven days.
Steph: Wow! What did they do right?
Spencer: I think they really did the entire end-to-end testing right. From step one with understanding the requirements to playing around in the sandbox prior to actually reaching out to us. That made the process to actually launching their application once they had that conversation with Dwolla very smooth.
Steph: Cory & Spencer, thank you so much for your time today and walking through the five steps for a successful payments integration. Listeners can get in touch with Spencer and Cory via our intercom bot, the Dwolla developer forum or by email at email@example.com.
Steph: Thank you so much for joining today. To learn more about integrating the Dwolla API, please visit developers.dwolla.com.
The above audio transcript of “5 Steps to a Successful Payments Integration – Transcript” was transcribed by the best audio transcription service called Sonix. If you have to convert audio to text in 2018, then you should try Sonix. Transcribing audio files is painful. Sonix makes it fast, easy, and affordable. I love using Sonix to transcribe my audio files.
Stay Updated with Dwolla