In the retail world, no one likes to be forced to create an account before purchasing a product. It’s well-known that it hurts the conversion funnel But in the subscription world, this is often a must-have. Subscriptions are complex products that require self-service - without registration and authentication, how will customers manage their subscriptions? So while it’s possible to skip authentication, it’s not best practice.
Not only will it make the customer experience more convoluted, but if you have an unauthenticated checkout, it makes provisioning an order much more complex. You will need to think about how you link the order to the customer’s identity. Post-purchase, there will need to be mechanisms to require the subscriber to create their account, but none are error-proof. Do registration on the order complete? The customer can close the tab. Do it via email? It can end up in spam or ignored. And there are complex edge cases, for example what if the customer makes a mistake in their email, how do you resolve those issues and assign the subscription to the correct identity?
Spare yourself some pain and plan to build and maintain an authentication mechanism as part of your ecommerce. If you already have an authentication mechanism, which most media or SaaS customers will already have, then you should re-use that. If you don’t have currently like most retail companies, then you’ve got two options:
- Build Your Own Authentication System:
- Pros: Tailor-made to fit specific requirements, offering full control over the authentication process and data. It can be more flexible in terms of integrating with existing systems and workflows.
- Cons: Time-consuming and expert resource-intensive, requiring significant development expertise. There's also the ongoing responsibility of maintaining security, updates, and compliance with data protection laws. It often will lack critical components such as OAuth, SAML, and OpenID.
- Buy/Use a Third-Party Authentication Provider (Auth0, Okta, AWS Cognito, Microsoft Azure, Salesforce Identity):
- Pros: Quick to implement, often just requiring integration into your system. These providers usually come with robust security measures, regular updates, and compliance with various data protection regulations. It also supports import frameworks such as OAuth, SAML and OpenID.
- Cons: Less flexibility in terms of customization. You're also reliant on a third party for critical security aspects and need to adapt to their system limitations and pricing models.
You will need to develop the UI for the authentication and registration. Most third-party identity platforms will have their own standards. If you plan on custom-building, developing the UI for registration and authentication should focus on simplicity, clarity, and security. Start by designing a clean and intuitive layout, with clearly labelled input fields for essential information like username, email, and password. You’ll need to incorporate visible validation messages to guide users through the process, and ensure that error messages are helpful without compromising security (don’t give away too much!). For a seamless user experience, integrate options for social media logins and remember to design for mobile responsiveness. Lastly, prioritise security features like two-factor authentication that is appropriate to your audience.
Last but not least, how do you link authentication to your overall customer identifier in Zuora and Salesforce (if they already exist). If you are john@smith.com, how does that relate to Zuora Account A-00001 and Salesforce Account ID 100AEXFF ? For example, to connect Zuora to Salesforce, Zuora requires a CRM ID at the time of creation, so that Zuora Z360 can show the relevant data in Salesforce. This is often work that needs to be carried within the authentication layer. Else you would need to query the external systems when creating the order, degrading the customer experience by increasing the order processing time due to the additional API calls involved. The best practice is to pass the relevant identifier to the identity provider, store them in the JWT token, and then use the information as part of the order provisioning.