How OnPoint Warranty started selling warranties online through partner storefronts

The situation before we showed up

OnPoint Warranty connects brands and consumers with warranty services: extended and OEM warranties, deductibles and on-demand repairs, sold under its own name and on behalf of the brands it works with.

The company was taking that business online. Consumers needed to buy warranties and subscriptions directly, and resellers needed their own branded shops selling the same products. The first partner was ready to go to market, so the platform had to process real transactions from its first release.

Why this was harder than a normal online shop

• The product is a contract.
  A warranty sale only exists once OnPoint’s contract system has issued a contract number for it. Checkout is the middle of the process.
• The same catalog, many shops.
  Each partner sells under its own brand, sometimes with its own product names, while pricing and contract logic stay in one place.
• Availability depends on where the customer lives.
  Warranties are sold state by state, so the catalog has to change with the customer’s location.
• Some products need a property address.
  A home warranty is tied to a building, so that address has to be captured at checkout.
• Subscriptions sit next to one-off sales.
  Monthly, quarterly and yearly plans had to work in the same cart and admin as single purchases.
• Past sales lived elsewhere.
  Existing customers and orders had to be brought into the new platform.

What we built

One Magento platform running every storefront, with custom modules for the warranty-specific parts and integrations to the systems OnPoint already ran.

One platform, many storefronts

• Each partner storefront is its own website on a single Magento install, using Magento’s website, store and store view structure
• Products are assigned per storefront, and a product can carry a different name on each one
• Shop-limited admin roles, so each dealer gets a login that reaches only its own shop
• A custom front-end theme built on Magento’s Luma theme, styled from OnPoint’s existing sites
• Separate staging and production environments, with the code in version control

Products that know they are warranties

Every product carries a custom product type: warranty, deductible or on-demand. That one field changes the product page layout, the fields a customer fills in at checkout, the API calls made for the order and the emails sent afterwards.

Two custom modules we developed do the rest. State availability controls which states a product is sold in, so a storefront with a state selector only shows what the customer can actually buy. Property address makes checkout collect the address each warranty or on-demand product covers.

Subscriptions run through Aheadworks Advanced Subscription Products, with monthly, quarterly and yearly plans priced per storefront.

Every order becomes a contract

When an order contains a warranty, deductible or on-demand product, Magento calls OnPoint’s contract API. The API returns the contract numbers, and Magento stores them on the order in its own contracts section. The same contract details appear in the customer’s own account, so both OnPoint’s team and the customer can see exactly which contracts a purchase produced.

Emails follow the same logic. The customer receives a thank-you email, then one or more emails chosen by the product types in the order. Each storefront can use its own templates for each product type.

The systems around the shop

• HubSpot. Orders and customer details sync every 15 minutes, so marketing works from real purchase data.
• Kustomer. The support team’s CRM is connected to Magento, so customer conversations sit alongside order history.
• Authorize.net and PayPal. Payments run through Authorize.net, with PayPal configured as well for one-off purchases.
• Taxes and discount codes are managed in the Magento admin by OnPoint’s own team.

Automating the operations around the orders

With the platform taking orders, the next phase automated the operational steps around them.

A replacement program with the card on hold

For a replacement program for countertop ice makers, the customer’s card is held first and only charged if the unit does not arrive in time.

1. A replacement order is placed
   A dedicated product type triggers the flow, and it sits alone in the cart.
2. Magento places a hold on the card
   Through Authorize.net, so no money moves yet.
3. Magento checks the shipment
   It sends the order ID to the client's shipping API and reads back the status.
4. The rule settles it
   If the unit arrives within 10 days, the hold is released automatically. If it has not arrived, the card is charged automatically.

The program also got its own customer portal, styled from an existing storefront template.

Refunds without leaving Magento

An admin opens the order, enters an amount and clicks refund. Magento sends the refund to Authorize.net and records it in the order’s list of transactions, so the payment history and the order stay in one place.

A second chance for failed contracts

If creating a contract fails, the order page shows a form holding every field from the original request. The team corrects what was wrong and resends it from the same screen.

The handoff

Before handover the storefronts went through QA and rounds of feedback from OnPoint’s team, and the platform moved to its production hosting with a separate staging environment.

OnPoint’s team received documentation covering the system overview, every third-party plugin and integration, and the admin tasks they handle day to day: adding products and subscription plans, managing taxes and discount codes, and working with orders and their contracts. Each task comes with a screen recording.

Built to extend

The first release was planned as the start of an iterative build, and the follow-on work landed in the same platform: new product types, payment rules and admin tools as custom modules on the same install. A new partner storefront is configuration on that install rather than a new project.