Medusa Integration

How Reorder connects to Medusa’s native modules — products, customers, orders, carts, and payments.

Reorder is built as a native Medusa plugin. Rather than managing its own product catalog, customer records, or payment processing, it links to the modules Medusa already provides. This means subscription data is always connected to the same products, customers, and orders your store already uses.

Module Links

Reorder defines six module links that connect subscription records to Medusa core data. These links are established using Medusa’s defineLink API and resolve through the standard query interface.

Reorder model	Medusa module	Cardinality	Description
Subscription	Customer	many-to-one	One customer can own many subscriptions
Subscription	Cart	one-to-one	The cart from the subscription checkout
Subscription	Order	one-to-many	Original checkout order and all subsequent renewal orders
RenewalCycle	Order	one-to-one	The Medusa order generated for each renewal cycle

Because these are standard module links, you can resolve them using Medusa’s query.graph() from any workflow, API route, or subscriber — no Reorder-specific query layer is needed.

Product and variant data is stored directly on the Subscription record as product_id, variant_id, and a product_snapshot field. Link definitions for Product and ProductVariant exist in the Reorder codebase but those link records are not populated during normal operation — use the snapshot fields to read product context.

Checkout Flow

When a customer subscribes through the storefront, Reorder wraps Medusa’s native completeCartWorkflow. The subscription record is created and linked to the resulting order in the same transaction. After checkout completes:

• A Subscription record is created in Reorder’s module.
• The subscription is linked to the Order produced by completeCartWorkflow.
• The subscription is linked to the Customer and Cart via module links.
• Product and variant data from the cart line items is stored as a snapshot on the subscription record.
• The first RenewalCycle is scheduled based on the plan’s billing frequency.

This means the initial subscription order appears in Medusa’s standard orders list alongside all other orders — no separate order management surface is needed.

Payment Module Integration

Reorder uses Medusa’s payment module for all money movement. It does not implement its own payment provider or store payment credentials.

Renewals — when a renewal cycle executes, Reorder creates a new order using createOrderWorkflow, then calls createOrUpdateOrderPaymentCollectionWorkflow and createPaymentSessionsWorkflow to collect payment. Authorization and capture are handled via the payment module service directly.

Dunning — when a renewal payment fails, Reorder opens a DunningCase and schedules retry attempts. Each attempt re-uses createOrUpdateOrderPaymentCollectionWorkflow and createPaymentSessionsWorkflow against the same renewal order. Attempt records are stored on the DunningCase.

Because payment processing goes through Medusa’s standard workflows, any payment provider that works with your Medusa store automatically works with Reorder subscriptions and renewals.

Orders Integration

Every renewal generates a standard Medusa order. These orders appear in the Admin orders list and can be managed, refunded, or fulfilled using the same tools as any other order.

In addition, Reorder adds a widget to the Order Details page in Admin that surfaces the subscription context for any order that was created by a subscription renewal. See Orders Widget for details.