Dwolla API Demo Showcase | Convert audio-to-text with Sonix

Byron:
Good morning. Welcome to the Dwolla API demo and product roadmap showcase.

Byron:
My name’s Byron Smith and I’m director of sales development and enablement. Today we’re going to walk through our API demo, talk a lot about Dwolla and where we started and where we’re headed and show you that through the lens of our product roadmap. We will then open up for question and answer session.

Byron:
I would ask if you have questions within the Go To Meeting panel on your computer you will see a box for questions. Please drop that down, type your questions in and we will respond to those during that session. I’m going to send it over to Jake.

Jake:
Thank you Byron. My name’s Jake on the sales team here and Dwolla. My job is to consult with prospective customers and help make what is a complex and highly regulated world in payments easy to understand and tie it to a product that’s very straightforward and allows businesses to move money bank-to-bank very very seamlessly. So before we talk about who Dwolla is today I think it helps to talk about where we’ve been. What our journey was.

Jake:
So we were founded in Iowa in 2008. We’ve been in payments for the better part of a decade and we’re still based primarily out of Des Moines. In 2010, we launched a consumer application a mobile app that allowed individuals to connect their bank accounts and send funds between each other even making payments app merchants. So we were an early early adopter of that peer to peer payments space. In 2011, we launched our ACH API which is the first iteration of the product that we currently offer today. In 2015, we were asked to participate in the Federal Reserve Steering Committee and the Faster Payments Task Force. So really we had a seat at the table in determining the direction of payments for the future in the United States banking system and it really allowed us to have a seat at the table and be an early adopter for the innovations that have happened in ACH such as same day ACH payments.

Jake:
In 2016, we turned our focus to our business to business line moving away from that consumer application and focusing on making payments easy for different businesses and making making it streamlined for them to also allow their users access to the banking networks. And then in 2017, the Bill and Melinda Gates Foundation hired Dwolla to participate in the Mojaloop project in which we helped to build the global ledger. Mojaloop is an open source software that financial services companies, commercial providers and government regulators in developing countries can utilize to make payments easy for really an underserved part of the world when it comes to electronic payments. So really we helped build a payment solution for those who didn’t have the means to build it themselves.

Jake:
And in 2018 we saw massive growth. We doubled our team in size and experience tremendous customer and revenue growth as well. And that continues here in 2019.

Jake:
So Dwolla today. We currently have over 100 team members with an office in Des Moines, Iowa as well as a smaller office in San Francisco and some remote team members that are spread across the United States. We have millions of end users transacting billions of dollars every year across a multitude of different customer applications in many different industries. Investment platforms, marketplaces, saving apps, rental platforms. There’s a lot of other examples of the spaces that our payments API has been utilized to move money.

Jake:
We’re very dedicated to our customers’ success. We take a partnership approach to our relationship with our customers giving dedicated support throughout the process of integrating our payment software. And, once you’ve gone live we provide customer success advocates to really understand what are the things we need to do to make our payments process even better and help our customers grow. Part of that dedication to our customers is helping with security. We like to say that security is in our DNA. Payments is a very highly regulated and complex space so security and data protection are extremely important and we take that responsibility very seriously.

Jake:
We maintain compliance with the SOC 2 framework which provides third party assurance that we are taking the appropriate steps to protect our customers’ data. It’s something that we do also with our own internal processes of ensuring that our security is up to date. Really it spreads throughout the culture of the company. Every employee, not just the members of our dedicated Info Security team are up to speed on what we need to do to make sure we’re maintaining security for our customers and their data.

Jake:
We also have a very very reliable platform. 99.9 percent uptime. One of the most reliable ACH platforms out there so that you can be assured that your business and your customers are going to have access to the banking networks at all times. We’re also a company that’s continually innovating. And that’s reflected through a lot of the awards that we’ve won over the years with more than thirty five hundred nominations from around the world. We were recently recognized the best business to business payments products from the 2019 FinTech Breakthrough Awards program. That program’s devoted to honoring excellence in FinTech and companies and products. We’re also named a payment finalist for the NACHA Excellence in Payments awards that honors companies that have shown leadership in the electronic payment space.

Jake:
We also received recognition from the Technology Association of Iowa’s Prometheus awards as the FinTech company of the year and the overall technology company of the year. Again recognized in Iowa which in Iowa the technology industry is an $11 billion industry and employs over 88,000 workers.

Jake:
So that’s where Dwolla’s been. And we’re going to talk now about our product what it is today and then dive a little bit deeper into a demonstration of how the API works. So really at the core of what we do we connect our customers’ applications. So their front facing apps that connect to their users to that ACH Network through our API. So that these businesses don’t have to build a bridge to the ACH Network themselves. If you think about how complex the banking network can be and how manual these processes could become. That’s where you start to see the value and the automation that our API brings. So think about a business trying to pay out its contractors. They could cut checks which takes a lot of time to manually cut. You have to send it in the mail to get to the contractors and then they have to go to their own bank to put those checks into their savings accounts or to cash those checks out.

Jake:
You could even think about going straight to a bank for ACH having to upload manually ACH files and have those batch processed and crossing your fingers and hoping that those payments go through the way that you’re hoping. Dwolla’s API takes a lot of those concerns and a lot of those struggles out of the picture and does it for you. So we spent many years and millions of dollars building this solution out starting with that consumer facing app and we’ve turned it into something that businesses can utilize and essentially rent so that you have access to it and have the ability to keep your brand front and center while making this payment solution very streamlined and very straightforward.

Jake:
So we really are a launching pad for a lot of the most new and innovative technologies out there across many different industries. So given that the API in our platform is white labeled, keeping your brand of front center, and it’s extremely flexible meaning that you can do a lot of different things with it the best way to understand what it does is to view it through the lens of what our current customers are building on top of it.

Jake:
So looking at the API at a high level it’s a developer friendly access point to the US banking system. We connect 100% of U.S. banks with our API. It’s very well-designed and RESTful meaning that it won’t do anything unless your application asks it to do something. So that gives you that flexibility to really build out the process in the flow of the way you want it to look. We also offer a comprehensive sandbox and free to use API documentation. Very straightforward.

Jake:
We get a lot of compliments on how developer friendly our system is. Really it’s as simple as breaking the payments integration down into three simple things:

Jake:
So the first thing would be to create a customer account. We need to know who the individual is or the businesses that the payments are gonna be made to and from. We have three different types of customers. We have verified customer records, unverified customer records and receive only customers. So each of these three have different capabilities, different limits depending on what the flow of funds is going to be and the nature of your business. Any number of these three different type of customer types might apply to you.

Jake:
What we’re showing here is what is required to onboard a unverified customer record. So it’s as simple as collecting first name, last name, email address and acceptance of the terms of service and privacy policy of the business and Dwolla.

Jake:
So once we’ve created a customer account that we can point to when payments need to be made we need to attach bank accounts or funding sources to that user. There’s a multitude of different ways you can do this. Dwolla offers two. We offer the ability to do instant account verification which is what you see pictured here. The list of some of the major banks in the United States and a search bar to find other banks. The user would choose their bank or find their bank and then be prompted to provide their banking credentials in a very secure way and then in a matter of seconds we can determine that that bank account belongs to that user and they’re able to start transacting on the platform. We also offer the ability to do micro deposits the old fashioned way of providing a routing and account number receiving two small micro deposit payments into that account and then having that reverified back.

Jake:
We also support third parties bank verification services such as Plaid which are very similar to what you see here. And the last step then is to initiate bank transfers pointing to the different customer accounts and funding sources and moving the money between them. So again very simple elements here. The first two taking place during the time that the user signs up for the first time so steps one and two are really a part of customer onboarding and once that’s done they’re able to just do this third step of doing bank transfers.

Jake:
So when you think about Setting up customers and attaching their banks and allowing to send funds we need to think about where these funds are going. What the use case is. And we call that the funds flow and we support a number of different fund flows and we’ll walk through them here. So one would be the Send funds flow. So this is a business sending funds to the users of its application. So think about a company that needs to pay out contract employees. So the company is here on the left side sending funds from their funding source to the Dwolla network to the users and their funding sources. So those contractors are getting a direct deposit from the… into their bank from the application.

Jake:
The flip side of this would be a Receive funds flow. So this is a business that needs to receive funds from users so a company that offers services that require subscription payments. Users could attach their bank accounts so that those subscription payments are taken out of their bank accounts on a monthly basis or however often they need to receive those funds. So users sending funds from their bank accounts to the Dwolla network. To the application owner and their bank account.

Jake:
You can combine those two flows for a company that both needs to send payments and receive payments so users would have the ability to both receive payments as well as send them. Same with the business.

Jake:
Now this is where Dwolla offers something that a lot of other payment processors don’t in the ACH to get money from two different entities from one entity to the other. A lot of times it requires a middleman of sorts. A bank account in the middle that takes the first transaction from a user and then has to process a second transaction to get to the other user. If you’re familiar with money services businesses or money transmission law that’s something that most companies would like to avoid. So what we can do is take the middleman out of the equation and let users of a platform send funds directly between each other without the company needing to sit in the middle or have a third party sitting in the middle of the transaction.

Jake:
So we call that a Facilitate funds flow. So here its users and their different funding sources transferring funds through the Dwolla network directly to each other and companies can utilize what’s called a facilitator fee to still take a portion of the transaction without sitting in the middle. And we’ll touch on that in just a little bit.

Jake:
Lastly we have a Me-to-Me funds flow. So this is a little different than the other flows in that if a single user so one user and its multiple funding sources and passing the money between those funding sources. So a good example of this would be a savings application where we need to move money from a checking account to a savings account. So the single user who has attached their checking account as a funding source and their savings account as a funding source and we’re moving money through the Dwolla network to get the money from the checking to the savings account.

Jake:
So now we’ll take a deeper dive into a couple of these funds flows and what they look like from an API perspective. So we’ll start with sending payments. So this is a business’s application where they need to send payments to their users. And we’re going to tie that to the Rally Rd. use case.

Jake:
Rally Rd. as a customer of ours and has a mobile platform that turns collector automobiles into stocks that allows individuals to invest in these into these vehicles and then receive disbursements on the interest they’ve made on those investments. We power payments on their platform and allow them to really focus on what they do best in the investment space while we do the heavy lifting on the money movement. So what we’re going to specifically look at is how we help them pay out their investors. So if we’re looking at the entire picture here we’ve got the user interface. So this is what the users of the Rally Rd. app would see.

Jake:
We have the client application. So this is what’s feeding that information into the user interface. So in this case it’s Rally Rd.’s application.

Jake:
And then we have the Dwolla API which is broken down into the Ops server, resources server and webhook center. So the client application is going to talk to the Dwolla API in order to display things and make things happen for the user through that user interface. If you were to extend this page back even further you’d see on the right side of Dwolla the would be the banking network. So we handle that entire connection to the ACH Network. Keep that burden on our plates. So that’s Rally Rd. can focus on the user experience and making that easy for them.

Jake:
So step one in the process is to gain access to our API through the Ops server. So this is another layer of security that we provide. And now we need to know that the businesses that are trying to gain access to our API and make requests are businesses that we have worked with and that we have compliance with. We want to make sure that the people asking for resources from the Dwolla API are real people. So we provide a key and secret to our customers and they take that key in secret and ask the Ops server to create a token. This is an access token that again allows them to make calls to the API. So then we return this access token and this access token expires each hour. So the reason for this is that if that token were to be intercepted It’s only good for an hour. It’s another layer of security and encryption that we provide.

Jake:
So what our clients will typically do like in Rally Rd.’s case, they will continue to refresh this token. They’ll have an automated process of asking for this token at least once an hour so that they can maintain access to the API. So what they would see what Rally Rd. would see on their end is that they have maintained access to the API. Things are alive and things are running. So now they can start making requests. So this is where Dwolla’s API is RESTful. It’s asking for something to be returned to the client application.

Jake:
And this is where really those three elements come in. The resource server is available to ask to create customers, attach funding sources and to make those transfers. So here we’re seeing the example of Rally Rd. wanting to make a transfer to a user as a disbursement. So what they’re doing is they are designating a source ID. So we’re looking at the funding source that Rally Rd. has attached that they make their payments out of. So they call that as a source. And then they call out a destination.

Jake:
So this would be the funding source of the user that’s to receive that payment. Then we’re also looking at the amounts. So here it’s $1,250 that are being paid out to that end user. Now this is a transfer request. So as a part of this transfer request you can do other things like put metadata on the transfer which is like adding a note. So here you’re seeing that it’s a payment that’s completed for work on April 22nd.

Jake:
Now we’re passing back a unique transfer ID. This is another value add that we offer. As I mentioned before ACH is batch processed. So on the back and we’re uploading a batch file to our bank to make the transfers happen. But we break down this batch file for you into a unique transfer so you can get the status of a single transfer at any time. I call in the API with this transfer ID. Again it’s breaking down what is a batch process and without you having to manually go through and find the transfers in question you’re able to call out a single transfer this way.

Jake:
Again it’s the transfer ID. So if you need the information about the transfer that’s actually being stored on the resources server. The same with that customer ID and that funding source ID. So those other two of the three steps you don’t need to actually hold on to the information that the customers provide especially that routing account number on your own servers. We’ll do that for you and allow you to just hold on to these unique IDs that points to those things. Another layer of security and encryption so you can be you can rest easy knowing that that information doesn’t have to be stored on your own platform.

Jake:
So what Rally Rd. would see once they’ve created that transferred disbursement and gotten that transfer ID back. They could display that that transfer has been confirmed. Now the Webhook sender this is something that we offer it again a little bit different than other services we actually can push notifications to our clients to let them know when important things have happened on the platform.

Jake:
So every client of ours has their own webhook sender so they get real time push notifications on what happens. So in this scenario we fired a customer transfer created Webhook. So we let Rally Rd. know that that customer transfer has been created in our system and then we can also notify them that it is pending.

Jake:
And along with this, Rally Rd. you can see that the transfer is initiated and then process that webhook to alert the end user of the payments confirmation. So here step six the end user actually gets to see through that process webhook whether it’s through the app, through an email that they’ve received a payment from Rally Rd. for that disbursement. So it’s another way to automate the process of notifying end users of things that happened on the platform.

Jake:
In this case they received a disbursement from Rally Rd.

Jake:
So that’s the full picture. Steps 1 through 6. So it’s maintaining access to the ops server by getting that access token and then creating requests from that resource server to create customers to add funding sources to them and to make transfers. And then the webhook center is pushing these notifications to Rally Rd.’s application that they’re then processing and showing to their end users.

Jake:
So that’s the sending flow that’s disbursements out to end users. We’ll take a quick look at a Me to Me funds slow to get an idea of what that would look like and it is in this example. We’ll talk about Astra, Astra finance the savings application that allows users to save money smarter. So really what we’re doing is removing money again for a single user between multiple funding sources that that user has. So in this case moving funds from a user’s checking account into their savings account. Again we’ve built this API out so that Astra doesn’t have to connect to the banking network themself. We can automate it for them and it makes it a very very important functionality that we provide for them.

Jake:
So again we were looking at the use case as a whole we’ve got the user interface Astra’s application and Dwolla’s API. We’re getting access to the API again with that expiring token.

Jake:
And now we’re creating a transfer to move money from the user into their Dwolla balance. So verified users on the Dwolla platform are able to hold a balance in our network. Think of that as like an e-wallet. So in this scenario the user’s gonna move funds from checking into that balance.

Jake:
So it’s the same scenario as before with just a little bit different endpoint. The source is the user’s checking account and the destination is the user’s Dwolla balance. And then we’re designating the amount below. In this case it’s just $10.

Jake:
Then Dwolla returns again that unique transfer ID so that we can point to this $10 transfer when we want to look at the status of it and see where that money moves.

Jake:
So again Astra is able to see that that transfer is confirmed. And then we’re going to fire off that webhook to let them know that that transfer is created. In their system they’ll be able to see it. And then they can process that webhook to show that end user that they’ve moved money from their checking to the Dwolla balance or to their savings account.

Jake:
So again the same six steps with just a little bit of a different use case. But again this is where the flexibility of our platform comes in and that really we can support many different fund flows as you’re just naming a source and a destination for these transfers to occur on users and their bank accounts.

Jake:
So then we’ll walk through that facilitator funds flow again. This is where we’re moving money between two different users of a platform. So we will use Earnnest as an example and Earnnest simply makes it easy for users to put money into an earnest money deposit account when they’re buying a home. And Daniel the CTO of Earnnest put it very simply and that we’ve helped them remove the opportunity for human error. Again our API really takes a lot of the manual processes that could happen that would need to happen in a more paper process or more manual bank process and we automate the whole thing. So it keeps that human error aspect out of the equation.

Jake:
So again Earnnest’s user application Earnnest client application and Dwolla’s API getting the access.

Jake:
And now we’re looking at creating a transfer between two different customers’ bank accounts. So in this scenario the customers are a home buyer and then an escrow account. So we set up the escrow account as another user in our system. Earnnest is the application, the users are homebuyer and escrow account. So here we’re creating a transfer for a user to put money into the escrow account. The source would be that homebuyer’s funding source and the destination would be the escrow account funding source. In this case it’s gonna be a $1,250 making that money move. And then we require that we return that unique transfer ID to Earnnest.

Jake:
I mentioned before the ability for a facilitator model that the platform can actually take a fee off of transfers that happen within a facilitator model. So in this case Earnnest takes a portion of the transaction between the home buyer and the escrow account. And this is an example of that facilitator fee detail. In this case Earnnest is taking two dollars from that one thousand two hundred and fifty dollar transfer. So from Earnnest’s point of view they can see that that transfer has been confirmed. Money has moved to the escrow account. We’re then going to push that webhooks that tells them that bank transfer has been created. So Earnnest can see that that money has been transferred and then they can display it to their different end users.

Jake:
So here again you have two different end users. You have the home buyer and the escrow account. So both get a notification. So the buyer sees that they’ve transferred the funds to the escrow account. The escrow account sees that the transfer has been received.

Jake:
Again steps 1 – 6.

Jake:
So that really is our API in a nutshell. It can get more complex as the fund flows get more complex. And with that we provide dedicated support. So as you integrate our API build against it. There are a lot of different steps that you take and we will provide dedicated support through an Integration Manager and a Developer Advocate throughout that process of going live.

Jake:
Once you’ve gone live and start making payments you’ll have a Success Manager that also is there to assist and have different business reviews with you to talk about how we can continue to improve our API and improve their user application.

Jake:
Another step that we take is to review your information security and do a review of a couple of things on the risk and compliance side. Another value add that we offer. Again it’s a highly regulated and complex space. A lot of customer information passing through it. We want to make sure that everything’s secure. We want to make sure that everything is compliant and our teams help you with that during the integration process.

Jake:
So we talked about the API and that it’s white label. So a lot of what the clients and the customers of Dwolla would see is whatever they build out but Dwolla also provides a dashboard to all of our customers a pre-built application that Dwolla provides so that our customers can get insights on what’s going on on their platform.

Jake:
So with the Dwolla dashboard You can see different trends that are happening. You’re able to see the different transfers that were sent. What’s been received, customers that are created, and customer transfers really over any given period of time so that you can get a good idea of how your business is trending.

Jake:
We also allow you to look down again to the singular transaction level so you can look at different transfers that have been created via the API. Looking at the status whether it’s pending, whether it’s in process and you can also search the amounts you can filter based on the amounts or the statuses of the transfers. You can see who the users were and what the date those transfers were made on. Very very important for reporting purposes. You’re also able from here to cancel transactions should you need to do that as well.

Jake:
So we’ve talked about where Dwolla has been and what the product looks like today. Another part of it is where we’re headed. So something we say a lot here as well is that we are never done. And I think that’s reflected through what we do from a human aspect and connecting with our customers, talking with them, hearing their feedback on what we could be doing better. Other things that they would like added in the future. We take all of that feedback and we wrap it into the future of the company and where we’re headed and what we’re innovating on from a product perspective.

Jake:
So we’ll take a look here at our products roadmap. So this is our product roadmap for quarter 2 and quarter 3. There’s as you see multiple different things that we’re working on at any given time. All based on making the client experience more streamlined, building out our ecosystem to provide more functionality and features, and looking at the current platform as a whole how do we make that more advanced. How do we make it better performing and more scalable? So let’s touch on a couple of these things here. Data analytics: we’re really looking at different ways that we can repurpose our customers’ data to show them trends and statistics about their business past what we’re providing with the dashboard. We’re also working on statements: so the ability to see and download financial statements from the dashboard or to get any financial data in real time from the API. We’re working on scalability enhancements. So just making our platform more scalable more available and better performing to help support the multiple customers and multiple different use cases that we have. An example of this is that webhook sender. So again every customer of ours gets their own webhook sender. So these notifications go into a queue but it’s the user’s queue. There are no other customers using the same webhook sender that that singular customer has. That’s something that we just launched.

Jake:
From an ecosystem perspective, We do focus on ACH but we understand that there are other payment rails out there that are important to the success of the companies that we work with. So we are working on card services looking for ways that we could potentially in the future accept debit and credit cards as payments, do push the debit cards, or even offer branded cards and other options in order to help companies utilize the other payment rails. We’re also working on an integration directory which would be a landing pad for our third party integrated partnerships. A good example of this would be Plaid Bank Verification Service that we have a partnership with that focused solely on the verification of bank accounts whereas we focus on the ACH aspect. So really the purpose of this directory is to help our customers tie in different integrations to make their payments platform full and robust.

Jake:
Really to close on the platform, a quote here from Alexi the CEO of Nomad, a company where requests that pays out doctors. And Alexi said that Dwolla has one of the best ACH optimized APIs in the market. Again very complex system. A lot of regulatory things a lot of technical things even that make connecting to that U.S. banking system difficult. What we’re doing is wrapping up all those complexities into a straightforward powerful API that really again is white labeled to your own interface. So we keep your brand front and center and as he mentions here we also get access to those newly released functionalities by being thought leaders in the ACH space. So an example of same day ACH. Again we had access to that before many did.

Jake:
And with that we will open it up for any questions.

Byron:
So yes if you have any questions please submit them through the questions within Go To Meeting. Jake, we did receive one question since there’s the limit of ACH if the user transfers through wire. How does that work?

Jake:
So right now wire functionalities would be separate from our API. It is something that we’re looking into is something that we can offer in the future but right now there’s very limited wire functionality through our own system. Now you spoke of a limit on ACH. We actually have some flexibility on what those limits are. It depends on the use case. It does require some compliance review and some review again of the use case as a whole. But any limit on ACH on a verified customer is pretty flexible. Again based on the use case. So we have seen a lot of platforms that we’ve on boarded that have very high limits transacting in the millions even in one given ACH transaction. So it is something that we offer there.

Byron:
Another question that we received Jake is if I want to know more how do I get in contact with you for next steps?

Jake:
Absolutely. So I will provide my information so that you can reach out to me directly. We’ll also be reaching out through our sales development team so that you can ask any questions there. We’re on Intercom so if you go to our website you’ll be able to chat us there. There’s also a lot of information throughout the many pages on our website and we can definitely advise where to go for that depending on what your questions are, if they are more development focused. And if they’re more API focused.

Jake:
You can also e-mail us at sales@dwolla.com for any general questions as well.

Byron:
Another question that has come in is a follow up to the first question around the wires by looking at transactions in the bank account. Would it be able to tell the details about the wire?

Jake:
So Dwolla currently doesn’t have the ability to look into a bank account per say to see what happened on it. Now we partner with Plaid, which is a Bank Verification Service that has that ability to look at the balance of a bank account and look at the transactions so we could definitely work hand in hand with Plaid to optimize that and see what has happened from a perspective of transfers coming in and out of that bank account. I would have to follow up on whether or not you can tell the difference between an ACH bank transfer and a wire transfer that way. But we can definitely follow up there.

Byron:
Another question that we just received in this is regarding the Earnnest process would the escrow account need to initiate a request for the money from the home buyer otherwise does the home buyer…how does the homebuyer know where to pay within the platform?

Jake:
It’s a good question. So it does depend on the different use cases. I can’t speak necessarily to Earnnest on exactly how they have it set up but let’s assume that the escrow account would want to initiate that request. Earnnest through the API has the ability again to build out these workflows the way they want it to look but they can have the ability for the homebuyer to opt into having their account debited for any of these transfers. So basically what would happen is that Earnnest would create a debit against that homebuyer’s funding source which then moves the funds from the homebuyer to the escrow account. They could also build out a flow where there’s a simple button that can be pressed where the homebuyer initiates that payment on their own. But again a lot of different things you can do when it comes to authorizing those payments.

Byron:
We received one more. Traditionally a merchant e-commerce store would go to an ACH provider to process ACH on their storefront. They have to go through underwriting to get an account and connect through their API to the rails. If I want to be a facilitator or be backed for a facilitator, who underwrites the merchant? does the risk department? How would that work?

Jake:
So just to clarify the question it sounds like we’re looking at a platform where many different merchants on an e-commerce site. Companies are providing ACH to their end users. so the underwriting of the merchants would fall primarily on the platform to do.

Jake:
Dwolla has some underwriting that we do as another step in our process but we encourage the companies that we work with to have their own underwriting processes for their own users should they require it.

Jake:
So a verified customer record, for example, which in this type of case the merchants would most likely be a verified customer record would require underwriting by the companies themselves Dwolla would also put them through our own KYC process just to ensure that we have taken that step for the benefit of our bank. So we make sure that this user or this merchant is who they say they are but the company themselves we need to do the full underwriting on that company.

Jake:
And I see one other question about ACH limits. So how do we learn more about those ACH limits and how do we increase it?

Jake:
So what I can do is point you to our developer documentation and customer types. So again we have those three steps of creating a customer, adding a funding source and then making those transfers. So there are three different customer types all with different abilities. So a verified customer record is going to have different limits than the other two. Now verified customer record is where we can look at increasing the limits pending a review from the compliance team. So the standard limit for a verified customer record is $10,000 per transaction and that’s for money sent. An unverified customer record is capped at $5,000 sent per week. And then receive only customer can only receive funds. But we can definitely look into discussing how to raise those limits on a use case by case basis. So we definitely would like to follow up with you on that.

Byron:
So it looks like we got a few more questions and any plans to available transactions from the API. Without the Plaid integration.

Jake:
So I believe that question is asking about checking the balance the actual bank account balance of the user through our own API without the Plaid integration. It may be something that we look at in the future. We have a very good partner in Plaid that does it might be something in the future. I don’t believe it’s currently on our roadmap though but again with the Plaid integration it’s a simple pass of a user’s token in order for our APIs to really talk to each other. So again a very seamless integration between the two APIs.

Byron:
That concludes our questions.

Jake:
Perfect.

Jake:
Well if there are any other questions remaining that we didn’t address here again you can contact us ad sales@dwolla.com. Definitely reference the website. We have a lot of good information there. We also have the Intercom chat functionality on the website. So feel free to post any questions you have there as well. We’ll be reaching out to everyone on the call today as well for feedback and any other questions again that weren’t answered here.

Byron:
Thanks everybody for attending.

Convert audio to text with Sonix. Sonix is the best online audio transcription software

Sonix accurately transcribed the audio file, “Dwolla API Demo Showcase” , using cutting-edge AI. Get a near-perfect transcript in minutes, not hours or days when you use Sonix. Sonix is the industry-leading audio-to-text converter. Signing up for a free trial is easy.

Convert mp4 to text with Sonix

For audio files (such as “Dwolla API Demo Showcase”), thousands of researchers and podcasters use Sonix to automatically transcribe mp4 their audio files. Easily convert your mp4 file to text or docx to make your media content more accessible to listeners.

Best audio transcription software: Sonix

Researching what is “the best audio transcription software” can be a little overwhelming. There are a lot of different solutions. If you are looking for a great way to convert mp4 to text , we think that you should try Sonix. They use the latest AI technology to transcribe your audio and are one my favorite pieces of online software.

Dwolla
The Payment Platform For Technologists

Be Smarter About Payments

Get Started