PayPal is the wallet buyers already trust.

Q: Is PayPal enough on its own for an ecommerce store?

Sometimes. A modern PayPal integration covers cards, the PayPal wallet, Apple Pay, and Google Pay, which is a complete checkout for many stores. Whether it should stand alone is a risk question: for mainstream categories it can, and for risk-adjacent ones we pair it with a specialist gateway so payment acceptance never depends on a single provider's policy.

Q: Does express checkout actually improve conversion?

On mobile, meaningfully. An express button from the cart removes address entry and card typing, the two steps where mobile checkouts die. We instrument checkout with GA4 funnel tracking on every build, so the lift is measured on your traffic rather than asserted from industry averages.

Q: Can PayPal work for restricted or high-risk products?

Case by case, and only with pre-approval. PayPal can approve documented use cases in restricted categories in writing, which we secure before building anything. Without that letter we treat the category as unsupported and lead with rails underwritten for it, like NMI and Bankful.

One integration that serves cards, PayPal, Apple Pay, and Google Pay, with one-tap express checkout that measurably lifts conversion. On the right build, it is the primary rail, not the backup button.

paypal.com ↗

How we use PayPal

We integrate PayPal server-side through its modern APIs, not as a drop-in button. On our commerce builds a single PayPal integration serves card processing, the PayPal wallet, Apple Pay, and Google Pay, including one-tap express checkout straight from the cart, so a buyer on a phone pays in seconds without typing an address. Orders confirm through server-side capture and webhooks, so fulfillment fires only on money actually received. On Medusa builds PayPal runs as a payment provider inside the commerce engine, and on multi-rail builds it sits alongside specialist gateways so no single processor decision can stop the store.

A checkout should meet buyers where their money already lives.

Why PayPal

Two reasons: conversion and reach. The wallet effect is real, especially on mobile, where an express checkout button converts buyers who would abandon a card form. And PayPal's risk team evaluates businesses individually, which matters in risk-adjacent categories: with the use case documented and pre-approved in writing, PayPal can be the trusted consumer-facing rail for products mainstream processors decline by default. We treat that pre-approval as an engineering deliverable, secured before the build, not assumed after it.

One integration, four ways to pay

Modern PayPal is a full payments platform, and we integrate it as one. A single server-side integration gives a storefront the PayPal wallet, advanced card processing, Apple Pay, and Google Pay, all captured through the same API and confirmed through the same webhooks. That consolidation is worth real engineering budget: one vault, one reconciliation path, one place to reason about refunds and disputes, instead of a different provider bolted on per payment method. On our Medusa storefronts the whole set runs behind the commerce engine's payment provider interface, so checkout logic stays identical no matter which button the buyer taps.

How we build on Medusa Our web engineering service

PayPal in risk-adjacent categories

PayPal's acceptable-use policy restricts many of the same categories mainstream processors do, but with one difference that matters: documented use cases can be individually pre-approved. When we replatformed Philter, a personal air-filtration brand that Shopify had deplatformed, PayPal approved the product line in writing before we built, and it launched as the storefront's consumer-facing rail alongside specialist processors. That is the playbook: confirm the category in writing first, diversify rails by design, and never let one processor's policy change become the event that stops revenue.

The Philter case study How we use NMI

Where we use it