Blog Ecommerce 7 min read

Checkout Page Product Image Fallbacks

Prevent broken product images on checkout and order confirmation pages with fallback.pics URLs. Maintain trust at the highest-stakes point in the purchase funnel.

checkout product imageecommerce checkout fallbackorder confirmation imageproduct image fallbackconversion optimization
Checkout Page Product Image Fallbacks

The checkout page is the highest-trust moment in ecommerce. A broken image on the order summary, confirmation page, or receipt email does not just look bad — it raises a legitimate question about whether the transaction was processed correctly.

Checkout product images appear in at least three distinct surfaces: the order summary before payment, the confirmation page after payment, and transactional email receipts. Each surface has different constraints, but all benefit from the same fallback.pics URL pattern.

Stakes

Why checkout images need special attention

Cart pages get high traffic but moderate trust. Checkout pages get qualified traffic and maximum trust requirements. A broken image at checkout creates a moment of doubt that can abort a completed transaction: the user refreshes the confirmation page, contacts support, or simply distrusts the receipt.

Image failures at checkout often come from sources that work fine on the catalog page: CDN TTL mismatches, images that expire between cart-add and checkout completion, or vendor-supplied URLs that only work with a referrer.

Order summary

Product images in the pre-payment order summary

The order summary on a checkout page shows each line item with a thumbnail before the user submits payment. Images failing here create the most friction — users may remove items and restart.

Apply the same onerror fallback from your cart component here. If you use a shared component for line item images, one change covers both surfaces.

Implementation tsx
// Shared LineItemImage component – works in cart and checkout
const FALLBACK = 'https://fallback.pics/api/v1/square/80/7C3AED/FFFFFF?text=Item';

export function LineItemImage({ src, name }: { src?: string; name: string }) {
  return (
    <img
      src={src ?? FALLBACK}
      width={80}
      height={80}
      alt={name}
      onError={(e) => { e.currentTarget.src = FALLBACK; }}
    />
  );
}

Confirmation page

Order confirmation page: larger images, different CDN state

Confirmation pages often display larger product images (200–400px) and load them fresh from a different context than the checkout flow. If product images are served from a vendor CDN that uses signed URLs, the URL in your database might have expired by the time the confirmation page renders.

Serve the confirmation image from your own CDN or use the product permalink image rather than a signed temporary URL. For any case where the URL is unknown or potentially expired, default to a fallback.pics URL with the product name as text.

Implementation tsx
function ConfirmationLineItem({ item }: { item: OrderItem }) {
  const w = 200;
  const h = 200;
  const fallback =
    `https://fallback.pics/api/v1/square/${w}/7C3AED/FFFFFF?text=${encodeURIComponent(item.name.slice(0, 20))}`;

  return (
    <div class="order-item">
      <img
        src={item.permanentImageUrl ?? fallback}
        width={w}
        height={h}
        alt={item.name}
        onError={(e) => { e.currentTarget.src = fallback; }}
      />
      <div>
        <p>{item.name}</p>
        <p>Qty: {item.quantity}</p>
      </div>
    </div>
  );
}

Email receipts

Product images in transactional email

Email clients frequently block external images by default. Product images in order confirmation emails need to be hosted on a trusted domain, served over HTTPS, and sized explicitly in the HTML. Avoid signed or expiring URLs in email receipts — those URLs may be dead before the recipient opens the email.

fallback.pics URLs are permanent and deterministic. Embed the product name in the text parameter so the image is useful even when email images are blocked, and set explicit width/height for email clients that size images from HTML attributes.

Implementation text
<!-- Order confirmation email HTML -->
<img
  src="{{ product.permanent_image_url | default: 'https://fallback.pics/api/v1/square/100/7C3AED/FFFFFF?text=' | append: product.name | url_encode }}"
  width="100"
  height="100"
  alt="{{ product.name }}"
  style="display:block;border:0;outline:none;"
/>

Returns and refunds

Image fallbacks in return and refund flows

Return and refund interfaces often load product images from order history data that may be months old. Images from suppliers may have been removed or relocated since the original purchase.

Store a snapshot of the product image URL at order creation time and use a fallback.pics URL as the default for any order where the image field is empty or points to a known-bad source.

Implementation tsx
// At order creation: store a fallback alongside the product image
const orderItem = {
  productId: item.id,
  name: item.name,
  imageUrl: item.imageUrl,
  imageFallbackUrl: `https://fallback.pics/api/v1/square/120/7C3AED/FFFFFF?text=${encodeURIComponent(item.name.slice(0, 20))}`,
};

Further reading

Connecting cart, checkout, and confirmation fallbacks

Cart, checkout, and confirmation are one funnel. A shared line item image component with consistent fallback logic covers all three. Apply the pattern once and it propagates across the entire post-cart experience.

Implementation text
# https://fallback.pics/docs/
# https://fallback.pics/placeholder-image-api/
# https://fallback.pics/blog/cart-thumbnail-image-fallback/
# https://fallback.pics/blog/product-image-placeholder-ecommerce-catalogs/

Key takeaways

What to standardize before shipping

  • Checkout images carry more trust weight than catalog images — fix them first.
  • Use permanent product image URLs in receipts, not signed or expiring CDN links.
  • A shared LineItemImage component with onerror covers cart, checkout, and confirmation.
  • Store a fallback URL at order-creation time for return and refund flows.
  • Email-safe product images need explicit width, height, and HTTPS URLs that do not expire.

Production fallback layer

Use fallback.pics anywhere an image URL is accepted.

Start with one deterministic URL and standardize fallback behavior across your design system.

Read the docs