A one-tap checkout widget merchants can drop into a product page or cart, with enough theming to still look like theirs.
Our clients wanted express checkout on the product page, but integrating it meant touching the checkout funnel. Four client interviews surfaced the same blocker. With the PM, we scoped a first version we could ship in two weeks, design and code included: a widget ready to drop onto a product page.
Merchants wanted a quick-buy button straight from the product page or the cart. In practice, wiring that into an existing storefront meant touching the checkout, and that is the one part of an ecommerce site nobody wants to rebuild.
Integrating a fast purchase from a product page or cart was too complicated to be worth it for most merchants.
Four clients interviewed, the same blocker four times: express checkout meant touching the checkout funnel, so a development project.
The existing flow broken down step by step, to remove what could go without losing the shopper’s trust.
One component that behaves the same on a product page, a cart and on mobile.
A limited set of exposed tokens so the widget safely takes on the merchant’s identity.
What scope for the first version?
With the PM, we limited V1 to the essentials: the widget, express payment and token customisation. Enough to prove the value on real merchants before going further.
What settled it: the company strategy, simplifying the buying experience, and the same blocker at all four interviewed clients.
Not this: A months-long project covering every integration case, before any measurement.
How much freedom should merchants get?
Merchants change colours, corner radius and type scale. Layout, spacing and payment states stay ours.
What settled it: layout and payment states carry trust and compliance; colours carry the brand.
Not this: Full CSS freedom. It would have won the demos and broken the payment step in production.
One component per placement, or one for all?
The same component adapts to the product page, the cart and mobile.
What settled it: in two weeks, one well-tested component beat three variants, and merchants have a single integration decision to make.
Not this: One widget per placement: simpler to design, but three times the integration decisions for the merchant.
The widget turned a development project into a configuration step. On the first four live merchants, checkout conversion rose by 3%. Marketing teams place it themselves and change its look without opening a ticket.
Conversion lift measured on the first 4 live merchants; figure rounded and anonymised.
For an SDK, the real user is the person integrating it. The shopper experience only exists if the integration was easy enough to ship.
What I would do differently: publish the theming documentation alongside the first release instead of after it.