Bank Payments for Intuit Quickbooks
Payers
Overview
nanopay Corporation worked with Intuit in order to provide bank payments for intuit quickbooks payers. Bank payments allows payers using intuit quickbooks to pay intuit merchants directly from their bank account reducing costs and transaction settlement times for merchants
My Role
I was the UX designer and front end developer on this project. I was responsible for working with PMs and users to problem solve based on initial user research and create end to end flows for the payer experience as well as help develop part of the front end.
Initial Research
- Bank transfers offer the greatest benefits to B2C vendors receiving numerous substantial bills (surpassing the e-Transfer $3,000 cap) from clients, as the other options involve managing and monitoring checks, or requesting customers to submit several e-transfers.
- However, for B2B sellers, they frequently provide a method for clients to make payments outside of Intuit's platform to bypass transaction costs.
-Intuit Merchants
How Might We...
How might we provide additional payment rails for payers using intuit's payment system that shortens accounts receivables and cost for merchants while retaining the speed and convenience of credit card payments provided to payers?
How might we simplify recurring payment process?
Design Considerations
Based on our research I worked with PM to establish major pain points and design considerations we needed to solve:
The new solution needs to be just as easy to use as the existing credit card solution that usually only requires a few fields to be filled out,
The compliance and technical requirements for completing bank payments are more cumbersome than credit cards,
Bank payments are fairly new for Canadian payers who are used to the ease and security of Interac e-transfer,
The beachhead for this product would be B2C payers as they are currently face the most friction in the payment process on quickbooks
Solution
Based on initial user research and design considerations, the solution used a third party service that allows us to capture all the data we need from a user's account by asking the user to log into their bank account.
User Testing & Quantitative Analysis
The pain point is it's making merchant's account receivable longer, because they would have otherwise received that payment right there but they couldn't, because the process is buggy, and it places doubt that if they would be able to make the payment in the future.
User feedback shows that while when it works the experience is just as easy as using credit cards, when it doesn't, it tends to lead to frustration and even longer account receivables than those provided by credit cards.
Analytics added to the payment flow showed a number of users dropping off due to connection issues. With a unique conversion rate of 30% for unique invoices.
"I would enter their banking information and all of sudden their banking information would disappear so I would have to back out and re-enter it. Having to do that the second time doesn't really inspire confidence."
"If it's not instantaneous I'm not waiting. Even if it's prompting 1-2 minutes, I just get used to refreshing if I have to wait that long."
Design Iteration
The problems with the payment flows were concerning and since we were using a third party service in order to capture data, it was tough to make any changes to improve reliability and UX.
In the short term, we elected to go for some easy wins of allowing the user to retry their login attempts if it failed and prompting the user that the data fetching process might take a while.
For the long term, I needed to implement a fallback flow that allowed us to capture data from the user directly in case we couldn't fetch it from their bank account. In order to complete a transaction we needed the user's account details however in our initial research I had observed that most users are not aware of their bank account details like they are of their username and password. Hence I designed a flow that walked the user through the process of finding their account details for the top Canadian banks.
Testing The New Flow
Users like the void cheque image clearly stating where they might find the information and the validation of bank details instilled confidence. However we found areas for improvement as well:
1. Payers are unsure who nanopay is and are unsure if their payment will go through → How do we instil confidence through design in the payer experience?
2. If void cheque is for recurring payment or for that transaction only → How do we ensure payers that they are only paying for 1 transaction
The Impact & Next Steps
Changes to the user experience allowing users to recover from a failed attempt to log into their bank account and a more optimized experience on mobile has pushed unique conversion up by 20%. The conversion rate for the beach-head market of payers paying bills above $3000 is even higher. I expect this conversion to go up once the new fallback flow is deployed.
Next stages of this project involve completing the fallback flow and adding the ability for payers to save their payment information so that they can easily make new payments if they have already provided their payment information.