In-Ad Checkout
The full checkout — line items, address, payment, confirmation — renders inside the ad creative footprint. Used for in-feed shoppable ads on platforms that support interactive ad units.
When this fits
| Condition | Does this pattern fit? |
|---|---|
| Ad surface supports interactive elements (clickable forms, payment widgets inside the creative) | ✅ Yes |
| Mobile feed (social, video, content discovery) | ✅ Yes — wallet payment shortens checkout dramatically |
| Static display ad (no in-creative interactivity) | ❌ No — use Post-Click Landing |
| Connected-TV ad (limited remote-control input) | ❌ No — use Post-Click Landing |
Real-estate constraints
In-ad checkout has limited space. Design choices:
- Single-screen flow — address, payment, and confirmation in one scrollable view
- Wallet-first payment — Google Pay button at the top of the checkout panel; card-via-JWE is a secondary option
- Pre-filled address — wallet flows auto-fill name, address, email; viewer just confirms
- No multi-step navigation — back/forward states inside an ad creative confuse the viewer; keep the flow linear
What the destination owns
| Layer | Owner |
|---|---|
| Ad creative rendering (HTML/JS or platform-specific format) | Destination |
| In-ad checkout UI (form fields, wallet button, confirmation message) | Destination |
| Cart / order orchestration | Firmly APIs |
| Payment encryption + processing | Firmly APIs |
| Order placement at merchant | Firmly APIs |
| Conversion postback to ad platform | Destination (after order success) |
Constraints to plan for
- Ad platform inspection. Some ad platforms periodically inspect creative behavior. If your creative makes outbound HTTP requests (Firmly API calls) at impression time rather than at click time, the platform may flag the creative. Always make the first API call (
POST /browser-session) on viewer interaction, not on impression. - Sandboxed JS environments. Some ad platforms run creatives in restricted iframes (no cookies, limited storage). Make sure your auth bootstrap doesn’t depend on cross-origin cookies — Firmly’s browser session works in restricted contexts.
- Limited error surfacing. If
complete-orderfails, you have minimal space to show the viewer a recovery option. Default to a single, clear message (“Payment couldn’t process. Try a different card or click here for full checkout”) with a fallback CTA to the Post-Click Landing.
Related
- In-Feed Shoppable Ad use case
- Single Product Purchase Flow
- Post-Click Landing — the alternative pattern