Decoupling Purchase From Onboarding in a Commerce-Driven Testing Platform

The challenge

The original checkout flow had been designed around the platforms internal data model. To complete a purchase, a customer first had to create an account. Then they had to create an entity record — the biological or product-associated object the test would be linked to. Only after both steps were complete could they proceed to payment.

This sequence made sense from a data integrity standpoint: the internal system was built to associate tests with specific entities, and the purchase flow had simply been built to reflect that requirement. But it imposed the platforms internal onboarding logic onto the external buying experience in a way that served neither the customer nor the business.

For a first-time buyer who just wanted to purchase a test, the flow required account creation and profile setup before they could reach payment. For someone buying a test as a gift, the requirement to register an entity they did not own was a barrier that had no clean resolution. For buyers who wanted to delay assignment — purchasing a test to use later, or buying multiple tests for a managed population — the flow offered no path forward.

Drop-off in the checkout funnel reflected this friction. The organization also had limited ability to support broader commerce channels. Stripe Checkout and Shopify, both practical options for expanding purchase surface area, were incompatible with a checkout flow that required mid-session entity creation before payment could be initiated. The buying experience the platform offered was narrower than the business needed it to be, and the constraint was not a product decision. It was an architectural one.

The approach

Protabyte began by separating the purchase concern from the fulfillment concern. The original architecture treated them as a single flow: buy, create, associate, fulfill. The redesign treated them as distinct: buy first, fulfill when ready.

The mechanism that made this possible was an activation-code fulfillment model. When a customer completed a purchase, the system issued an activation code representing the purchased test. That code could be assigned to an entity at any point after purchase — during the same session, later in the customers account, or by a recipient in a gifted purchase scenario. The test itself was purchased, paid for, and held in a fulfilled state. The downstream association to a specific entity was deferred until the customer was ready to make it.

This change required more than a front-end adjustment. The backend order and payment handling had to be refactored to support a purchase that was complete and valid without an entity association at the time of checkout. Account creation logic was redesigned to support automatic account creation or user mapping at purchase time, preserving the organizational need to associate orders with customer records without requiring the customer to complete that process before paying. Activation code generation, storage, validation, and redemption were introduced as first-class operations in the fulfillment layer.

With the purchase flow decoupled from entity creation, the path to broader channel support became straightforward. Stripe Checkout integration was implemented to support streamlined direct payment without a custom checkout interface. Shopify-compatible purchase flows were enabled, expanding the surface area through which customers and partners could initiate purchases. The backend fulfillment architecture handled activation code issuance consistently regardless of which channel originated the order, preserving internal business rules across all purchase paths.

Throughout the engagement, particular attention was paid to the integrity of the order, payment, and account association logic. The goal was not to remove the data model requirements that the original flow had been built around, but to move them downstream of the purchase event so they no longer stood between the customer and completing a transaction.