6

I have a shopping cart I want to embed in a widget/iframe on other users sites, I see three ways of doing this each with drawbacks. Here are options from estimated most to least work.

  1. Recreate interactive shopping cart UI in javascript widget then pass values to server script with AJAX, variables are passed to the main site, when user clicks "checkout" the user is then redirected to main shopping cart site with variables populated from what the entered in the widget.

    • pros: complete experience
    • cons: most work to complete creating UI and AJAX request.

  2. Somehow detect if user is coming to shopping cart via iframe, if this is the case have alternate code that opens new window when user clicks "checkout" redirecting user to secure page and getting variables from cart via AJAX to populate final checkout.

    • pros: mid amount of work, must do AJAX request to get variables from shopping cart to populate final checkout
    • cons: can we easily detect if site is being accessed from a user within an iframe on another site?

  3. complete entire checkout process inside iframe/widget.

    • pros: least ammount of work, just embed cart in iframe
    • cons: will not show https in browser user may be reluctant to purchase

What is the best option?

j0k
  • 22,600
  • 28
  • 79
  • 90
Alex Borsody
  • 1,908
  • 9
  • 40
  • 74

3 Answers3

4

If you could provide a bit more information, maybe I could offer you an even better option. For starters, what have you built this application with (languages/framework)? Also, would you say your application's functionality is similar to Shopify's in that you allow users to host e-commerce sites through your service? If not, tell us a bit more about your application.

Here's a quick response to the options you provided.

option 1: the only real option as I see it. Whether you're embedding the shopping cart in specifically an iframe or rendering it onto the user's page as part of a template, you should be navigating the customer away to your main site to complete the checkout process. Or at least give them a lot of screen real-estate to work with (a sizable modal for example).

option 2: is messy. You can tell if a request is coming from a remote form (like an iframe) by appending url parameters. But taking the approach you're suggesting with this doesn't make too much sense.

option 3: too heavy unless you take a modal-approach like what I mentioned in response to option 1.

That being said, if you are building an application like Shopify, you should be able to build a template for each user's website that has a section dedicated to displaying a shopping cart pertaining to the current customer's session. No iframes or widgets necessary with this approach. But again, it all depends on the use cases of your application.

anxiety
  • 1,689
  • 16
  • 25
  • This is going to be one store we are displaying through a widget for a promotion. We are not building an app like shopify – Alex Borsody Aug 27 '12 at 15:51
  • Nothing has been built yet for this widget. – Alex Borsody Aug 27 '12 at 15:57
  • Then I'd recommend either option 1 or 3. However, consider the complications of dealing with your payment gateway exclusively through a widget. Because of that, I'd still say option 1 is the way to go. Is there anything else you wanted some clarification on? – anxiety Aug 27 '12 at 19:32
3

If your only concern with Option 2 is detecting if your content is being loaded within an iframe, you can do that with JavaScript by using "top.frames.length" or "top === self."

For example, you could show or hide different conditional form content, or a different submit button, using the following:

if (top.frames.length == 0) {
    // Show content if not embedded in an iframe.
    document.getElementById('embedded-content').style.display = "none";
    document.getElementById('unembedded-content').style.display = "block";
}
else {
    // Show content if embedded in an iframe.
    document.getElementById('embedded-content').style.display = "block";
    document.getElementById('unembedded-content').style.display = "none";
}
Community
  • 1
  • 1
Mac
  • 1,201
  • 2
  • 15
  • 28
2

As you've stated, the first option is the best in terms of user experience and the most likely to achieve the highest possible conversions. How much better the conversion is compared to the next best solution cannot be objectively measured, as it involves recurring customers, your own brand name, the kind of products, etc. Since the conversion rates will directly affect you (and your company), it's wise to make an estimate first to see if your efforts spent will be worth it in the short and long term.

The second option is the sweet middle ground; you still get brand recognition and customers will have some security reassurance (via address bar); (i)frame detection is easily done by a simple JavaScript comparison: top === window. However, you're losing the continuity and hence likely lose some conversion. If this risk is manageable, I'd go for this option in the short term.

Not being able to see the security certificate directly via the green lock makes the third option the least desirable. However, not all is lost; by clever use of imagery you can still gain some trust with your end-user, as outlined in this image, which is part of a great article from Smashing Magazine.

Your decision should be based on:

  1. what can be done in the short term
  2. what should be done in the long term
  3. how important is secure visual cues to my potential customer
  4. time / money spent on either solution versus revenues (break-even analysis)
Ja͢ck
  • 170,779
  • 38
  • 263
  • 309