Extend, substitute, or create?

Commerce drop-ins offer three customization approaches. Extending existing drop-ins is the recommended and fully supported path. Substituting drop-ins with third-party solutions is sometimes necessary due to drop-ins’ composable architecture. Creating new drop-ins with the Drop-in SDK (currently early access) is also possible. This guide helps you choose the right approach.

Vocabulary

Extend

Modify or enhance existing drop-ins using slots, styling, events, or configuration. This is the recommended and fully supported approach.

Substitute

Replace an Adobe drop-in entirely with a third-party solution (like using Stripe for checkout). This comes with maintenance responsibilities and compatibility risks.

Create

Build a brand-new drop-in from scratch using the SDK. Currently in early access with limited third-party support.

Configuration

Settings and options that customize drop-in behavior without changing core functionality.

Styling

Override CSS, modify layouts, and replace visual components to change how drop-ins appear without altering their core functionality.

Slots

Declarative anchors where custom UI content can be injected into a drop-in.

Events

Data events that drop-ins emit, allowing you to listen and add custom behavior.

Transformers

Modify how drop-ins process and display data from Commerce APIs.

SDK (Drop-in SDK)

Software Development Kit for building custom drop-ins from scratch (currently in early access).

Third-party solution

External service or component that replaces an Adobe drop-in (for example, Stripe for checkout).

Choose your approach

EXTEND

Recommended approach

Most customization needs can be met through slots, styling, events, and transformers without the complexity and maintenance burden of substitution or creation.

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:

• Slots - Inject custom HTML/components at predefined points
• Styling - Override CSS, modify layouts, replace components
• Events - Listen to data events and add custom behavior
• Configuration - Modify drop-in settings and options
• Transformers - 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

Proceed with caution

Substitution means you’re responsible for maintaining compatibility with Commerce APIs and handling all future updates yourself.

Replace an Adobe drop-in with a 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

Early access considerations

The drop-in SDK is in early access with limited third-party support.

Before building: Contact Adobe to discuss your use case using 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.