Extend, substitute, or create?

You can build on the drop-ins Adobe provides in more than one way, and the path you pick changes how much is supported for you and how much you maintain yourself. The sections below step through the tradeoffs. Start with the recommended path, then read the others if your requirements rule it out.

Choose your approach

EXTEND

When you ExtendCustomize existing drop-ins through supported extension points such as slots, events, styling, transformers, and configuration. a drop-in, you keep the Adobe package and add behavior or UI through the extension levers the product exposes. This is the path that Adobe is set up to support and keep compatible across releases.

Recommended approach

Most needs are met with the levers in Extension methods below—without replacing the whole package or writing a new drop-in from scratch.

Extend a drop-in if you need to:

• Change how drop-ins look or behave
• Add custom content or UI elements
• Integrate third-party services (like payment methods)
• Respond to drop-in events with custom logic
• Modify how data is displayed or processed

Note: You can integrate third-party services using slots without replacing the entire drop-in. For example, integrate Stripe or PayPal payment methods into the Checkout drop-in rather than replacing the entire checkout flow.

Extension methods:

• SlotsAn extension point inside a drop-in where custom UI or behavior can be added, replaced, or removed. - Inject custom HTML/components at predefined points
• StylingVisual customization of drop-ins through CSS overrides, token changes, and layout adjustments. - Override CSS, modify layouts, replace components
• EventsData or lifecycle signals emitted by drop-ins that custom code can listen to in order to run additional behavior. - Listen to data events and add custom behavior
• ConfigurationSettings used to change behavior without rewriting core implementation logic. - Modify drop-in settings and options
• TransformersFunctions that modify or shape data before a drop-in displays it. - Change how drop-ins process and display data

Benefits:

• Fully supported by Adobe
• Automatic compatibility with updates
• Lower maintenance overhead
• Access to new features and bug fixes

SUBSTITUTE

Use SubstituteReplace an Adobe drop-in with a third-party implementation and own compatibility and maintenance responsibility. when you will put a third-party solutionAn external service or component used in place of a native Adobe drop-in implementation. in place of the Adobe drop-in for that part of the experience, so you own integration, updates, and API compatibility—not when you only need a contained integration (for example, a payment provider you wire in while still extending the Checkout drop-in).

Proceed with caution

If you substitute, you are responsible for keeping compatibility with Commerce APIs and keeping up with changes yourself.

Replace an Adobe drop-in with a full third-party solution if you have:

• Complete solutions from a single provider (not just payment methods)
• Specialized functionality that doesn’t align with Adobe’s approach
• Legacy system integration requirements
• Provider-specific workflows requiring their complete UI and logic

Risks and responsibilities:

• Maintenance burden - You own all updates, bug fixes, and compatibility
• API changes - Must adapt to Commerce API changes independently
• Feature gaps - May miss out on new Commerce features
• Support limitations - Adobe cannot provide support for third-party code

CREATE

The SDKThe Drop-in SDK used to build custom drop-ins and related integration logic. is what you use to CreateBuild a new drop-in from scratch when extension and substitution are not suitable for the required experience. a new drop-in package. Reserve that for cases where you need a whole new feature surface that the existing family of drop-ins does not cover, and you can commit to owning it over time.

Early access considerations

The drop-in SDK is in early access, with limited third-party support. Before you invest, contact Adobe to discuss your use case in the Discord Commerce Storefront channel .

Create a drop-in if you:

• Have a use case that no existing drop-in addresses
• Are building entirely new functionality for multiple storefronts or brands
• Have the resources and expertise for long-term maintenance

Boundaries and limitations

Drop-ins work best for certain types of functionality. Understanding these boundaries helps you choose the right approach:

Drop-ins excel at:

• Commerce-specific UI components (product displays, cart management, checkout flows)
• Data-driven interfaces that connect to Commerce APIs
• Reusable functionality across multiple storefronts
• Components that benefit from Commerce’s styling and theming system

Consider alternatives for these use cases:

• Simple static content (use HTML/CSS instead)
• Third-party integrations with existing UI (use vendor scripts)
• Highly merchant-specific logic (use application-level code)
• Temporary A/B testing variants (use feature flags)
• Single-use, non-reusable customizations

Need a new extension point?

If existing drop-ins don’t provide the slots or events you need:

1. Document your use case - Explain what you’re trying to achieve
2. Identify the gap - What specific slot or event is missing?
3. Submit a request - Share your requirements in the Discord Commerce Storefront channel

FAQs

Q: Why does Adobe recommend extending over building new drop-ins?
Extending is fully supported, maintains compatibility with updates, and reduces maintenance overhead. Most customization needs can be met through extension without the risks associated with building from scratch or substituting drop-ins.

Q: When is it acceptable to substitute a drop-in?
Substitution is acceptable when you need complete solutions from a single provider, have specialized functionality that doesn’t align with Adobe’s approach, need legacy system integration, or require provider-specific workflows with their complete UI and logic. However, you become responsible for maintaining compatibility with Commerce APIs and handling all updates independently.

Q: Is the drop-in SDK ready for production use?
No. The SDK is currently in early access with limited third-party support and no timeline for full support. Contact Adobe before investing in custom drop-in development.

Q: What extensibility options are available beyond slots?
While slots are the primary mechanism, you can also:

• Use configuration options to customize behavior
• Change how drop-ins look or behave (styling and layouts)
• Respond to drop-in events with custom logic
• Modify transformers to change how drop-ins process data

Q: How do I know if my use case requires a new drop-in?
Follow the decision flow in this guide. Most needs can be met by extending existing drop-ins. Only consider building new drop-ins if you have a use case that no existing drop-in addresses, are building entirely new functionality for multiple storefronts or brands, and have the resources and expertise for long-term maintenance.

Q: What happens if I substitute a drop-in and Commerce APIs change?
You’re responsible for updating your substitute to maintain compatibility. Adobe cannot provide support for third-party substitutes, and you may miss out on new features or security updates.