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.
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.
// 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.
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.
<!-- 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.
// 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.
# 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.