FastSpring WooCommerce: 5 Parts of a Gateway

Selling software from Ukraine with card and PayPal payments means a merchant of record, and a merchant of record means the checkout is not yours. A fastspring woocommerce integration accepts that and keeps the store as the place where orders live.

Code: woocommerce-fastspring-gateway, GPL-2.0-or-later.

WordPress 6.4, WooCommerce 8.0, PHP 8.1, and one plugin that redirects to the hosted checkout and listens for the webhook that comes back.

Part 1: the session, not the card form

The gateway does not collect card data. It creates a FastSpring session through the API and sends the customer to the hosted page, where FastSpring handles cards, PayPal, Amazon Pay and the tax rules of the buyer’s country.

For the shop that is a shorter compliance conversation. Card data never touches the server, the PCI scope shrinks to a redirect, and the merchant of record owns the invoice the customer downloads.

Part 2: the webhook is the order

The order is marked paid by a webhook, not by the return URL. A customer who closes the tab after paying still gets a paid order, and a customer who returns without paying does not.

Twelve events are handled: four for orders, one for a return, and seven for subscription lifecycle and charges. A gateway that only listens to order.completed leaves every renewal invisible.

Part 3: the signature is mandatory

Every webhook is verified with HMAC SHA256 and compared with hash_equals, and a request without a valid signature is rejected. An optional IP filter narrows it further.

The alternative, trusting a POST because it looks like a webhook, is how an order gets marked paid by anyone who reads the plugin source. The readme states that verification is mandatory, which is the sentence to look for in any payment plugin.

Part 4: subscriptions are a separate problem

Recurring payments add renewals, trials, signup fees, pauses and cancellations. The plugin maps each to a WooCommerce status: subscription.activated stores the id, paused puts the order on hold, uncanceled returns it to processing.

A shop that sells a monthly plan and only implements the first payment discovers the gap in month two, when the renewal charge arrives with nowhere to land.

Part 5: the product mapping

FastSpring sells its own product paths, WooCommerce has its own products, and something has to connect them. A meta field on the product holds the FastSpring path, with SKU as a fallback.

Small decision, large consequence. A missing mapping is a checkout that opens FastSpring with an empty cart, and the support ticket says “the button does nothing”.

What the plugin does not decide

Refund policy, tax registration, invoice wording and the legal entity behind the sale belong to the merchant. A merchant of record handles collection and remittance, and the shop still decides what it sells and under which terms.

HPOS compatibility and Blocks compatibility are declared, which in 2026 is the difference between a plugin that installs and one that breaks a checkout after an update.

What to check after the first payment

Make one real payment of the smallest amount and follow it: the order status, the note, the email, the invoice in the FastSpring dashboard, the refund back. A test card proves the code path, and a real payment proves the tax and the accounting.

Then break it on purpose: close the browser before returning and confirm the webhook still marks the order. That single check catches most of the integrations that look fine in a demo.

What it costs

A day of configuration for a simple store, a week when subscriptions and a test storefront are involved. The rest of the integration is the mapping exercise: products, taxes, emails and the refund path a support agent will use.

Related: woocommerce development for how a store scope is quoted, and PHP development for the plugin work around it.