To fulfil those expectations, you will need to get building and coding. You will need to set up a DevOps infrastructure, front and back-end frameworks, and release processes. The key areas will be:

• Domain and Hosting: Choose a relevant domain name and a hosting service suitable for your website's scale and traffic.
• Front-End Development: Use HTML, CSS, JavaScript, and frameworks like React or Angular for designing the user interface.
• Back-End Development: Employ languages like Python or Node.js and databases (SQL/NoSQL) for server-side processing and data management.
• DevOps and Deployment: Implement version control with Git and automate deployment using CI/CD tools like Jenkins or cloud services like AWS.
• Testing: Conduct unit, integration, functional, and performance testing to ensure robustness and reliability.
• Security: Secure data transmission with SSL/TLS, regularly update software, and use security tools like firewalls and anti-malware.
• SEO and Analytics: Optimise for search engines and use tools like Google Analytics for insights into traffic and user behaviour.

Now the nice thing is none of this is specific to Zuora, so you will find plenty of developers happy and willing to help. The basics for a subscription ecommerce website are similar to a regular website, but we’ll tackle all the particularities and specificities of subscriptions commerce in the next sections, and in particular Zuora commerce.

Ok so you have the barebone of a website, now it’s time to create your Zuora Commerce website! First thing first, your customers need to browse the catalog. For subscriptions, it can be fairly simple (e.g. Spotify Free, Spotify Premium, Spotify Family) as opposed to sprawling ecommerce catalog. It can however be more complex if you have many products and add-ons. So let’s break down what you need to think about. We’ll merge in product and pricing pages, as a lot of subscription products will present all the information in one place, but you could also separate them.

Product & Pricing Page:

• Content or Product Descriptions: For digital subscriptions, describe the type of content (e.g., courses, e-books, software); for physical products, detail what items are included in each delivery.
• Subscription Options: Detail the different types of subscriptions available, such as monthly, quarterly, or annual plans, and any variations in the frequency of deliveries or access.
• Trial and Demo Information: Provide details on any free trial periods or demo versions, explaining what is included and how to sign up.
• Promotional Discounts: Highlight any introductory offers or discounts for new subscribers, and explain how and when these apply.
• Plan Comparison: If offering multiple tiers, provide a side-by-side comparison of features, benefits, and prices for each tier.
• Bundling Options: If bundles are available (e.g., combining different products or services), clearly outline what each bundle includes.
• Customization Options: If subscribers can customize their subscription, provide clear instructions and options for doing so.
• User Reviews and Testimonials: Share feedback from current subscribers to build trust and provide insight into the subscription experience.
• FAQ Section: Cover common questions about subscription terms, cancellation policy, pausing subscriptions, and any other relevant details.
• Cancellation and Refund Policy: Detail the process for cancelling a subscription and any refund policies that apply. This can be mandatory in some regions or for certain products.

Again, not much that is specific to Zuora Commerce, though you will need to pull the price from somewhere. Do you hardcode them on your website, store them on a local database, or do you pull them dynamically from Zuora? Let’s consider the options:

• Hardcoding Prices on the Website:
• Pro: Simple setup with direct control over price changes.
• Con: Time-consuming updates via a developer and poor scalability for large or frequently changing catalogs.
• Storing Prices in a Local Database:
• Pro: Dynamic pricing with centralised data management and integration potential, faster load times.
• Con: Requires more infrastructure maintenance and regular synchronisation for accuracy.
• Pulling Prices Dynamically from Zuora Catalog:
• Pro: Real-time pricing accuracy and automated updates tailored to customer behaviour.
• Con: Relies on Zuora's system reliability and can impact website performance if not optimised.

The right option for you will depend on the use case. Simple pricing with little promotional activity? Hardcoding might be fine for those simple use cases or to start with. More pricing with lots of promotional activity and where load time is critical? Storing prices in a local database will make more sense. Complex pricing such as consumption-based price? Pulling prices from Zuora will guarantee the best accuracy, but the experience might be slow. A good workaround can be to show prices such as ‘From $99 a month’ or ‘Starting at $9/user/month’ and performing calculations in a cart in the cart or checkout. Don’t forget you’ll also need to pull the name of the product and pricing from somewhere, and this could change with time (Digital - 50% off).

In subscription commerce, having a shopping cart is often deemed optional because the purchasing process typically involves selecting a subscription plan rather than adding multiple individual items to a cart. However, even if not prominently displayed, maintaining a "hidden" cart system can offer several benefits:

1. Abandoned Checkout Tracking: A hidden cart allows you to track when potential customers add subscriptions to their cart but don't complete the purchase. This data is valuable for understanding customer behaviour and for retargeting efforts, such as sending reminder emails to encourage completion of the purchase.
2. Upselling and Cross-Selling: A cart system can facilitate upselling and cross-selling by suggesting additional or complementary subscriptions before checkout. This can enhance customer experience and increase revenue.
3. Flexibility for Customers: Even in subscription models, customers might appreciate the flexibility to manage multiple subscriptions (like adding, modifying, or bundling different plans) before finalising their purchase. A cart system makes this process more intuitive.

In essence, while not always front and centre in subscription commerce, a cart system, even if hidden, offers valuable tools for customer engagement and operational flexibility.

So if you want to create a cart, how do you do it? Zuora doesn’t include a cart concept in its application or APIs, so you’re on your own here and will need to build the logic as part of your website. What are the key components of a cart?

• Product Details: Name, description, and image of the product or subscription plan, providing clear and informative details about what is being purchased.
• Quantity (optional): For e-commerce, the number of each item; in subscription commerce, it might indicate the number of subscription units or duration.
• Pricing: Displays the price for each product or subscription plan, updated in real-time for changes in quantity or duration. This may require API calls to Zuora if quantities are updated for example. This can be quite complex if you have consumption-based pricing and promotions applied.
• Promo Codes: A field for entering discount codes, with the cart recalculating the total price upon applying a valid code. Promo codes aren’t natively handled by Zuora, you will need to build your own solution or consider add-ons.
• Total Calculation: A dynamic total that updates with changes in the cart, including itemised costs like taxes (if possible) and discounts. Again, this may require API calls to Zuora to retrieve the correct calculation.
• Update Mechanism: Functionality to change quantities or remove items, with immediate recalculation of the total cost.
• Checkout Button: A clear and prominent button leading customers to the next step in the purchasing process.

There's a couple of other complexity to handle:

• Analytics: If you build a data-layer, you'll need to make sure to track the add_to_cart and remove_from_cart events with the relevant product information.
• Multi-domains: If you have multiple subdomains but want to persist the cart across them, you'll need to think about a cookie or server-side solution. If it's a cookie, you'll need to make sure to clear it after the purchase is done.

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.

The checkout is likely the largest beast to tackle in subscription commerce, even more complex than authentication. Offering a checkout that can cater to all the different subscription pricing, the complexity of certain baskets, the regulatory requirements around cancellation and price displays, and the ability to purchase, renew, upgrade throughout the subscription lifecycle is complex enough. But layer on integration for payments, tax, addresses, and the requirement for security and speed, as well as marketer’s desire to control the look & feel and experiment with different checkouts and it becomes a nightmare. We haven’t even touched how to do it specifically with Zuora.

Let’s breakdown the key components of a checkout:

1. Flexible Pricing Structure Integration: The checkout system must handle various subscription pricing models (like tiered, volume-based, or per-user pricing) and support different billing frequencies (monthly, annually). It should also accommodate promotional pricing, discounts, and trial periods.
2. Complex Basket Handling: The ability to manage multiple subscription products in a single transaction, including bundling different products or services and handling add-ons or upsells effectively.
3. Regulatory Compliance: Ensuring the checkout process complies with global and local regulations regarding cancellation policies, price transparency, and consumer rights. This includes clear communication of terms of service, privacy policies, and return/refund policies.
4. Payment Gateway Integration: Securely integrating with multiple payment gateways to offer a range of payment options (credit/debit cards, digital wallets, bank transfers). This includes express payment methods such as Apple Pay and PayPal.
5. Tax Calculation and Compliance: Automatically calculating taxes based on the product, customer location, and local tax laws, including handling of VAT, GST, and other applicable taxes for different regions.
6. Address and Delivery Management: For physical subscription products, efficiently managing shipping addresses, delivery options, and costs. This includes integrating with address prefill and validation services to streamline the checkout process, ensuring accuracy and speed in address entry. For digital subscriptions, ensuring the user's location aligns with service availability and compliance requirements.
7. Security and Data Protection: Implementing robust security measures to protect customer data and payment information, including encryption, secure socket layer (SSL) certification, and compliance with standards like PCI DSS.
8. UI/UX Design Flexibility: Allowing marketers and designers to control the look and feel of the checkout process, ensuring it aligns with brand identity and provides an intuitive user experience.
9. A/B Testing and Optimization: Enabling the testing of different checkout flows, layouts, and elements to optimise conversion rates and improve the customer experience.
10. Analytics and Reporting: Providing tools to analyse checkout performance, track abandonment rates, and gather customer feedback for continuous improvement.
    

To go further, you may need to think about:

1. Multinational Checkout Support: Equip the checkout to handle multiple currencies and price zones, enabling customers to see prices and transact in their local currency. Additionally, offer multilingual support for the checkout interface.
2. Different Checkouts: Support varied input requirements, such as options for gift recipients or company purchases. This includes fields for entering gift recipient details, special instructions, or company-specific information like tax identification numbers.
3. Promo Code Integration: Implement a robust system for promo code application within the checkout. This feature should allow customers to easily apply discount codes or special offers, with real-time updates to the pricing and total cost.
4. Upsell and Cross-Sell Mechanisms: Integrate upsell and cross-sell opportunities strategically within the checkout flow. This can include suggesting related products, upgrades to subscription plans, or additional services that complement the customer’s current selection. Such recommendations should be relevant and enhance the overall value of the customer's purchase, potentially increasing the average order value and improving customer experience.

Lots to think about right? So let’s define the key components and focus on doing the basics:

• User Details: Integrating the user details with the authentication layer is essential. This integration helps in automatically pulling relevant details to form the basis of the Zuora Customer Accounts. It ensures that the user's profile,
• Payment Details: The integration of Zuora Hosted Payment Methods (HPM) is crucial for secure and efficient payment processing for credit cards and bank-based payment methods such as Direct Debit and ACH. Additionally, incorporating express payment methods like PayPal and Apple Pay can enhance the user experience by offering more convenience and speed in transactions.
• A word on pre-authorization: Implement a system for pre-authorizing payments during the checkout process. This can be achieved by creating a standalone payment method in Zuora, which initially holds the payment details without processing the charge. This method ensures the validity and availability of funds on the customer's payment card. Once the order is confirmed and finalised, the pre-authorized payment method is then attached to the customer's account, and the charge is processed. This approach enhances transaction security, improves customer experience by reducing payment failures, and ensures compliance with payment processing regulations.
• A word on non-supported gateway: A word on non-supported gateways: If you hear the term "non-supported gateway" from Zuora, brace yourself for a considerable amount of work. Zuora offers a Universal Payment Connector framework that enables the integration of any gateway. However, this setup is fairly complex and requires substantial technical expertise in API integration and customization. You'll need to understand the specific API calls and data structures of your chosen gateway and ensure they align with Zuora's payment processing workflows. Additionally, maintaining compliance with payment security standards and handling error scenarios becomes your responsibility. This path requires thorough planning, development resources, and continuous maintenance to ensure seamless payment processing.
• Address Details: Collecting accurate billing and delivery addresses is vital, especially considering the different address formats in various locales. Integrating with a prefill or validation service, such as Google Maps, streamlines this process by automatically suggesting addresses and validating their accuracy. These addresses then need to be correctly mapped to the BillTo and SoldTo fields in Zuora, ensuring that billing and delivery information is accurately reflected in the system.
• A word on billing address: Not every payment methods require you to collect a billing address in the checkout. For example, PayPal and Apple Pay will have a billing address available and it will be a better experience to reuse that (less fields for the customers to provide in the checkout). That said, you'll need to think about the consistency of your address data (if that matters to you), as you may attempt to collect less information for debit and credit card (for example just state + ZIP code, but not the first line of address or the city). For debit/credit card, you will need to discuss with your payment gateway what is the least amount of address data you can collect without increasing the fraud and chargeback exposure risk.
• Basket: Maintaining a clear and interactive view of the customer's basket is important. This includes not just listing the items selected for purchase but also allowing for easy modifications, such as adding or removing items, changing quantities, or applying promo codes. This dynamic basket view helps customers in making final decisions and ensures that they are aware of the total cost and details of their purchase. To do that, you may need to regularly query Zuora via Zuora Preview to reflect the price based on different input.
• A word on tax: In the US and Canada, tax can only be calculated once the address of the customer is known. This will require retrieving tax through a Zuora Preview once you have sufficient information. This can rapidly be complicated if you want to show clearly to the customer tax due while keeping the experience simple and showing full costs as upfront as possible.
• Submission: The final step involves triggering the order processing once the customer completes the checkout process. This involves sending all the collected data (user details, payment information, addresses, and basket contents) to Zuora for processing.

Et voilà, you’ve got a checkout that can handle a purchase and make the Order API call to Zuora to create a Zuora Customer, Zuora Subscription, Zuora Payment Method, Zuora Contacts, Zuora Invoice and Zuora Payments. But let’s not get ahead of yourself as that’s in the next section.

Last but not least, you need an order complete page. They are typically three types of order complete page:

• Onboarding-focussed: Some order complete pages are more focussed on onboarding, fleshing out first steps such as downloading apps, learning about key features, or setting up more details on your accounts. This approach is more typical in SaaS or Media.
• Order-focussed: The order complete page might also recap the order, for example showing all the details captured including billing, delivery, payment details etc. This approach is more typical in Retail.
• Redirect: Some companies might decide to completely skip the order complete page and take the customer straight into the subscription experience. This will be more typical of consumer or B2B SaaS.

Regardless of the order complete page, there is one key challenge around order completion: how do you provision access and entitlements as soon as the order is completed? It is immensely frustrating to a customer to perform a purchase and then not get access to the product immediately. Yet, Access and Entitlement systems are often custom-built and therefore required to be integrated with the ecommerce systems. Integration means failures, race conditions, and performance degradation are all on the table. One safe way to make sure this doesn’t happen is for order to be synchronous, so the customer only gets to the order complete page once all systems have been provisioned.

An even better experience, especially for media companies, is being able to jump back into the trigger point of the purchase, for example an article where the paywall was triggered. This requires conserving the referrer through the whole conversion funnel and being able to redirect the customer, for example via a Call-To-Action, back to the article.