The following content was transcribed from a webinar we conducted titled “Getting Started with Dwolla White Label.” In the webinar, we provide an introduction to getting started with your white labeled bank transfer integration, and what to expect during implementation.
Brian, Sales Representative:
What I’m going to be focusing on today are the biggest differences between Dwolla’s co-branded solution and API and the new White Label offering. And also, we’re going to be touching on why it will make a significant impact on both your business and your customer’s experience when interacting with your business. As I’m sure many of you know, Dwolla’s co-branded API offers a lot of great functionality, with things like OAuth and Dwolla Direct. There were however some recurring themes of feedback that we were getting from our partners, things like: it’s less than ideal having my customer’s leave my site and go create a Dwolla account, introduce a second brand come back to my website, auth into their Dwolla account. They said it would be great if they could have it not say “Dwolla” in the bank line. Also one of the major ones we heard is it would be really nice if I could give my customers Dwolla Next Day rather than just my account. So with the introduction of Dwolla White Label we’ve actually answered and addressed every single one of those concerns and a lot more things.
So let’s go ahead and dig in.
To start on the basics, we have to answer what is White Label? In it’s most simple form White Label is essentially the ability for you to create a Dwolla account on behalf of your users while simultaneously removing most of Dwolla’s branding from the equation altogether and replacing it with your own branding, so really Dwolla is taking a step into the background here which is different than anything we’ve done before. Your users will never be asked to leave your website or your mobile app, they won’t be getting emails from Dwolla, they won’t be contacting Dwolla’s customer service. It really makes it feel as if this is a solution that you’ve built yourself in-house with your engineering team, which I think has a lot of value.
Many of our partners chose co-branded because they wanted to offer an ACH payment solution but they didn’t want to have to deal with storing the routing and account numbers on their own servers. That can be very sensitive information as many of you know. I think it’s important to understand as Spencer, Bobby and myself talk about White Label today to know that even though with White Label your customers are entering in that bank information on your website, you’re still not responsible for storing that information. You’re securely passing it to us through the API, we’re encrypting it and you’re dealing only with API tokens.
So moving forward I’d like to go over the three basic ways that partners can implement White Label. The first is receiving payments from your customers. This is pretty self-explanatory here. You’re customer owes you money and you’d like to be paid via ACH. With White Label you can build your customers a portal that allows them to auth into their online banking and submit a payment without them ever leaving your site. We’ve recently released a new function that is only available in White Label called On-Demand Transfers. Let’s say that you customer wants to give you permission to send money from their bank account for a variable amount in the future. With On-Demand Transfers, we give you an API endpoint that allows your customers to grant this permission. This can be extremely useful in subscription services, accounts receivable situations, B2B transactions, there’s a lot of different areas where this can be effective.
The next basic use case in using White Label is payouts. This is an area where we’ve seen the quickest adoption of White Label actually. Let’s say you have a large number of contractors or 1099 employees that you need to make payments to you on a daily, weekly, or monthly basis, or you have an ecommerce platform where creators sell their art and you need to pay them for the items that they sold on your website. There’s a lot of different ways you can look at this. With White Label it’s as easy as presenting these payees with a page to give just their first and last name, email address, routing and account number. That’s it. You pass us that information and we create what’s called a White Label Receive-Only entity. That’s exclusively for payouts. And you’re able to send payments to that individual any time in the future and they’ll have the funds in their bank account in as little as one business day, and it will not say “Dwolla” in their bank line it will say the name of your application.
The final use case and the most sophisticated one is what we call a platform integration. The platform approach is used when you’re building an application or software that connects two parties but you don’t want to touch the money yourself for a variety of different reasons. Think about for example, software where tenants and landlords need to be connected so that a tenant can pay their rent. Maybe you want to build a peer-to-peer payment app where you can connect two parties for thousands of different reasons, we’re seeing a lot of that lately. Through our API you can create customer records for both ends of that transaction and have full visibility into every transaction that is happening over your application.
One feature that we built specifically for platform integrations is facilitator fee. As I’m sure many of you know, Dwolla doesn’t take a per transaction fee, we don’t take a percentage fee like credit cards do, with facilitator fee we allow you to build in your own percentage fee from each transaction that can become a new revenue stream for your organization. That’s something that’s very appealing for companies that want to add this as an additional way for your company to make money.
Speaking of money, one question that I’m sure we’ll get to at the end, but we can address now, is: What would it cost me to either switch from co-branded to White Label, or maybe you’re brand new to Dwolla and would like to jump right into White Label. The answer is that we have a very unique SaaS-based pricing, where you work with our business development team and we work out a flat monthly fee together. That’s really ideal for businesses cause there’s no surprises. Again we don’t charge per transaction and you know exactly what you’re going to be paying month to month, no matter how much your company is really growing. You can find out more information about that by going to dwolla.com/pricing.
So that covers the 30,000 foot view of the business side of things, but really we’d like to take this time to dig in if there’s any developers on the webinar that would like a little bit of insight into the API itself. I’d like to introduce Spencer Hunter who will be getting into that.
Spencer, Developer Relations:
I’m going to be diving into some of the technical aspects of upgrading to White Label. A big piece of that is our V2 API. One of the things we had the opportunity to do is take a step back and really rethink our existing API and create a new one from scratch. So we really took a pragmatic approach to this new API, introducing elements to it that offer an API user friendly experience.
One of those elements is the discoverability aspect. What I mean by that is using hyperlinks to navigate between resources versus hard-coded URLs like in API V1. So if you see our example, we show a list of links that are available for this specific Dwolla account. What your application will do is, it will be able to figure out everything it needs with little or no outside information. So, what that allows you to do is use these links to discover actions that are available in the current OAuth context. So for example, here if we want to add a funding source we will follow that link, if we want to transfer money, we’ll follow the transfers linked relation.
The second kind of benefit or enhancement to this V2 API is following proper HTTP status codes and having consumable errors. One of the thing in the V1 API that we provided back was this kind of vague response from the API. For example you’ll call our API, we’ll give you back a success is false, but not necessarily the proper status code in this instance, we’d give you back a 200 saying that everything was okay, whereas we maybe should have responded with ah 500 telling you that it could have been an issue on our end, not on your end.
So, shifting to the V2 API we have a validation error in this instance we provide back a 400 error to your application that says that there’s an issue on your end that you need to correct before you can resubmit the API request. You can see there that the first name parameter that’s required that tells you specifically what went wrong with the request and how to fix it. You can really see through HTTP status codes and the consumable errors that we’re trying to navigate toward this simplicity in using our API. In with the simplicity, you’ll still be interacting with OAuth, and Brian mentioned this co-branded experience. So this co-branded experience is OAuth, so you redirect your users to Dwolla to authorize your app for a set of permissions, and you get back an access token. You’ll likely store this access token in your database. This is required for all of your users. Now, when you get a growing list of users, this opens your application up to running into potential errors. What I mean by that is you going out to your database to fetch these access tokens or calling out to our API and maybe getting back an invalid access token error. So, having that one access token for White Label to manage your customers really minimizes your exposure to potential errors.
The next piece here is our improved webhooks system. Our new webhooks system relies on events, and what happens is your application subscribes at a webhook endpoint that Dwolla can deliver information to. This is information such as transactional information, account related information, etc. For example, one of your customers has added a bank account and we send you a notification telling you “customer funding source added,” include information such as who that customer was, and the resource that had changed. You can then go out and fetch more information from the API to figure out more information on that bank account that was added. In addition, we retry for events or webhooks that don’t make it to your servers. So say your server goes down for any reason, what we’ll attempt to do is retry these webhooks to your application. If you don’t receive it, we’ll keep retrying over a period of 72 hours, exponentially backing off. That way you get this important transactional and account information for your customers.
On the last piece here, I want to touch on the ease of integration and customization through Dwolla.js. Brian briefly hinted on this but, Dwolla.js is essentially a client-side library that allows you as an application to talk to our API through the browser. You don’t have to pass through sensitive information such as bank data through your server. You get a one-time token for your customer that you want to add a funding source for, you call a function in Dwolla.js and what that does is it acts like a middle man between our API and your application, passing in that sensitive information. The other piece to Dwolla.js that’s really nice is the customization aspect. Whether you’re using our instant bank account verification or just passing us the account number and routing number, that is fully customizable. We provide CSS classes for that instant account verification to make it look like the look and feel of your application, which is really nice.
I’m going to transition over to Bobby and he’s going to talk about what you’re going to need to migrate and what’s involved.
Bobby, Account Manager:
Thanks, Spencer. You know, Brian really talked from a high-level, and he talked about why White Label is so important and the different types of integrations and use cases you can use it for, and all the features that are really baked into it. Spencer really talked in terms of the technical aspects and a lot of the improvements and enhancements we’ve made within that API V2.
Now I really want to talk about, alright that’s all well and good and you’re really ready to get started moving forward. Initially we’re going to have a consultation with you. What that means is that we’ll schedule a call with one of our business development members to discuss your existing integration, and then also understand what your vision is for processing payments on your application or platform. Then, we want to make sure that you have the ability to familiarize yourself and your team with the sandbox and the API. Reason for it is really this new API is more involved from a technical process. What that means is that there are new endpoints and different client libraries that are available. Also, there are a lot more API calls that are involved and you’ll have to account for both customer accounts and bank related activity. Those are both two important things to keep in mind.
Spencer, do you want to talk a little about the process for migrating customers to the API V2?
Spencer, Developer Relations:
Yeah, so the migration process, Bobby mentioned briefly about the testing everything in the sandbox. This is available to test in the sandbox as well. So, as I briefly mentioned, you’ll be using user account access tokens to interact with the API on the users behalf. That’s whether you’re on V1 or V2 using the co-branded experience. What you’ll do with that existing token is, you’ll call an endpoint on our API V2 which is /customers, passing in that access token, the valid access token of that user account. On the success of that API call, we’ll provide you back with a link to that customer ID or customer object that was created in the API. In that process, any information account related or bank account related is migrated over to that customer account and is populated within your customer listing. So it’s really a seamless process, one API and one request parameter that you pass in. It’s as simple as that.
Bobby, Account Manager:
Great, thanks Spencer. And then, really lastly when you’re wanting to really understand what it takes to get going is making sure you understand what the integration requirements are. And these aren’t necessarily Dwolla’s requirements, but since we’re moving money and funds over the ACH network there are certain regulations and compliance requirements that we have to abide by. Basically it’s important to understand those security and compliance regulations that you must meet as a White Label partner. One example of this is email notifications. So anytime funds are being moved or let’s say a customer is adding or removing bank accounts, we need to make sure that you are sending corresponding communication to your customers regarding those types of events. Basically we need to make sure that you understand all these regulations and things that must be reviewed before we move forward. Once we’re in a good spot with that and we really understand what it takes to get up and running with White Label and you’re ready to move forward, we get you into a contract and once you’ve signed a contract and want to move forward with that, we’ll run through basically what the process is to get up and running on White Label.
The first step of that is really an introduction to a dedicated account manager and technical integration lead that you’d have here within Dwolla. What they’ll do is help answer the preliminary questions that you have as you’ve gone through our partner integration guide, understand your target launch date in terms of when you’d like to go live with White Label, and discuss the timing of that integration process to make sure you hit that target launch date.
We’re also going to spend a lot of time helping you understand the relevant API documentation. Besides your dedicated account manager and the technical integration lead we also offer chat support. We offer that HipChat support to be able to have a dedicated technical team to help assist you with your questions throughout that process just on a one-off basis if you need help with certain endpoints or questions that you have.
The next step is completing Dwolla’s internal review process. What that entails is basically we set up a demonstration that the partner would lead to show the functionality on their end from user account creation to connecting a bank account to initiating transfers, just to make sure everything is following those regulations we’d kind of discussed about previously. And then once we get approval from the Dwolla team, you’re good to go live. And from there, we want to make sure that not only are you ready to go live but that we’re also there along with you to support you as you’re up and running on White Label. So you’ll still have that account manager, that dedicated integration lead as well, to help to make sure that everything is running smoothly going forward. Those are just some of the benefits of becoming a White Label partner, is that higher level of priority support that you get through that process and going forward.
With that said, we’ll wrap things up on the presentation side. I’m going to introduce Mariah, she’s been reviewing some of the questions that have been submitted and we’ll try to address some of those now.
How long does a typical integration take?
It definitely depends on the integration you’re doing. There are some that are a little more simpler than others. It also depends on how much due diligence you’ve done up front in the sandbox environment building your application out. We’ve had partners that have been up and running in as little as 10 days, and some may take longer, from 1-2 months. It depends on their time frame. We are here working with you to make sure you hit whatever you’re target deadline is. We’ll lay out a timeframe to make sure that we hit each step along the integration process to make sure you hit your target launch date.
Could you clarify what level of technical support a partner might get, and at what level of contract would they need to get technical support?
We have various packages you’ll be able to find at dwolla.com/pricing. So as far as what kind of technical support you get at various levels, the technical support actually begins at the Premium package which is a co-branded only solution. And with that you get email access to guys like Spencer on the developer relations team, being able to get quick answers to questions that you need. As a White Label partner which is really our Enterprise level solution, you’re getting those things like direct contact information for the developer relations team. As Bobby mentioned, you get access to that HipChat channel or Slack channel if you prefer to invite us to your Slack channel if that’s what your company chooses to use so that you can get real-time answers to the questions that you need. Additionally, if you ever want to jump on a call with a member of our team we’re always happy to do that. It’s really a white glove experience all around.
Can you clarify the options for speeding up payments from 3-4 days to maybe a different time frame?
Absolutely. We’ve had this feature for awhile called Dwolla Next Day. Inherently a standard ACH timeframe when you take into consideration how long it takes for an ACH reject code to come through, it can be 3-4 business days. But with the introduction of White Label we can turn on Next Day for your entire application, which means that we’re cutting down the time it takes for money to go from a bank account, into the Dwolla network, or from the Dwolla network out to a bank account, down to 1-2 business days. An important time to understand when using Dwolla is that 4:00pm Central Time is what we call our cut-off time. Let’s say you want to get payouts out to a large group of individuals and you want to make sure that they get their money the following day, you just want to make sure that you make the payout from your Dwolla balance before 4:00pm Central Time, everybody is going to have their money the following business day morning. Same principal applies for receiving money, and then the platform we can talk about it in our consultation but really what it is 1-2 business days into the network and 1-2 business days out of the network.
If my user has a Dwolla account, does that affect my White Label integration?
When we designed the White Label product, we decided to make it two completely different silos. For example, I have a Dwolla account under BrianCrall@gmail.com. If I were to go and use a White Label partner’s application and sign up for that application with BrianCrall@gmail.com, those are two completely different accounts that exist separate of one another. So, it’s not possible for me to go to Dwolla.com, sign in with that email address and see the transactions on that White Label application, they exist entirely independently and that’s gotten some extremely positive feedback from our partners the way that we’ve handled that.
Could you talk about the options for requesting payments from customers?
I like to think of Dwolla’s White Label solution as payments Legos. And what I mean by that is that we offer you the bricks in order to customize and build whatever you want. So if you’d like to build this into a solution where you’re requesting a payment by sending an invoice to somebody, you can absolutely do that by integrating into our API. If you’d rather make it more of a checkout kind of flow, you can absolutely do that as well. If you want to set it up as a subscription payment service…it’s really how you want to build it in. There’s really not a set way. Trying to breakdown the question a little bit, I think it’s important to understand maybe if the question is coming from someone who is not using Dwolla today is that Dwolla is an ACH API. You can certainly use other payment networks alongside Dwolla, but Dwolla is going to be a solution for paying directly from a bank account.
What kind of information do I need to collect from my customers?
We’ve got different types of customer accounts. For instance, if you’re wanting to create what we call a CIP verified customer account, the information we need to collect is first and last name, date of birth, last four of social security number, an address and a phone number. Those are going to be the primary things that we use to make sure that we can verify that customer is who they say they are. Otherwise they can create what we call is a customer record, and for that we are just looking for first and last name, as well as banking information.
Is there anywhere currently where attendees can go and look at some of the White Label integrations or code, or where can they get started with the dev docs?
As far as being able to see an actual real-life integration of Dwolla White Label, keep in mind that the entire point of White Label is that you’re wanting to remove most of Dwolla’s branding and make it appear as if it is something that you’ve built yourself. With that being said, if you reach out to us, through a consultation we can set you up with a conversation where you can speak to some of our partners who are happily using White Label today. We also have great case studies that continue to come out on a regular basis, where we feature businesses that are using our White Label. The best place I think to direct people to take a look at the White Label API would be developers.dwolla.com. That’s a great place to get started, that’s got all the dev docs, that’s got guides and best practices, pretty much everything you need—and a sandbox—to get started.
What is the difference between CIP verified and a customer record, which would be better for payouts?
You are able to make whatever kind of customer record you like for your integration, but really as far as what would be the least amount of friction—if you’re only going to be doing payouts I strongly recommend you create White Label Receive Only accounts, and that’s because they are not having to give things like the last four of their social security number, their physical address, you know things like that that may cause friction. Additionally, it’s important to understand that when you’re using the Dwolla network, if you’re only going to be ever receiving money, you are not required to verify the bank account. You can simply enter in the routing and account number. But anytime money is being sent into the network, they will need to verify their bank account using that Instant Account Verification (IAV) process through Dwolla.js that Spencer mentioned, or we do offer the micro-deposits which has been around for quite some time, entering in the routing and account number and coming back and verifying those amounts. Short answer: if you’re going to be doing payouts, White Label Receive Only is the way to go.
How do you get started with an initial consultation? Should I call you, should I email you?
The next step for anyone interested in a consultation and advancing the discussion, head to dwolla.com/contact. There’s a form there to fill out your information and it goes directly to our business development team, and then we’ll be following up to get more information and set up a call with you guys.
In conclusion I just want to thank everyone for joining us today, feel free to head to dwolla.com/contact to take your payments to the next level. Thanks again, and we appreciate you joining us today.