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.
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.
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.
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
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).
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
A substituted drop-in no longer emits the ACDL events that analytics, personalization, product recommendations, and Live Search rely on. You’ll need to publish those events yourself:
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.
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
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.