Recurly.js Payment Flows
Creating modular and flexible systems
With the release of Recurly.js, an API documentation site for Recurly, new sample forms were needed for the Recurly’s merchants. The goal was to supply our users with a set of developed templates that were modular, systematic, and flexible. We wanted to encourage the usage of branded checkout flows but reduce the amount of time spent on developing them. This would allow Recurly’s merchants the opportunity to focus their attention on growth.
You can test out the live samples and review the documentation.
Prior to starting this project. I read through Luke W’s book Web Form Design. It gave me insight on effective form design for all industries. One of the things I needed to consider was the purpose of designing sample forms. If a merchant were to use Recurly’s API, that was already a clear indication that they had some knowledge of development. We knew we could be a bit more clever with how we would provide the forms as well as how advanced we could get with the forms.
- Ability to brand the checkout forms or integrate them into an existing website
- Provide simple forms and complex forms that accommodate various use cases
- Ability to have multiple plans, quantities, currencies
- Ability to include add on items
- Include advanced billing requirements
- Ability to edit customer information
- Mobile friendly
Arriving at a Solution
As a business, we had a variety of merchants who had a wide range of needs around checkout flows. Some merchants required one-time transactions where others required subscription models. The complexity of catering to such a wide range of business types meant I needed to come up with a design that would allow for flexible functionalities. The thinking was split up into a few parts: account information, payment information, and additional purchase information. In splitting the forms into 3 parts, it allowed the customer to customize these areas without affecting the outcome of the other parts. For instance, a merchant could require an email address in addition to first and last names for account information. In other cases, a merchant may only need payment information to process a purchase. The designs allowed for these types of changes.
I went through many iterations of wireframes to nail down the core experience. The final flow is displayed below:
I wanted to make sure I was also designing the forms systematically so developers could deliver code that was easy to navigate for our merchants. This allowed me to create a workflow that adopted the Atomic Web Design methodology. I then leveraged Sketch app’s symbol libraries to efficiently design components.
Kale Krate is the final form design set that we provided our merchants. The sample subscription business below was created to illustrate the capabilities of a minimal checkout form. We designed the form to reduce a lot of pain points that are commonly seen with checkout flows.
For instance, in this form we are able to auto detect credit card types as the number is entered. This allows the user to instantly verify acceptable payment methods our platform allows. The initial goal was to create a smart checkout much like this one. However, technical limitations with 3rd party processing engines hindered the implementation. We also discovered that sometimes being too clever might not be the right solution for our users. As you can see, the design of the forms are split into a few parts: branding, purchase summary, billing information, and call to action.
The advanced form is much more complex and can be directly embedded into a merchant’s site. With that in mind, allowing our users to brand their forms was not a crucial factor. The primary needs were to execute on the desired outcomes. We automated a lot of the form so when a customer manipulated any part of the form it would be reflected in the order summary area.
I also wanted to consider the ability to complete one-time transactions and updating customer information.
Optimizing for mobile
Designing with mobile in mind was another aspect that drove my flexible modular designs. The modules were designed to be shifted around depending on device sizes. The other interactions that were consider include triggering correct keyboards for various input fields and readability on small devices.