“The Story of Blinkpay: Making something complicated really simple” by Jared Christensen
My introduction to Blinkpay came in the form of a meeting. Across the table was a gentleman from a local payments processing company. These are the folks who work with businesses to set up a merchant account and get them situated to accept credit card payments. They also handle the transactions for the merchant, running payments through all the necessary systems and then getting the money deposited into the merchant’s account. For what we wanted to do with Blinkpay, we needed a partner like this.
The conversation was pleasant and informative. I asked a few questions, and by the end of the meeting I had in my hands the intimidating stack of paperwork required to become a merchant.
It was my job to take this daunting process and make it feel achievable.
Getting the lay of the land
I began designing for Blinkpay by coming at it from 2 different directions. The first direction aimed to understand the existing paperwork, the application process and how the electronic payments system worked in general. This was practical work; Blinkpay would have to work within the payments system, so this direction sought to understand what was malleable and what was not.
The second direction came at Blinkpay from the users’ perspectives (both the Blinksale merchant AND his clients). No matter the constraints that would be discovered by exploring that first direction, Blinkpay had to align with the same design tenets that guide Blinksale: clarity, honesty, perceived simplicity and delight (to name a few).
I studied, reorganized and challenged the merchant application. I diagrammed my understanding of the payments industry’s processes. I incessantly posed questions to our chosen payments processor (JetPay), asking every stupid question I could think of to understand the entire scope of processing a credit card, and all the possible scenarios that could come out of that process.
At the same time, I worked out task flows, user interfaces and mockups describing the ideal Blinkpay implementation from the users’ point of view and shared them with JetPay. This communication allowed us to work out kinks, recognize constraints and keep forward momentum.
(Even though this writeup is going to make it seem like designing Blinkpay was a linear process, nothing could be further from the truth. Even the best-laid plans went through revision after revision, adapting and refining as new information came to light.)
The Merchant Application
The true start of the Blinkpay experience is the online application process, and I knew it could not be as complicated as the paper application. It had to ask for only the most absolutely essential information. It had to feel relatively easy, straightforward, honest, and simple; at the same time, I also wanted to provide enough information to educate applicants seeking to dig deeper into the nitty-gritty details of the agreement. It had to be able to be saved and re-opened as many times as the applicant needed to complete it, so there was no pressure to finish it all at once. And it had to put the applicant at ease—the exact opposite effect of its paper counterpart.
I began designing the application by translating the paperwork into wireframes, sending them to JetPay and getting feedback. There is a fair amount of intentional redundancy in the paper application, and the back-and-forth exchange helped JetPay to see the application in its new context and better identify which portions could be removed.
For the actual implementation of the application, the form takes the scattered information of the paper forms and organizes it into 6 (mostly) brief pages. Not only does this approach make each page contain less information and break the form into logical groupings, it also makes it feel like progress is being made more quickly by putting the easy parts up front. Heck, the first page is almost entirely pre-filled with information pulled from the account’s Company page.
Visually, the application simply builds off of Blinksale’s existing form design, using a soft & neutral color palette. The applicant’s progress is displayed at the top of each page so there is a sense of how far he as come and how much remains. Contact information is displayed in the sidebar of every page, reinforcing that feeling of safety and ease we want the user to have while in the application.
The result of this effort is a 100% electronic signup process. All supporting documents can be attached and uploaded, and the whole application is electronically signed.
Signing the application
A major sticking point in the application comes at the end, where applicants must typically sign and date in numerous places. Not only does all that signing feel bothersome on paper applications, but the online incarnation doesn’t really lend itself to that kind of approach
I looked at the top online signature services out there but didn’t feel like they were appropriate for our needs. Drawing your signature with your mouse? Please. I figured we had more than enough digital fingerprints already on the application that I could design something more appropriate. So we proposed an alternate solution:
No silly scribbling with a mouse. No multiple signatures. Simply type the randomized verification word into the textfield and click “Sign this form.” Signature complete.
We were able to implement this solution thanks to being backed by a very progressive bank, as well as the fact that a user has to be logged in to access the form. So, when the application is signed, we have the signer’s Blinksale ID (and, therefore, payment info, full name, email address, etc), login name, password, ISP and the date it was signed as proof of identity. For our particular case, this solution is acceptable.
Your Blinkpay service has been activated!
Activation is the last step in the on-boarding process, and turns on all of Blinkpay’s features for the account.
Once activated, the user’s probable first point of interaction with Blinkpay happens when sending an invoice. The “Send Invoice” dialogue receives a new credit card option under the payment options, right next to the pre-existing PayPal option:
Despite any global settings, payment options can be controlled per-invoice by toggling the payment checkboxes.
“How much is it going to cost me to let this invoice be paid by credit card?”
This is one of the questions I could imagine our customers asking as they looked at the Send Invoice dialogue’s new payment option.
Every Blinkpay account starts with a low baseline rate for transactions. However, there are several factors which can push the fees per transaction slightly up or down. For this reason, I knew we couldn’t predict the exact fees for every single transaction for every single merchant. By using the default baseline rates, however, we could at least get close.
So, next to the Credit Card option, the estimated fees for the transaction are displayed. This allows the merchant to see their invoice total and the estimated cost of enabling the credit card payment option—all on the same screen.
Paying the Invoice
A clear and encouraging path to payment is at the heart of Blinkpay. After all, how to pay the invoice is a decision left in the hands of the client. No one is forcing him to pay online instead of mailing a check. It has to be easier.
With the Credit Card (and/or Payal) option checked on the Send Invoice dialogue, the sent invoice arrives in the client’s inbox. At the top of the email is a “Pay this invoice…” link which leads to the invoice’s online payment page.
When this page loads, all of the payment options that the merchant has enabled for that invoice display at the top of the page as big icons. This clearly tells the merchant what his next move should be.
Choosing the Credit Card option prompts the client to confirm the amount he would like to pay. On behalf of the merchant, Blinksale pre-fills this field with the total amount due. After confirming the amount, the client continues to the payment screen, where he can enter his info and send the payment.
All credit card payment data entry is done inside of a customized iframe, hosted by JetPay. The benefits of this approach on the security side are great, but presented challenges on the presentation side.
The last place you want to introduce an element of uncertainty is on a payment page. The iframe implementation had to look like it was just a normal piece of the page, because—for all intents and purposes—it is. JetPay created a custom version of the iframe for Blinkpay which allowed us to style it to match up with the surrounding page design. Without viewing the source, you’d never know it was an iframe.
But styling was the easy part. On top of styling, our iframe needed to support error messaging and help blurbs.
The challenge for both of these features is that they could not alter the width or height of the iframe, lest scrollbars appear in strange places and introduce that element of uncertainty. The help blurb was pretty straightforward (we just popped open the content in a smaller window inside the iframe), but the error messages were a little tricker. In the end, I found a good solution in positioning the error messages over the existing form labels:
This approach both provided the necessary context for the errors and prevented the iframe from growing scrollbars.
Upon a successful transaction, each party has to be notified. For the client, I designed a simple emailed receipt containing relevant payment information. For the merchant, a notification system pushes a note to the account dashboard.
In addition to notifying the merchant of payment, Blinksale is also able to determine if the invoice has been paid in full and Close the invoice if that is the case.
Step 1: Fill out application. Step 2: Get activated. Step 3: Get paid fast. That’s really what we’re going for.
Blinkpay contained a of of complexity, and it was a challenge to always be standing in a place where I could see of all the angles. I don’t think I always succeeded, but there are a few things I did which helped me stay sane:
Internalize. This sounds overly simple and difficult at the same time, but try to remember everything that you can as you progress through a feature, project or design—especially the big ones. If you care about the work, this comes naturally. Drawing on this backlog of accumulated knowledge as complexity builds can provide clarity as you look ahead. Become the expert.
Sketch it out. Use words or visual tools—whatever works for you. I use both. Writing out a problem often leads me right to an answer. Roughly visualizing ideas with Keynote, Photoshop or a pencil helps get terrible ideas out of the way quickly so the mind can move on to better things.
Listen to others. Even the most hot-shot designer in the world is not the vessel of all truth. Great ideas can come from anyone on the team, so pitch your ideas to them and let a discussion happen. In the end, it is not important who came up with the best idea, but finding the idea leads to a great solution.
Document patterns. Yes, any pattern. It saves so much time if you can look at a particular problem and reference an existing solution. Keep a PSD of UI elements, or a wiki of interactions or whatever you need to easily reference your past work and decisions.
It’s always challenging to design within an established ecosystem, and the world of electronic transactions is certainly rigid. There is little room for compromise or change.
The goal of Blinkpay, then, is to let Blinksale customers enjoy the benefits of online payments without having to deal with all the minutiae. And that’s what design is for—to help people accomplish their goals, and enjoy themselves along the way.