Post-purchase is the surface with the biggest gap between "what it looks like" and "what it technically is." It renders between payment confirmation and the order-status page, so it feels like part of checkout, but accepting the offer creates no second checkout flow for the shopper — the charge is applied to the payment method already authorized, which is also exactly why this is the most constrained context on the matrix. Because the order is mid-authorization rather than finished, the post-purchase SDK only allows standard and swap behavior; auto-add and mix & match aren't available because they'd mean mutating an order that's actively being finalized in ways the SDK doesn't support. The same constraint rules out carousel layouts and button-width control, and styling uses semantic color tokens rather than hex, same as checkout.
Two details worth knowing before relying on this surface: not every payment method can trigger a post-purchase offer (some payment flows finalize the order before the post-purchase step would run), and because it's tied to payment authorization rather than a page load, debugging a post-purchase offer that isn't appearing usually starts with checking the payment method used on the test order, not the offer's Smart Rules.