More information on Dwolla, and pay as you go

Hi,

Our company is looking at Dwolla (very impressed with the API examples) to run Direct Deposits for our software.

We offer a payroll service where our users would run payroll and pay there employees. Now I gathered some information from looking at the examples and I would like to detail them in a list below to see if I am correct in my approach to partnering with Dwolla.

  1. When our customer signs up for our software, we would provide them the ability to opt for a direct deposit for certain employees or all employees. Which we would have to get them to accept that we will share the information with Dwolla and be able to have that saved into our database to present at any time necessary.

  2. The client, which will always be a business, will then have to be added as verified Business Customer.

  3. When our client adds a bank we will add their bank information, and do a micro deposit check for them to verify the bank.

  4. The employees would be set up as unverified customers that are receive only users that we would capture their bank information inside our software. Would their bank information need to be added to dwolla as well?

  5. After our client runs payroll. We would then process that request through Dwolla to initiate the Standard ACH. Do you have any examples of a bulk amount of many being paid to many customers? I have not been able to find one.

Pricing questions

  1. We will have to start as the pay as you go model. And standard ACH is .5% per transaction with a max of $5. So if our client runs a payroll for $5,000 for 5 employees would that be $5.00 or would that be $5 per employee receiving funds?

  2. How do you receive the funds for the ACH transactions? actually through the transaction itself or will this be billed to us, and we will have to withhold this amount from our client?

  3. Is there the ability to switch pricing tiers seamlessly, so If we were to get enough clients to hit the point where it would make sense to move to the Scale pricing plan would this be a seamless transition (just changing the api keys)?

Sorry for the lengthy post, I appreciate any answers!

Thanks,
Eric

This post was flagged by the community and is temporarily hidden.

Hi,
I think you meant to create your own question, This is a question that I asked!

Sorry for that

Hi @Eric, thanks for posting! See my replies inline below…

Asking a few clarifying questions Who would perform the action for #3 and #4?

Q #3: would you create the Dwolla Customer account and add the bank account on your client’s behalf, or would the client login to your application and submit information required to be created as a verified Business Customer and then submit details for their bank?

Q #4: Would the employees setup their payment account or would your client setup the employees account on their behalf? (assuming they’d have access to their banking data?). The information would need to be collected from the end-user of the app and submitted by them. For example, if I’m an employee, I’d need to sign-up on your app to agree to your TOS and Privacy Policy. Once complete, you’d collect firstName, lastName, and email (which you may already do as part of your user signup) and then direct them to a screen to submit their bank details which would then be passed to Dwolla via the API.

Q #5: Ideally the client would login to your app to review the payment details for the batch of payments they’d want to submit. Once complete, they’d hit submit and your application would call our Mass Payments API behind the scenes. That API request would take in a list of items which are individual requests to end-user’s bank accounts (employees) setup as Receive-only users in Dwolla.

This would be per transaction cost. Therefore, assuming it’s 5 individual $1000 to different employees then it’d be $5 per employee/transaction.

Assuming you are facilitating a transaction between your client (verified Business Customer) and an employee (Receive-only user), we would charge you variable fees at the end of the month via an invoice.

The next pricing tier would be our Scale tier which is a flat rate consultative pricing. You would meet with a Dwolla rep to understand what features you’d need access to and go over transaction volume. You’d then sign and agree to a services agreement and be billed on a monthly basis. Once the business aspects are done, then it’s a pretty quick switch (no changing of API keys needed).

Hi, Aravindkumar.

  1. When you are creating a Personal Verified Customer, make sure you are passing in the correct request parameters. and are using a valid token (tokens expire 60 min) This guide will walk through the identity verification process for personal verified Customers within the Dwolla API.

  2. To create a card funding source token, make sure you are passing in the Customer ID which represents the user who will submit their debit card details. You can find this ID by using the list and search customers endpoint, or inside the sandbox itself on the “Customers” tab upon login. Click name, then Details. For additional information on creating a card funding source token, check out our guide

We also have a Postman Collection you can utilize for easier testing here

Create customer Request body:

var requestBody = {
		"firstName": "Rylan",
		"lastName": "Bruce",
		"email": "ralan.bruce@nomail.net",
		"type": "personal",
		"ipAddress": "99.99.99.99",
		"address1": "99-99 33rd St",
		"city": "Some City",
		"state": "NY",
		"postalCode": "11101",
		"dateOfBirth": "1989-01-01",
		"ssn": "0736"
};
let data = await dwolla.post("customers", requestBody).then(function (result) {
      return result.headers.get("location"); 
    }).catch(err => { return res.json(err) })
    return res.status(200).json({data, message:"Customer created successfully"})
  } catch (error) {
    return res.status(400).json({ error })
  }

Response from API

{
    "status": 403,
    "headers": {},
    "body": {
        "code": "Forbidden",
        "message": "The supplied credentials are not authorized for this resource."
    }
}

We resolved the issue on a different thread! Thanks Aravind for being patient with us while we were figuring out the issue!