Ralph Lauren · Cart, checkout & payment product ownership
Payments & Checkout
Expanding payment choice.
Simplifying the path to purchase.
Selected initiatives from my payments and checkout roadmap
After Ralph Lauren’s initial Klarna rollout, I took over the cart and checkout roadmap and led subsequent payment expansions and purchase-flow improvements across web, app, and Factory Store experiences.
The three examples below show different parts of that broader ownership: delivering Klarna across channels, running a checkout experiment that progressed to global implementation, and evaluating a gifting platform against its customer value and operating requirements.
My role · Cart & checkout roadmap ownership · Payment integrations, requirements, experimentation, cross-functional delivery, and vendor evaluation
Payment expansion
Web. App. Stores.Pay in 4 on Ralph Lauren web and app; Pay Now and Pay in 4 for Factory Store shoppers through Klarna.
Experiment to implementation
Global rollout.Ran checkout-navigation testing and helped move the successful change into implementation.
Product judgment
A deliberate no-go.Led the 4Gifters evaluation and decided against a launch whose operating requirements outweighed its value.
Klarna · Payment integration & expansion
Expand Klarna across web, app, and stores.
I led the launch of Pay in 4 on Ralph Lauren web and the RL app, plus Pay Now and Pay in 4 for Factory Stores through the Klarna app. The work combined integration delivery with payment eligibility, customer messaging, and Express Checkout roadmap work.
My contribution · Integration delivery, payment requirements, eligibility rules, customer messaging, and checkout roadmap
Manage the integration across the purchase journey.
I translated the payment experience into requirements spanning product pages, the bag, checkout, and the handoff to Klarna: where to introduce installments, which purchases qualified, and how customers continued when payment could not proceed.
The channel shaped the delivery model: payment within Ralph Lauren’s web and app checkout, or payment setup through Klarna’s app for Factory Store shoppers.
- Channel deliveryLed Pay in 4 integrations for web and the RL app, and Pay Now and Pay in 4 for Factory Stores through Klarna’s app.
- Eligibility expansionTranslated basket thresholds, product exclusions, and regional payment rules into integration requirements; the North American purchase limit expanded from $2,500 to $4,000.
- Recovery & handoffsSpecified declines, retry behavior, redirect loading states, and product information passed to Klarna.
Make payment choice visible throughout the journey
Original Ralph Lauren interfaces illustrate the messaging and payment steps covered by the integration requirements.
Behind the interface: implementation
SFCC configuration and content assets · Klarna on-site messaging · Adyen response handling · product/image data continuity · channel-specific payment journeys.
Connect payment eligibility, storefront messaging, and provider responses.
Expanding Klarna required coordinated behavior across Salesforce Commerce Cloud, Klarna’s on-site messaging, the checkout handoff, and payment-provider responses. My product scope covered channel delivery, payment requirements, customer messaging, and recovery behavior. The implementation depended on keeping storefront configuration, basket eligibility, and the customer’s payment state aligned.
- Message visibility ≠ payment eligibilityA product attribute can suppress on-site messaging (including the furniture exclusion) without defining whether the basket can pay with Klarna.
- Merchant eligibility ≠ credit approvalStorefront rules decide when Klarna is offered; Klarna decides whether the shopper is approved.
- Baseline ≠ later expansionHistorical basket range of $1–$2,500; the RLNA expansion to $4,000 shipped in release 21.14, September 2021.
Prevent repeat declines without trapping the shopper.
- Shopper starts a Klarna payment
- Adyen returns a “refused” response
- Shopper returns to the payment selectors
- Klarna is disabled for that session
Cart unchanged → Klarna stays unavailable; the shopper continues with another payment method.
Cart amount reduced → Klarna is offered again under the reduced-cart rule. This does not guarantee credit approval.
Configuration and exclusions
| Surface | Setting | Behavior |
|---|---|---|
| Klarna Portal | On-Site Messaging › Placements | Provides placement code copied into SFCC content assets; separate placements for PDP and cart. |
| PDP | Content asset klarna-onsite-messaging · data-key custom-type0 | Locale supplied; placed below price and above product selection. |
| Cart | Content asset klarna-onsite-messaging-cart · data-key custom-type1 | data-locale and data-purchase-amount populated; below bag total, above Proceed to Checkout. |
| Payment selection | Content asset klarna-tooltip | Installment and eligibility education where the shopper chooses a payment method. |
| Site | SFCC Payment Methods › Klarna site preference | Operational switch that enables or disables the functionality. |
| Basket | Configurable thresholds | Historical baseline $1–$2,500; later RLNA expansion $2,500 → $4,000 (release 21.14, September 2021). |
| Basket | Payment exclusions | Gift-card purchases excluded; every basket item must qualify; Klarna suppressed when the order has White Glove Delivery shipping. |
| Product | Attribute isNoKlarnaOnSiteMessaging | Controls messaging suppression, including the furniture exclusion. Separate from payment eligibility. |
| Handoff | Product and PDP lifestyle image URLs | Should match the image shown in the bag so the purchase displays consistently in Klarna’s app. |
| Merchandising | Default-on messaging | Historically on by default for Merch Ops, subject to the exclusions above. |
Acceptance scenarios and expected behavior
| Scenario | Expected behavior |
|---|---|
| Eligible, configured basket and locale | Correct placement renders with the current purchase amount. |
| Basket contains a gift card or White Glove item | Payment exclusion applies. |
| Shopper starts the Klarna redirect | Checkout is protected from extra interaction. |
| Provider returns refused | Return to payment selectors; Klarna disabled for the session. |
| Cart reduced after a refusal | Option offered again after the cart amount is reduced. |
| Purchase shown in the Klarna app | Product link and lifestyle image correspond to the bag item. |
| Digital vs Factory Store channel | Factory Store follows a distinct Klarna-app-mediated store journey. |
Carry the payment work into the checkout roadmap.
My scope also included Klarna Express Checkout work, recorded on the FY23 roadmap. The current UK screens below illustrate payment education and the Express handoff, including recovery when the Klarna window does not open.
Payment education and the Express handoff
Live UK captures. The example plans shown here are Pay in 3 and Pay in 30 days.
Bring flexible payments into Factory Stores
The in-store experience runs through the Klarna app. These current screens show the merchant entry and preparation steps.
A different integration surface
One customer promise.
Different payment journeys.
The web and RL app work integrated payment choice into digital commerce. Factory Store customers used Klarna’s app to prepare their in-store payment.
Explore standard checkout and Pay in 4 reference screens
Official Klarna examples provide additional context for payment selection and review.
Product takeaway: the integration’s quality depends on the full journey—where payment choice is introduced, when it is available, and how clearly the shopper can continue or recover.
Selected checkout experiment · Testing & implementation
Test a more focused path to purchase.
As one initiative within my broader cart and checkout remit, I ran a navigation experiment to assess whether fewer browsing options would improve purchase completion. The successful test progressed to global implementation.
My contribution · Running the test, coordinating desktop and mobile execution, and supporting implementation
One hypothesis, tested across desktop and mobile.
The test used a 50/50 traffic split in Monetate to evaluate reduced navigation in the shopping bag. Server-side delivery was chosen to avoid visible flicker and support a path to production, with distinct desktop and mobile treatments.
The original test concepts
The 2021 brief explored bringing a reduced header into the shopping bag. Original design annotations are preserved.
See the current desktop and mobile purchase journeys
The current UK experience separates browsing from purchase completion: the bag retains shopping navigation, while checkout simplifies the header. These captures show today’s journey alongside the original concepts above.
Desktop · shopping bag to checkout
Two stages of the current UK journey, captured in November 2026.
Mobile · a simpler header at checkout
The current mobile journey makes the shift in navigation especially visible.
Product takeaway: focused checkout testing paired a clear customer hypothesis with an implementation approach that could scale globally.
4Gifters · Vendor evaluation & product judgment
Evaluate the gift experience.
Follow the money behind it.
I led the 4Gifters evaluation and decided not to proceed when the tax, reconciliation, and regional operating requirements outweighed the benefit of the proposed gifting experience.
My contribution · Lead product manager · Vendor evaluation, customer journey, regional requirements, Finance alignment, and launch recommendation
The customer promise was appealing.
Send a product without knowing the recipient’s size or delivery address. Add a personal message, fund a gift with other people, and give the recipient a digital reveal.
After receiving the gift, the recipient could accept it, change a variant, exchange it, or take a voucher path. I assessed the customer experience alongside the commerce, fulfillment, and financial processes required to support those choices across regions.
The interface needed explanation.
A ten-person usability study found that shoppers could miss the gifting option, while “digital gift” could be interpreted as a gift card. The team explored alternative PDP messaging and an education modal to explain the new journey.
Discover and understand the gifting option
Original Ralph Lauren concepts from the August 2021 usability study.
The experience behind the button
The vendor proposal extended beyond sending a product into reveal, recipient choice, and exchange.
Behind the interface: proposed integration
Evaluated and not launched. Proposed responsibilities and data exchanges across Ralph Lauren and 4Gift.
A funded gift was not yet a final order.
The proposed integration separated gift funding from the recipient’s final product, size, delivery address, and fulfillment choice. That made the technical challenge larger than adding a gifting button: the experience had to keep catalog data, availability, order state, customer communications, tax, and settlement aligned across Ralph Lauren and 4Gift.
I led the integration evaluation across North America and Europe, bringing the customer journey, implementation requirements, and Finance questions into the launch decision. The partner flows show the proposed behavior I assessed.
Connect the storefront, partner platform, and order systems.
- The plan used an SFCC cartridge and APIs to align products, categories, options and master/variant data with 4Gift.
- The delivery breakdown covered SFRA adaptation, PDP changes, analytics, order history, returns, email and reporting.
- Proposed order model: an unfinished order in SFCC, finalized when a partner completion notification carries the order details, supporting OMS export. Recipient choices happen before final fulfillment.
Keep availability separate from funding.
- Inventory reservation was an unresolved, conflicting assumption: the vendor described a temporary hold after the first contribution, while RL architecture notes said the cartridge did not hold stock until order placement and that reservation was unlikely to be implemented.
- If stock was unavailable when funding completed, the documented alternatives were a substitute item, a gift-card option, or cancelling and refunding contributors. Funding alone could not be assumed to reserve inventory.
Original partner sequence: recipient exchange
Original partner sequence, March 2022. Vendor-authored flow assessed during the evaluation.
- AAvailability is checked when alternatives are offered, after variant selection, and after payment before confirmation.
- BA higher-priced replacement introduces an additional payment from the recipient.
- CExchanges before finalization live in 4Gift; returns after confirmation follow Ralph Lauren’s gift-return process.
Account for changes before the order is finalized.
- A gift created during a promotion could be finalized after it ended, so explicit price-locking and recovery rules were needed.
- Order history is associated with the gifter’s account and existing gift-order rules apply.
- Partner gift updates and RL order and shipping communications have distinct owners; the customer handoff needs a clear redirect notice.
Original partner flows: team-gift contribution, finalize and cancel
Make the financial transaction traceable.
- A distinct 4Gift payment method in OMS with a corresponding tender reference in OMS/IIB output; an order-line attribute identifies 4Gift ecommerce sales in BI.
- Rather than standard PSP settlement: a 4Gift reconciliation file, RL verification of amounts, partner disbursement and a monthly invoice. The source proposed a file within the first seven business days of the following month, while Finance asked whether settlement should be weekly — cadence was a decision needing alignment.
- Sales Audit needed an agreed file format and dashboard access; requirements covered fees, chargebacks, AP and forecasting.
OMS would not interface with standard payment service providers such as Adyen to settle these orders. Reconciliation would run through a partner file and RL verification instead.
Resolve regional tax assumptions before launch.
- US: the proposal used Avalara, with discussion of using RL’s existing instance; jurisdiction coverage and a changed recipient delivery address needed validation.
- EU: Finance’s working analysis treated the pickup code as a voucher and 4Gift as deemed supplier under the assumed terms. Under those assumptions, redemption and destination affected VAT and invoicing, and could require an RL-to-4Gift invoice for delivered goods — distinct from North American partner invoices to RL accounts payable.
Operating-boundary matrix
| Boundary | What had to be handled |
|---|---|
| Catalog → 4Gift | Cartridge/API catalog entities plus SFRA adaptation |
| Funding → stock | Conflicting hold assumptions plus out-of-stock recovery |
| Partner → SFCC/OMS | Unfinished order, completion details and export |
| Customer → history | Gifter account plus existing gift rules |
| Recipient → replacement | Availability, variants and price delta before finalization |
| OMS/IIB → Finance/BI | Payment method/tender plus order-line attribute |
| Partner → settlement | File, verification, disbursement and invoice, plus cadence/format alignment |
| Delivery → tax | US jurisdiction/system plus conditional EU redemption/destination model |
The decisive issue was the business model.
The difficult questions sat behind the interface: who collected payment, when a gift became an order, how recipient choices changed the transaction, and how payments, goods, and invoices would reconcile.
EU Finance’s working analysis considered voucher and deemed-supplier treatment under the proposed arrangement. That raised different VAT and invoicing requirements depending on redemption and delivery. Exchanges, price changes, additional payments, gift cards, and unaccepted gifts added further exceptions.
The operating model that shaped the decision
Original Finance analysis connects the shopper experience to voucher issuance, redemption, delivery, and invoicing.
One gifting flow.
Several transaction outcomes.
- Align the commercial agreement with the tax treatment.
- Reconcile purchaser payment with the recipient’s final order.
- Account for exchanges, gift-card conversion, and gifts that are not completed.
- Support regional Finance and sales-audit requirements.
Choose a simpler direction.
As the implementation effort became clearer, EMEA business interest weakened. I concluded that the operating burden was disproportionate to the customer benefit and decided against launch.
The better direction, in my view, was a more focused gifting capability within Ralph Lauren’s existing commerce experience, with simpler scope and clearer ownership of the transaction.
View the alternative PDP message tested with shoppers
Product takeaway: deciding not to launch was an outcome of the evaluation. Customer appeal, implementation effort, and the ongoing operating model had to justify the same investment.
Across the portfolio
Payment choice is a product decision.
So is the complexity behind it.
These selected initiatives illustrate how I approached the broader cart and checkout roadmap: deliver useful payment options, test improvements to purchase completion, and evaluate partner models against customer value and operating cost.
