# shopping Published articles for shopping. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Authentication made easy: Building a secure e-commerce shopping cart with Firebase DevFeed: [Authentication made easy: Building a secure e-commerce shopping cart with Firebase]() Original publisher: [Read original article]() Author: Karl Weinmeister Published: 2026-09-01T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Authentication](), [Firebase](), [Firestore](), [Authorization](), [Security]() Tags: [authentication](), [cloud-run](), [e-commerce](), [firebase](), [firestore](), [security-rules](), [shopping](), [tutorials](), [web]() ### AI overview This tutorial explains how to build a secure e-commerce shopping cart with Firebase Authentication and Cloud Firestore. It covers guest onboarding through anonymous authentication, migration of guest carts to permanent accounts, real-time synchronization, and checkout while addressing database permissions and security. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Securing Agentic Commerce DevFeed: [Securing Agentic Commerce]() Original publisher: [Read original article]() Author: Bradford Peirce Published: 2026-08-31T17:22:00Z Content type: article Language: en Sources: [Auth0 Blog]() Topics: [Artificial Intelligence](), [Authorization](), [Large Language Model]() Tags: [agentic](), [ai](), [authorization](), [identity](), [shopping]() ### AI overview The article explains how AI-driven shopping is developing into agentic commerce, from product discovery toward purchases completed within chat interfaces and delegated buying. It argues that identity verification, authorization, and fraud prevention are necessary for secure transactions involving third-party AI agents. ### Source excerpt Identity as the Foundation of the World's Newest Shopping Channel. ## How Razorpay Built a Customer Data Platform for Queryable Segments at Scale DevFeed: [How Razorpay Built a Customer Data Platform for Queryable Segments at Scale]() Original publisher: [Read original article]() Author: Varun Meka Published: 2026-06-26T08:06:33Z Content type: article Language: en Sources: [Razorpay Engineering - Medium]() Topics: [data](), [Transactions](), [App](), [systems](), [Apache Spark]() Tags: [app](), [banking](), [card](), [customer](), [data](), [devices](), [engineering](), [payments](), [platform](), [razorpay](), [saas](), [scale](), [shopping](), [transactions]() ### AI overview Razorpay describes building an in-house Customer Data Platform to unify fragmented customer and transaction data into queryable audience segments. The supplied excerpt says the platform serves segments across more than 500 million user profiles in under 30 milliseconds while keeping personally identifiable information isolated in source systems. ### Source excerpt Turning Scattered Data Into Queryable Segments at Scale: How Razorpay Built Its Customer Data Platform A consent-native CDP that serves audience segments across 500M+ user profiles in under 30ms, with PII isolated to the source systems. The Problem We Were Solving A customer opens her favourite online shopping app, adds a few items to her cart, and pays INR 1,200 via UPI, powered invisibly by Razorpay. A week later she returns and pays using a saved Visa card from her laptop. Later that month, she places a larger INR 8,500 order through net banking from work. Three transactions. Three different payment instruments. Three different devices. To the merchant's engineering team, and to Razorpay's data systems, these could look like three completely different people, unless you've done the hard work of figuring out they're all the same customer. Now suppose this is a D2C fashion brand approaching their Diwali sale. The merchant's growth team has a clear plan: "Identify customers who have transacted at least once in the last 30 days, have spent more than INR 5,000 cumulatively this quarter, and haven't enrolled in our loyalty programme. Send them an early-access nudge with a personalized discount 48 hours before the public sale opens." A year ago, answering that question at Razorpay meant filing a cross-team data request, waiting for an analyst to write a custom Spark job, and getting an answer in 2-3 days. By the time the merchant had the segment, the Diwali sale was already live. The early-access window had closed. The campaign got sent to a broader, less-targeted audience, wasting spend on customers who would have bought anyway and leaving cold customers untouched. Now multiply that pain by millions of merchants. Razorpay powers payments and growth for over 12 million merchants. From D2C fashion brands and SaaS startups to subscription platforms, ed-tech companies, and the 2 million+ local merchants accepting QR payments every day. Together, they process billions of transaction ## Open rails for agentic commerce at Open Source Summit North America 2026 DevFeed: [Open rails for agentic commerce at Open Source Summit North America 2026]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-16T23:16:03Z Content type: opinion Language: en Sources: [Google Open Source Blog]() Topics: [Artificial Intelligence](), [Open Source](), [systems](), [Protocol (disambiguation)]() Tags: [2026](), [agentic](), [agentic-commerce](), [ai](), [ai-agents](), [business](), [capabilities](), [checkout](), [consumer](), [e-commerce](), [features](), [fragmentation](), [integration](), [interoperability](), [open-source](), [open-standards](), [payment](), [platforms](), [shopping](), [standard](), [ucp](), [universal-commerce-protocol](), [workflows]() ### AI overview An article from Open Source Summit North America 2026 explains why agentic commerce may require shared, open rules and integrations. It presents Universal Commerce Protocol (UCP) as an open standard intended to let agents, businesses, consumer surfaces, and payment providers work together across shopping, checkout, fulfillment, and post-purchase flows. ### Source excerpt by Anurag Sinha, Universal Commerce Protocol (UCP) At Open Source Summit North America 2026, I shared why agentic commerce needs open rails. As AI agents become more capable, the shopping journey is shifting from "show me" to "help me." Instead of browsing, comparing, clicking, and checking out step by step, people can increasingly ask an agent to help them decide what to buy and, in some cases, complete the purchase. Industry forecasts suggest agentic shopping could account for roughly 10% to 25% of U.S. e-commerce by 2030 (Bain), which points to a meaningful shift in how digital commerce will work. Watch the full keynote here. Why shared rules matter That shift also exposes a challenge. Commerce is still highly fragmented. Different businesses, payment providers, and platforms operate with their own rules, workflows, and business logic. Every new surface adds more integration work. Every bespoke connection creates more complexity. And that fragmentation makes it harder for AI systems to understand and perform commerce actions consistently across businesses. A shared language lowers that barrier for everyone. A common language for agentic commerce That is the problem Universal Commerce Protocol (UCP) is designed to solve. We launched the Universal Commerce Protocol, or UCP, with industry leaders to establish an open standard for agentic commerce, built to work across the shopping journey. UCP creates a common language for agents and systems to operate together across consumer surfaces, businesses, and payment providers, so the ecosystem does not need a different bespoke integration for every new agent or platform. Just as importantly, UCP is designed for the real world. Every business has its own way of selling. Checkout, fulfillment, loyalty, policy logic, shipping, and post-purchase flows can vary widely between a local shop, a marketplace, and a large retailer. UCP is built to support that reality. A layered architecture for a shared commerce language UCP uses a ## Apparel & Accessories Quantitative UX: 3 High-Level Takeaways from 40+ Charts DevFeed: [Apparel & Accessories Quantitative UX: 3 High-Level Takeaways from 40+ Charts]() Original publisher: [Read original article]() Author: Niel Gan Published: 2026-06-12T08:02:00Z Content type: article Language: en Sources: [Baymard Institute]() Topics: [User experience (UX)](), [data](), [benchmarking]() Tags: [article](), [benchmarking](), [customer](), [data](), [ecommerce](), [online-shopping](), [research](), [reviews](), [shopping](), [survey](), [ux]() ### AI overview This quantitative UX study examines apparel and accessories shoppers' habits and preferences using survey data from 1,922 US online shoppers. It presents more than 40 insights on topics including sizing and fit confidence, product-page evaluation, reviews, returns, loyalty programs, and delivery expectations. The article highlights uncertainty throughout the shopping journey, including mismatches between shoppers' self-reported sizes and industry definitions, infrequent shopping as a barrier to loyalty enrollment, and reviews serving as a proxy for fit evaluation. ### Source excerpt (Note: Unfortunately, e-mail and RSS don't support advanced layouts and features. If the graphics in this article look strange, you may want to read the article in your web browser.) Key Stats & Takeaways 40+ new insights on Apparel & Accessories shopper habits and preferences 1,922 US online shoppers surveyed in this quantitative UX study Apparel and accessories shoppers face uncertainty at every stage of their journey, from how their self-identification corresponds to retailer categories to how they evaluate fit on the product page We've released new Quantitative Insights into people who shop on "Apparel & Accessories" sites, adding to our growing body of data on the habits and preferences of online shoppers across key ecommerce categories. These insights are survey-based data visualizations that complement and deepen our large-scale UX research findings and benchmarking of the Apparel & Accessories industry. The 40+ insights cover the Apparel & Accessories online shopping experience across a wide range of topics: online trip drivers, size and fit confidence, product page evaluation, reviews usage, returns, loyalty programs, and delivery expectations. Apparel and accessories shoppers make decisions with incomplete information at every stage of their online journey. They can't feel a fabric, try out a fit, or know whether a size label will translate to their body. Beyond that, they may not know whether the items they buy will ultimately feel "worth it" to them, or whether they'll shop frequently enough to make a rewards program worth joining. Each of these uncertainties plays out at a different stage of the journey, and each has distinct implications for how Apparel & Accessories sites should be designed. In this article, we'll highlight 3 high-level findings that reflect how apparel and accessories shoppers navigate that uncertainty: Shoppers' self-reported size categories often diverge from industry definitions Infrequent shopping, not program design, is the top ## From Products to Inspiration: Inside the Engine of Occasion-based outfit visualiser DevFeed: [From Products to Inspiration: Inside the Engine of Occasion-based outfit visualiser]() Original publisher: [Read original article]() Author: Ankit Kumar Published: 2026-04-23T18:23:51Z Content type: article Language: en Sources: [Myntra]() Topics: [Data Science](), [Computer vision](), [Generative AI](), [JSON]() Tags: [ai](), [computer-vision](), [data-science](), [drapes](), [generative-ai](), [json](), [occasion-based-shopping](), [outfit-ideas](), [product](), [shopping]() ### AI overview This article describes how Myntra built its Looks occasion-based outfit visualiser. The feature combines fashion intelligence, data science, computer vision, generative AI, and JSON-based outfit rules to turn individual product images into coordinated outfit recommendations and visualisations. The supplied text details its style taxonomy and curation of over a million styles, but the article is truncated before the visualisation implementation is fully explained. ### Source excerpt Ankit Kumar | Oct 2025 - 6 min read The "Why": Moving Beyond the Grid Picture this: A white background. A shirt. Fabric details. Fit specs. A price tag. For decades, this has been the status quo of online shopping. It is clinical, clear, and -- let's be honest -- completely detached from real life. In this model, the customer does all the heavy lifting. "Where would I wear this?" they wonder. "Does this go with those beige chinos I bought last year?" They close their eyes. They imagine. They guess. Sometimes they buy; often, they bounce. Traditional Product Detail Page (PDP) recommendations tried to help by suggesting jeans to pair with shirts. But the truth is, they remained a list of ingredients, not a prepared meal. At Myntra, we decided to change that. We set out to build Looks, a feature designed to transport a static product into a lived experience -- a Friday night in Bangalore, a high-intensity gym in Gurgaon, or a quiet art gallery in Mumbai. This is the story of how we orchestrated Data Science, Computer Vision, and Generative AI to build a personal stylist that scales to millions. Phase 1: The Brain -- Orchestrating the Look Before we could visualize an outfit, we had to understand fashion. Not just as data points, but as a language. This required Fashion Intelligence: a system that knows what works, what doesn't, and why. Our Data Science team undertook a massive curation effort, analyzing over a million styles. They didn't just tag clothes; they mapped them to the "cascading tree of style." For every Primary Style (e.g., a Polo shirt), the engine identifies four critical layers: The Occasion: (Weekend Outing, Office Smart-Casual) Secondary Style: (The bottom wear) Tertiary Style: (Footwear) Tertiary (others) : (Accessories like watches or sunglasses) The Recipe in the Code The logic is powered by a JSON structure that acts as the "AI Stylist's" brain: JSON "29936239": [ { "Weekend outing": [ [ 29936239, // Primary: The Polo T-Shirt 33551732, // Secondary: B ## Instacart and OpenAI partner on AI shopping experiences DevFeed: [Instacart and OpenAI partner on AI shopping experiences]() Original publisher: [Read original article]() Published: 2025-12-08T06:00:00Z Content type: news Language: en Sources: [OpenAI News]() Topics: [ChatGPT](), [OpenAI](), [Artificial Intelligence](), [App](), [Protocol (disambiguation)](), [real-time]() Tags: [agentic](), [ai](), [app](), [chatgpt](), [checkout](), [global-affairs](), [instacart](), [integration](), [models](), [openai](), [partner](), [partnership](), [payment](), [real-time](), [shopping]() ### AI overview OpenAI and Instacart are expanding their partnership with a fully integrated grocery-shopping and Instant Checkout experience in ChatGPT. Users can receive meal and grocery suggestions, build a cart using OpenAI models, and complete payment through the Instacart app without leaving the conversation. ### Source excerpt OpenAI and Instacart are deepening their longstanding partnership by bringing the first fully integrated grocery shopping and Instant Checkout payment app to ChatGPT. ## OpenAI and Target team up on new AI-powered experiences DevFeed: [OpenAI and Target team up on new AI-powered experiences]() Original publisher: [Read original article]() Published: 2025-11-19T06:00:00Z Content type: news Language: en Sources: [OpenAI News]() Topics: [OpenAI](), [ChatGPT](), [Artificial Intelligence](), [App](), [data]() Tags: [agent](), [ai](), [apis](), [app](), [chatgpt](), [checkout](), [company](), [enterprise](), [models](), [openai](), [productivity](), [shopping]() ### AI overview OpenAI and Target are expanding their partnership with a new Target app in ChatGPT for personalized recommendations, multi-item shopping carts, and checkout through Drive Up, Order Pickup, or shipping. Target is also using OpenAI APIs and ChatGPT Enterprise to improve employee productivity and guest experiences. ### Source excerpt OpenAI and Target are partnering to bring a new Target app to ChatGPT, offering personalized shopping and faster checkout. Target will also expand its use of ChatGPT Enterprise to boost productivity and guest experiences. ## Astro 5.7 DevFeed: [Astro 5.7]() Original publisher: [Read original article]() Author: Matt Kane; Florian Lefebvre; Emanuele Stoppa; Nate Moore Published: 2025-04-15T00:00:00Z Content type: release Language: en Sources: [The Astro Blog]() Topics: [Astro](), [API](), [Font](), [SVG](), [Core Web Vitals]() Tags: [api](), [astro](), [components](), [core-web-vitals](), [experimental](), [fonts](), [google](), [performance](), [shopping](), [state](), [svg](), [web-apis]() ### AI overview Astro 5.7 introduces stable Sessions and SVG components, plus an experimental Fonts API. The Fonts API supports local fonts and built-in providers with automatic optimizations, while Sessions securely store server-side user data across Astro features. ### Source excerpt Astro 5.7 has a basketload of treats, including stable Sessions and SVG components and a new Experimental Fonts API. ## Create a shopping cart using Qwik and Turso DevFeed: [Create a shopping cart using Qwik and Turso]() Original publisher: [Read original article]() Author: James Sinkala Published: 2023-04-27T00:00:00Z Content type: tutorial Language: en Sources: [Turso Blog]() Topics: [Qwik](), [Turso](), [Web]() Tags: [framework](), [how-to](), [integration](), [qwik](), [shopping](), [turso](), [web](), [web-development]() ### AI overview A tutorial on creating a web shopping cart with the Qwik framework and Turso. The source notes that the post references an older version of Turso. ### Source excerpt Learn how to create a robust shopping cart for the web using the Qwik framework and Turso, the edge database. ## Back to basics: Navigation DevFeed: [Back to basics: Navigation]() Original publisher: [Read original article]() Author: Niek Haarman Published: 2018-10-25T09:12:40Z Content type: tutorial Language: en Sources: [Stories by Niek Haarman on Medium]() Topics: [navigation](), [Android](), [Mobile](), [Development]() Tags: [android](), [android-app-development](), [android-development](), [androiddev](), [development](), [flow](), [fragments](), [login](), [mobile](), [navigation](), [onboarding](), [payment](), [screen](), [shopping](), [state]() ### AI overview A fundamentals-focused guide to in-app navigation in Android applications. It explains the back stack, reusable navigation flows, conditional paths based on user state, and how navigation responsibilities are handled by Activities and Fragments. ### Source excerpt Previously I talked about the unfortunate design of the Activity class, and I went back to basics regarding screens in an application. This time, we're going back to basics regarding in-app navigation. What is meant by 'navigation'? In a typical mobile application, a user can navigate from one screen to another. Traveling through an application builds up a navigational state; in Android this is traditionally done with a back stack. Activities can start new Activities which get pushed upon a stack. When the user presses back, the top Activity gets popped off the stack, to reveal the previous Activity. You can modify how Activities are created and pushed upon the stack with several flags and attributes, which are described at length on the Understand Tasks and Back Stack page. The back stackFlows In a non-trivial application, there are often multiple 'flows' that can be defined: there might be a login flow, an onboarding flow, or a flow that takes you through a payment process. In the latter case, you might have a series of screens that start with a description of the user's shopping cart, followed by forms to enter shipping and payment information. Such flows are usually completely self contained, and can be reused when necessary. It may be possible to start a specific flow from anywhere in the app, allowing for dozens of paths through your application to exist. An example payment flow for a shopping application.Conditional navigation In your typical application, there is no strict sequence of screens that will appear in a fixed order. Depending on user input, the user can travel through different paths through your application. A dashboard screen for example can have multiple buttons that all lead the user to a different screen. Another thing to consider is that the next state of the navigation state is dependent on the some conditional state. If the user already has entered shipping and payment info a previous time, we may want to skip these forms and go straight t ## Restaurant App Builder DevFeed: [Restaurant App Builder]() Original publisher: [Read original article]() Author: Shai Almog Published: 2017-06-13T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [app builder](), [App](), [Tutorial](), [Bootcamp]() Tags: [app](), [app-builder](), [billing](), [courses](), [generate](), [native](), [shopping](), [tutorial]() ### AI overview The article introduces a restaurant ordering app and an app builder created during a bootcamp. The builder lets users customize the ordering app for a specific restaurant and generate a native app. The author presents a soft launch, invites feedback from restaurant owners, and describes plans for further development and course material. ### Source excerpt In the bootcamp we didn't build just one big app, we built two... Or infinity... The first app was a restaurant ordering system that allows you to pick dishes from a menu and add them to a shopping cart. The second app was an "app builder" that allows you to customize the first app and then generate a native app based on that for your specific restaurant. I kept that under wraps because I wanted to do a big "launch" and release the app to the wild based on that but I ended up being so busy after the bootcamp completed that this just didn't materialize. So instead of doing a big launch I'm doing the softest possible launch for this app. This is how the restaurant app looks, I cover its creation in the upcoming courses too: ## Reactive Apps with Model-View-Intent - Part 4: Independent UI Components DevFeed: [Reactive Apps with Model-View-Intent - Part 4: Independent UI Components]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-02-25T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [reactive](), [ui](), [App](), [Code]() Tags: [blog](), [design-patterns](), [flow](), [recyclerview](), [shopping](), [toolbar](), [ui-components](), [viewmodel]() ### AI overview This blog post discusses building independent, reusable UI components in reactive application architectures such as Model-View-Intent, Model-View-Presenter, and Model-View-ViewModel. It argues that presenters should communicate indirectly by observing shared business logic and describes this approach using a shopping-basket example. ### Source excerpt In this blog post we will discuss how to build independent UI components and clarify why Parent-Child relations are a code smell in my opinion. Furthermore, we will discuss why I think such relations are needless. One question that arises from time to time with architectural design patterns such as Model-View-Intent, Model-View-Presenter or Model-View-ViewModel is how do Presenters (or ViewModels) communicate with each other? ## On Aggregates and Domain Service interaction DevFeed: [On Aggregates and Domain Service interaction]() Original publisher: [Read original article]() Published: 2017-01-25T00:00:00Z Content type: tutorial Language: en Sources: [Marco Pivetta]() Topics: [Object-relational mapping](), [Code](), [Dependency injection](), [API](), [App](), [Databases]() Tags: [api](), [architecture](), [code](), [dependency-injection](), [frontend](), [orm](), [payment](), [shopping]() ### AI overview This article examines where to place I/O and domain-specific validation when working with aggregates in CQRS, event-sourced architectures, and imperative ORM entity code. Using a shopping-cart payment example, it discusses commands, aggregates, command handlers, guards, dependency injection, and the problem of moving business rules into application-layer handlers. ### Source excerpt Some time ago, I was asked where I put I/O operations when dealing with aggregates. The context was a CQRS and Event Sourced architecture, but in general, the approach that I prefer also applies to most imperative ORM entity code (assuming a proper data-mapper is involved). Scenario Let's use a practical example: Feature: credit card payment for a shopping cart checkout Scenario: a user must be able to check out a shopping cart Given the user has added some products to their shopping cart When the user checks out the shopping cart with their credit card Then the user was charged for the shopping cart total price Scenario: a user must not be able to check out an empty shopping cart When the user checks out the shopping cart with their credit card Then the user was not charged Scenario: a user cannot check out an already purchased shopping cart Given the user has added some products to their shopping cart And the user has checked out the shopping cart with their credit card When the user checks out the shopping cart with their credit card Then the user was not charged The scenario is quite generic, but you should be able to see what the application is supposed to do. An initial implementation I will take an imperative command + domain-events approach, but we don't need to dig into the patterns behind it, as it is quite simple. We are looking at a command like following: final class CheckOutShoppingCart { public static function from( CreditCardCharge $charge, ShoppingCartId $shoppingCart ) : self { // ... } public function charge() : CreditCardCharge { /* ... */ } public function shoppingCart() : ShoppingCartId { /* ... */ } } If you are unfamiliar with what a command is, it is just the object that our frontend or API throws at our actual application logic. Then there is an aggregate performing the actual domain logic work: final class ShoppingCart { // ... public function checkOut(CapturedCreditCardCharge $charge) : void { $this->charge = $charge; $this->raisedEvents[ ## How We're Thinking About Commerce and VR With Our First VR App, Thread Studio DevFeed: [How We're Thinking About Commerce and VR With Our First VR App, Thread Studio]() Original publisher: [Read original article]() Author: Daniel Beauchamp Published: 2016-09-29T17:00:00Z Content type: opinion Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [Shopify](), [Virtual reality](), [App]() Tags: [platform](), [products](), [retail](), [shopify](), [shopping](), [storytelling]() ### AI overview Shopify describes how virtual reality could support commerce through immersive product storytelling, spatial visualization, and merchant workflows. The article introduces Thread Studio, a VR app for arranging T-shirt designs on mannequins and producing print-ready files or opening a Shopify store. ### Source excerpt 3 minute read Hey everyone! I'm Daniel and I lead our VR efforts at Shopify. When I talk to people about VR and commerce, the first idea that usually pops into their heads is about all the possibilities of walking around a virtual shopping mall. While that could be an enjoyable experience for some, I find it's a very limiting view of how virtual reality can actually improve retail. If VR gave you the superpowers to do anything, create anything, and go anywhere you want, would you really want to go shopping in a regular mall?More than a virtual mall It's easy to take a new medium and try to shoehorn in what already exists and is familiar. What's hard is figuring out what content makes the medium truly shine and worthwhile to use. VR offers an amazing storytelling platform for brands. For the first time, brands can put people in the stories that their products tell. If you're selling scuba gear, why not show what it'd look like underwater with jellyfish passing by? Or a tent on a windy, chilly cliff, reflecting the light of a scrappy fire? It sure would beat being in a fluorescent-lit camping store. In VR, you could explore inside a tent before you buy it, or change the environment around you at a press of a button. ## Square Menu Embed v2 Adds Shopping Basket Support DevFeed: [Square Menu Embed v2 Adds Shopping Basket Support]() Original publisher: [Read original article]() Author: Square Engineering Published: 2014-08-07T16:07:00Z Content type: release Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Website](), [browser]() Tags: [checkout](), [customers](), [embedded](), [engineering](), [modal](), [release](), [sales](), [shopping]() ### AI overview Square's Menu Embed v2 adds shopping basket support, responsive item modals, and an embedded cart so customers can customize, review, and purchase multiple items without leaving a seller's website. ### Source excerpt Our interactive menu embeds now turn your website into an online store ## Advanced Embedding with Square Market DevFeed: [Advanced Embedding with Square Market]() Original publisher: [Read original article]() Author: Square Engineering Published: 2014-07-09T16:07:00Z Content type: tutorial Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Website](), [Web Components](), [HTML](), [browsers]() Tags: [browsers](), [components](), [embedded](), [engineering](), [html](), [self-service](), [shopping](), [widget]() ### AI overview Square Market describes how it developed an embeddable interactive menu for business websites. The article compares injecting HTML, using a web component, and using an iframe, ultimately choosing an iframe because browser support for web components was considered insufficient. ### Source excerpt Ember an interactive menu into your website using Square Market.