JD Sports - Scalapay Integration
Context
JD Sports' Italian storefront needed a buy now, pay later option. Scalapay is the country's dominant BNPL provider, and Italian user research told us customers wanted access to it. Adding it wasn't the hard part.
The hard part was where it sat, and what giving a third-party BNPL provider prominence over Apple Pay, Google Pay, and card payments would mean for how customers actually paid.
Scalapay wanted to be positioned as the primary payment method in Italy, ahead of every other option. Not an alternative alongside them. The default.
Their reasoning was straightforward: they're the leading BNPL provider in Italy, and believed that position should be reflected in checkout. JD's standard model puts BNPL providers on a second tab, separate from the primary payment methods. Scalapay wanted to break that convention.
My role
I was the sole product designer on this, working with a lead researcher, an accessibility lead, a technical product owner, trading, and Scalapay's own brand team directly for asset and placement requirements.
I was a Senior Product Designer at the time, and ran this using the same structured process I'd built and embedded across the team — kickoff, research, design, sign-off — rather than working it ad hoc.
The design phase ran two 2-week sprints, extended by the volume of work run past legal given the regulatory weight of BNPL terms and messaging. Engineering build took a further three sprints, reflecting the complexity of the Scalapay hand-off itself rather than the JD-side screens.
Working within legal and compliance constraints
Legal and compliance weren't a sign-off gate at the end of this project — they set the boundaries I had to design within from early on, covering Scalapay's own requirements, Italian regulatory law, and the risk to our other payment partners if we got the balance wrong.
I shared early design concepts with them directly rather than waiting for a finished design to be reviewed, so the constraints came before the work rather than after it. Engineering was in the same conversations, working through the development effort each option would realistically take. That's the shape this collaboration actually took: legal and compliance telling us what we could and couldn't do, engineering telling us what was buildable, and me designing inside both.
The problem with the ask
The product owner on this wasn't willing to challenge Scalapay or ask questions of their request. She also didn't want to involve JD's commercial team for support in pushing back.
There was a risk she hadn't clocked: giving a BNPL provider more prominence than Apple Pay or Google Pay isn't just a JD decision. Apple and Google are protective of how their payment methods are presented, and having done an Apple Pay integration previously at Paddy Power Betfair, I knew how seriously Apple treats that. I walked her through it. She hadn't seen that risk on her own.
I didn't think the placement question was one to wave through either way. Prioritising a BNPL product over a customer's own card, or a payment method already saved to their phone, isn't neutral. It nudges people towards debt-based payment by default. That's a judgement call, not just a placement decision, and it deserved to be treated as one.
Rather than leave it unresolved at product-owner level, I took it directly to the trading director.
Making the case with evidence, not opinion
I didn't want to win this on instinct. Working with a researcher, we ran a survey to around 100 Italian users asking directly whether they wanted BNPL presented as the primary payment option ahead of standard methods. The majority said no. Alongside that, we ran an A/B test to work out which design treatment performed best, and worked with local Italian colleagues to properly understand how Scalapay was actually used and perceived in that market rather than assuming it mapped onto UK BNPL behaviour.
That gave the trading conversation something to stand on. Not "this feels wrong," but a specific, evidenced answer from the customers the decision would affect.
What shipped
There wasn't a design exploration phase in the visual sense. The checkout patterns already existed in JD's design system, so the components themselves weren't in question. The real work was the placement battle: where within that existing structure Scalapay would sit.
Checkout defaults to "Pay now," with Apple Pay (or Google Pay on Android), card, and PayPal presented as the immediate options. Scalapay sits under "Pay later," JD's standard second tab for BNPL providers rather than being promoted to the primary view.
Within that tab, Scalapay does get first position in the list, ahead of Klarna. That was the actual resolution: not a flat no, but the best position available to them within a structure that didn't compromise Apple Pay, Google Pay, or card payments as the default choice.
Building this meant working directly with our third-party engineering team to get the hand-off between JD's checkout and Scalapay's own flow working correctly, rather than just designing the JD-side screens in isolation.
What we didn't get
Not everything landed. Scalapay wouldn't add JD branding to their own login page, despite doing exactly that for other retailers. I pushed on this because a customer being handed off to an unbranded page mid-checkout is a trust and continuity problem, not just a cosmetic one. I suspect it was a quiet consequence of not giving them full top-of-checkout prominence elsewhere. It's an honest example of a vendor relationship where leverage cuts both ways, and not every negotiation ends in a full win.
Outcome
Checkout completion rate for Italian customers rose from 63.7% to 68.3% once Scalapay launched, a 4.6 percentage point improvement, alongside a 4.6 point drop in payment abandonment. Average order value rose 12.2%, from €96.40 to €108.20, and revenue across the Italian storefront increased 22.7%, from €78.9m to €96.8m over the comparison period.
14.6% of Italian orders now go through Scalapay. The Scalapay modal on the basket page saw a 12% interaction rate, showing real engagement with the option beyond just the checkout adoption figure.
One pattern stood out: customers who checked out with Scalapay bought an average of 4 items, against an average of 1 for JD customers overall. I can't say the modal caused that basket size, only that it correlates with it, but it's a strong enough signal that BNPL customers behave differently, and worth further testing rather than a settled claim.
The placement didn't cost adoption, and it didn't cost the business either. It proved the two things could both be true: an ethical stance on how BNPL was presented, and a payment method that drove a measurable commercial improvement once it existed as an option people could actively choose rather than one pushed in front of them.
What held
As of my leaving JD, the checkout design remains exactly as shipped. No override, no revisiting. Scalapay didn't get the prominence it originally asked for, and the business didn't need to give it that prominence to make the product work.
Beyond Italy
This was an Italy-specific decision for Scalapay specifically, but it became a reference point internally for how JD approached localised payment integrations more broadly — evidence that a market-specific provider request could be handled through the same structured process rather than as a one-off exception.
Key Decisions I Personally Drove
Identified that a partner's placement request was an ethical and commercial decision, not a routine implementation task, and escalated it rather than letting it pass at product-owner level.
Took the decision directly to the trading director when the product owner wasn't willing to challenge the request or involve commercial support.
Commissioned Italian-specific user research rather than relying on UK BNPL assumptions, and used the result to ground the trading conversation in evidence.
Negotiated the resolution: Scalapay first within JD's standard second-tab BNPL structure, rather than promoted above Apple Pay, Google Pay, and card payments.
Identified the Apple/Google brand-risk implications of the original request, drawing on prior Apple Pay integration experience the product owner didn't have.
Held the position after launch — the design remains unchanged, with no override or renegotiation since it shipped.