DEV Community: Luca Siviero

Why I built a full PayPal checkout on Cloudflare Workers instead of using Stripe

Luca Siviero — Tue, 18 Aug 2026 16:37:15 +0000

When I migrated a 4-year-old e-commerce store to Webround, the client had one non-negotiable requirement: PayPal had to work. Their customers were used to it and removing it would have meant losing conversions from day one.

I assumed it would be straightforward, but it wasn't.

The Stripe Connect dead end

Webround uses Stripe Connect in standard mode: the platform takes a commission, but the merchant keeps their own Stripe account and receives payments directly. It's a clean architecture, keeps Webround out of non-technical matters and causes no issues.

Except with PayPal.

Stripe Connect in standard mode doesn't support PayPal unless you're a merchant of record, meaning you collect the money on behalf of your merchants and redistribute it yourself. It's a completely different business model, implying a whole set of responsibilities. It seemed strange enough that I had to confirm it with Stripe support. After a phone call (yes, Stripe calls you, wherever you are), I got confirmation that what my client needed required a change in Webround's internal responsibility model.

It wasn't a viable path, but fortunately, with Webround on my side, reaching a workaround wasn't difficult.

The PayPal equivalent

The second idea I had was to integrate PayPal's equivalent of Stripe Connect (PayPal Marketplace) at the platform level, so the merchant could connect their own PayPal account natively. In theory it made sense, in practice a bit less: there's an approval process, you need to talk to someone on the sales team, reach a minimum volume threshold, and go through a partner onboarding process that takes weeks. Not viable.

The standalone approach

Third option: build a standalone PayPal checkout flow that bypasses both Stripe and any Connect model entirely. The merchant uses their own PayPal account directly. In practice, a perfectly normal PayPal payment process to orchestrate correctly.

I've been relying on Cloudflare Workers for this kind of thing for a few years now: lightweight, distributed at the edge, perfect for stateless serverless integrations.

I published the full source on GitHub: github.com/WebroundAdmin/wr-paypal-integration. Feel free to use it as a starting point.

How the flow works

The customer clicks PayPal: the Worker validates the cart via the Webround API. It never trusts what the frontend says.
The Worker creates the Webround order (status: created) and the PayPal order.
The PayPal order ID goes back to the frontend, which opens the payment page.
The customer approves and the frontend captures the payment. We don't trust the frontend for the order status change. We use webhooks!
PayPal sends the signed webhook and the Worker verifies the HMAC signature.
The Worker updates the Webround order to paid.
Webround fires the order.paid event to your existing integrations.

Step 1. Validate the cart server-side

Never trust prices submitted by the client, because any request can manipulate them. When the customer initiates checkout, the Worker fetches the real net price, tax rate, and stock availability for every item directly from the Webround API.

const verifiedItems = await Promise.all(
  items.map(async item => {
    const { unitNet, taxRate, packageWeight } = await fetchVariantData( // Method that calls the Webround API
      env,
      item.variantId,
      item.productId,
      item.priceId,
      currencyCode,
      shippingAddress.countryCode
    );
    return { ...item, netAmount: unitNet, taxRate, packageWeight };
  })
);

Step 2. Calculate the total (and the rounding trap)

This is where things get interesting.

Stripe and PayPal calculate order totals differently:

Stripe:

unitGross = round(netAmount × (1 + taxRate/100) × 100) / 100
lineTotal = unitGross × quantity

PayPal:

lineTotal = round(netAmount × quantity × (1 + taxRate/100) × 100) / 100

This is an implementation detail: you could just send the total directly to the Stripe checkout session, but in Webround's native Stripe integration, the payment page shows the full cart breakdown: images, name, unit price, and line total. So Stripe, which works in cents when paying in EUR, needs to know the tax-inclusive total for a single unit before it can show the total across all quantities purchased.

On a single-unit purchase, the difference is zero. On a cart with mixed quantities and decimal prices, the totals diverge.

I discovered this in production. Not because a customer complained... the checkout worked fine from their perspective. I found it because the order export was recalculating totals server-side and the numbers weren't matching what PayPal had actually charged. Silent discrepancies in the accounting export.

Here's an example:

Take a product with a net price of €8.17 and a 22% VAT rate:
Exact gross: 8.17 × 1.22 = €9.9674

PayPal method: multiply first, round after:
9.9674 × 3 = 29.9022 → rounded: €29.90

Stripe method: round first, multiply after:
9.9674 → rounded to 2 decimals: €9.97
9.97 × 3 = €29.91

A difference of €0.01 per order. Silent, systematic, and impossible to catch in happy-path testing.

The fix: align PayPal's calculation to Stripe's method, which is Webround's native integration, so PayPal adapts.

const grandTotal = verifiedItems.reduce((sum, item) => {
  // Stripe-compatible rounding: round unit gross first, then multiply by quantity
  const unitGrossCents = Math.round(item.netAmount * (1 + item.taxRate / 100) * 100);
  return sum + (unitGrossCents / 100) * item.quantity;
}, 0);

Apply the same method when creating order items:

const unitGrossCents = Math.round(item.netAmount * (1 + item.taxRate / 100) * 100);
const unitGross = unitGrossCents / 100;
const unitNet   = item.taxRate > 0 ? unitGross / (1 + item.taxRate / 100) : unitGross;
const unitTax   = unitGross - unitNet;

Pick one method and apply it consistently everywhere. The mismatch is exactly what causes the bug.

Step 3. Create the Webround order and the PayPal order in parallel

const [wrCustomerId, paypalToken] = await Promise.all([
  ensureCustomer(env, customerEmail, billingAddress, customerId),
  getPayPalToken(env),
]);

const [wrOrder, paypalOrder] = await Promise.all([
  createOrder(env, wrCustomerId, customerEmail, currencyCode, grandTotalStr, shippingCostStr, billingAddress, shippingAddress),
  createPayPalOrder(env, paypalToken, grandTotalStr, currencyCode),
]);

We save the mapping between the PayPal order ID and the Webround order ID in a Cloudflare D1 table: we'll need it when the webhook arrives.

await Promise.all([
  createOrderItems(env, wrOrder.id, verifiedItems),
  saveOrderMapping(env, paypalOrder.id, wrOrder.id),
]);

The Worker returns the PayPal order ID to the frontend, which passes it to the PayPal JS SDK to open the payment page.

Step 4. Handle the webhook

After the customer approves and the frontend captures the payment, PayPal sends a signed webhook event. This is the authoritative signal that the payment succeeded. Never trust what happens on the client!

const body  = await request.text();
const token = await getPayPalToken(env);

const valid = await verifyWebhookSignature(env, request, body, token);
if (!valid) return new Response("Unauthorized", { status: 401 });

const event = JSON.parse(body) as { event_type: string; resource: any };

const wrStatus = WEBHOOK_STATUS_MAP[event.event_type];
// PAYMENT.CAPTURE.COMPLETED → "paid"
// PAYMENT.CAPTURE.DENIED    → "failed"
// CHECKOUT.ORDER.CANCELLED  → "canceled"

const mapping = await getOrderMapping(env, paypalOrderId);

await Promise.all([
  updateMappingStatus(env, paypalOrderId, wrStatus),
  updateOrderStatus(env, mapping.wr_order_id, wrStatus),
]);

When the Webround order status becomes paid, Webround fires the order.paid event to all registered webhooks: email confirmations, stock updates, CRM syncs, everything listens there. The PayPal flow plugs into an event system that runs parallel to Stripe's native one, thanks to Webround's architecture and its webhooks.

The frontend component

On the Webround side, this is a custom React component dropped into the built-in IDE, added to the cart page below the native checkout button.

export default function PayPalButton({ wr }: { wr: Wr }) {
    const [message, setMessage] = useState("");
    const currencyCode = wr.customer.cart.items[0]?.currencyCode ?? "EUR";

    const cartItems = wr.customer.cart.items.map((item) => ({
        variantId: item.variantId,
        productId: item.productId,
        priceId: item.priceId,
        quantity: item.quantity,
    }));

    const payload = {
        items: cartItems,
        currencyCode,
        customerEmail: wr.cart.customerEmail,
        customerId: wr.customer.isLoggedIn ? wr.customer.profile?.id : undefined,
        customerJwt: wr.customer.isLoggedIn ? wr.customer.accessToken : undefined,
        billingAddress: wr.cart.selectedBillingAddress,
        shippingAddress: wr.cart.selectedShippingAddress,
    };

    return (
        <PayPalScriptProvider options={{ clientId: PAYPAL_CLIENT_ID, currency: currencyCode }}>
            <PayPalButtons
                createOrder={async () => {
                    const res = await fetch(`${WORKER_URL}/api/orders`, {
                        method: "POST",
                        headers: { "Content-Type": "application/json" },
                        body: JSON.stringify(payload),
                    });
                    const data = await res.json();
                    if (data.id) return data.id;
                    throw new Error(JSON.stringify(data));
                }}
                onApprove={async (data, actions) => {
                    const res = await fetch(`${WORKER_URL}/api/orders/${data.orderID}/capture`, {
                        method: "POST",
                    });
                    const orderData = await res.json();
                    const errorDetail = orderData?.details?.[0];

                    if (errorDetail?.issue === "INSTRUMENT_DECLINED") return actions.restart();
                    if (errorDetail) throw new Error(errorDetail.description);

                    window.location.href = "/checkout/success?clean_cart=true";
                }}
            />
        </PayPalScriptProvider>
    );
}

What this unlocked

The Worker became the foundation for the client's entire payment layer outside Stripe. Clean separation: Stripe has its own isolated microservice, PayPal goes through the Worker. Both converge on Webround's order system and fire the same order.paid event downstream, with the difference that PayPal does everything from the outside via REST API.

The client now runs both payment methods in parallel, with full webhook coverage and correct event tracking on both sides.

The takeaway

If you're building on a platform that uses Stripe Connect in standard mode, don't assume PayPal is just a plugin away. It isn't. But it's also not impossible: it just requires owning the orchestration yourself.

Cloudflare Workers are a good fit for this use case because the logic is stateless, latency matters at checkout, and you get secrets management and D1 out of the box.

Test the rounding before you go live. It won't show up in happy-path testing. Explicitly compare totals between your platform's calculation and PayPal's, with real product data and mixed quantities, before you ship.

The full Worker source, React component, D1 schema, and wrangler config are on GitHub: github.com/WebroundAdmin/wr-paypal-integration

Built on Webround, an API-first e-commerce platform. All order, catalog, and checkout endpoints are publicly documented at docs.webround.com.

Why I built an API-first e-commerce platform

Luca Siviero — Tue, 07 Jul 2026 09:33:37 +0000

Hi! I'm Luca, from Italy, and I've spent the last two years building Webround: an API-first e-commerce platform.

This is something that started as a project of mine with a totally different target: I wanted a quicker way to update my portfolio because I was completing different projects every week. After a lot of headaches, early mornings, late nights and a ton of coffee, I had what I wanted: a way to no-code my portfolio and update it as I wanted.

But while I was completing the project, an idea of making it a headless platform started growing: why would you keep things static and limited to portfolios? AI's already great at doing that!

This idea started getting more serious, to the point that I fired myself from the previous job and after waaay more coffee, late nights, early mornings and a lot of building, breaking, changing, crying, it started to take shape as the product that is today.

While building the platform, I worked as a freelance dev for smaller businesses in town and I had the (very bad) privilege of seeing what they were doing with e-commerce platforms, website management, hosting and more. Nothing ever made any sense because every set-up started from a mix of old technology, forgotten stuff, weird hosting providers, on-premise setups, big ahh monoliths, hacked servers, random throwing errors systems and much more ugly stuff.

I never tried to force Webround into making sense. I've always wanted to be free (in general in my life) and as a developer, the fact that other platforms started feeling as a constraint rather than a tool when things started evolving, was throwing me off.

After working with other popular platforms, I realized that today's landscape is almost never about making things easier, rather about making users dependent on the platform so it's harder to go away.

Why Webround?

Before answering this question, we have to take a look at two examples.

Shopify: this is arguably the best go-to platform for immediate satisfaction. But you're not buying a website, you're buying an ecosystem and all the deriving things from it. Shopify has a great source of strength that is, at the same time, a great source of pain: the app store. Don't get me wrong, extensibility is huge, but usual customers on Shopify are smaller business owners that are chaotic, lack expertise and threat their website like it's a phone with apps. But a website is not a phone and needs real expertise to make it work correctly, so why would anyone keep finding workarounds to make something work with half-solutions to their unique problems? As a developer, working with Shopify never felt great with all the apps and the ecosystem they force. While merchants keep scaling requests to devs or agencies because they keep finding out that they bought a complex (and closed) ecosystem instead of a website.
WooCommerce, Medusa, Vendure, Prestashop: these tools are open-source and carry all the benefits of open-source solutions, but when you start working with these softwares, you enter a maze of weird stuff that you have to actually understand before you get productive at even writing a single line of code. Then you have to manage the infrastructure, without talking of the common issues that these platform have: poorly designed plugins, the "Plugin Hell" situation, non-existent backwards compatibility, monolithical architecture... well, this is not something that looks promising to build onto.

That's where Webround starts making sense.
Let me make you one question: what if you had a managed environment that lets you build natively, in a modern and standardized way, leveraging SDKs and APIs to build virtually anything, while keeping plugins and extensions as separated microservices that work with the core of the platform and not within the core of the platform?

Well, that's exactly what Webround is. A flexible solution to build virtually anything while keeping the developer at the center.

Who's the target user?

In Webround, the more you know, the more you can do. I have always developed the platform with three users in mind.

The no-code user. This person doesn't want or know how to write code and likes to keep things simple, without the risk of running custom implementations. There are limitations, because this user can only work within the boundaries of no-code components, but there is no room to break stuff, while keeping the flexibility to build any layout through a drag & drop editor.
The React developer. This user can speed up website creation by a lot, for a good reason: not only you can write React code inside an integrated IDE, but you can also install any NPM package and use Tailwind. Although, the real advantage lies in the built-in SDK. With a simple wr prop, you can access the underlying app's state and functions to leverage e-commerce functionalities straight from your custom React components. You can access these tools from the browser, without installing anything. Even builds are server-side.
The builder. Their attitude is simple: "Give me a bunch of APIs and I'll figure it out". Webround is an API-first platform that publicly exposes all the endpoints you need, both for the storefront and for managing the e-commerce, the authentication flow of its customers, the catalog system, the cart and the checkout flow. You can use Webround to build headless stores or even as a data layer for your own custom app! It's totally doable; all you need to do is read the docs at docs.webround.com and you're ready to go.

There's more

E-commerce is not just a storefront. Behind every store there are events to handle, data to sync, notifications to send, external systems to connect. The usual answer on other platforms is: open another app, install another plugin and pay another subscription.

With Webround, you have native tools for this.

Webhooks to react to platform events in real time.
Edge Hooks to inject secure runtime data before your pages render.
Checkout Hooks to manipulate the payment flow before it reaches Stripe (Webround partners with Stripe Connect).
App Extensions to build isolated micro-services that plug directly into the platform without touching the core.

This is a way bigger topic that needs to be analyzed in a separated session, so I'll just anticipate that these tools exist for now :)

Final thoughts

I'm not here to sell you anything. I'm looking for users. No-coders who want to explore a modern solution, React developers who want to speed up their work, and hardcore builders who just want a solid set of APIs and the freedom to do whatever they want with them.

If you want to reach out or give me some thoughts about Webround, what you like, what you don't like, what you think is a good or a bad idea, you're absolutely free to reach out!

Just a little anticipation: the website requires you to sign-up with email or google and to verify your account. But, apart from this, every function is basically free to use. Another thing, is that you'd need a subscription to call APIs from the outside (for publicly accessible data). You can either activate a trial, either contact me to request an activation: I'll be more than happy to welcome you here.

Finally, if you want to see my big face, I've created an introduction video to Webround, uploaded on the official channel, where you'll also find a set of tutorials to do the basic stuff with the no-code editor.

I'll leave the links to the official website and documentation, so you can know more about it!

webround.com
docs.webround.com