Lemon Squeezy payments for GoCommerce

What it does

Configuration

Four settings are required: the API key, the webhook’s signing secret, and the store and placeholder variant every checkout is created against. Set them in Config from your own main(), or under Settings › Payment methods.

The module reads its Config struct, not the environment. The variable names are the ones the package’s own example or the reference binary uses; in your own main() you choose where each value comes from. Where a setting has a panel label, the admin’s settings drawer can hold it too, and a value typed there wins over Config.

Setting it up

1. Create the placeholderIn Lemon Squeezy, create one product with any name and price, and note the store id and its variant id. Shoppers never see it.
2. Add the webhookPoint a webhook at https://your-api-host/api/checkout/lemonsqueezy/webhook for order_created, and keep its signing secret.
3. Install and configurePass lemonsqueezy.New to gocommerce.New as below, or run the reference binary with -gateways and fill in Settings › Payment methods. Leave GoCommerce’s tax rates empty.
4. Take a paymentPOST /api/checkout/lemonsqueezy answers with a redirect intent whose url is the hosted checkout. A paid order_created marks the order paid.

import (
	"os"

	"github.com/itswadesh/gocommerce/core"
	lemonsqueezy "github.com/itswadesh/gocommerce/ext/payments-lemonsqueezy"
)

app, err := gocommerce.New(cfg,
	lemonsqueezy.New(lemonsqueezy.Config{
		APIKey:        os.Getenv("LEMONSQUEEZY_API_KEY"),
		WebhookSecret: os.Getenv("LEMONSQUEEZY_WEBHOOK_SECRET"),
		StoreID:       os.Getenv("LEMONSQUEEZY_STORE_ID"),
		VariantID:     os.Getenv("LEMONSQUEEZY_VARIANT_ID"),
	}),
)

How it works

• JSON:API, as required

  Requests go as application/vnd.api+json, which Lemon Squeezy insists on — the package notes that plain JSON is refused with a confusing 415.

• Signed, without a timestamp

  X-Signature is a hex HMAC-SHA256 of the raw body, compared in constant time. With no timestamp in it, the idempotency claim is what stops a captured delivery applying twice.

• Each event once

  Lemon Squeezy sends no event id, so claims are keyed on the event name plus the object id. A retry is a duplicate; two different events about one order stay distinct.

• Only paid settles

  order_created with any status other than paid is acknowledged and changes nothing, so a sale still being collected, or refused, is not marked paid.

• Refunds against the order

  A refund posts to Lemon Squeezy’s refund endpoint for its order id, for the amount asked, and keeps the id it answers with on the refund row.

• A failed update is retried

  If marking the order paid fails, the claim is released and the webhook answers 500, so the retry finds work to do.

What it does not do

Read these before an order depends on it. No store is known to run GoCommerce in production yet, so these come from the code, not from anyone’s experience.

• A placeholder is requiredWithout StoreID and VariantID the module stays unconfigured, and a wrong variant surfaces as an error from Lemon Squeezy at the first checkout.
• No currency is sentThe checkout carries the total as custom_price in minor units and no currency code. Check that the Lemon Squeezy store charges in the currency your store settles in.
• Tax is Lemon Squeezy’sLeave GoCommerce’s tax rates empty. The module does not check, and configuring both charges tax twice.
• No failure pathThe module never marks a payment failed. A checkout that is abandoned or declined leaves the order unpaid.
• Refunds follow the webhookA refund goes against the Lemon Squeezy order id that only the paid order_created webhook records.
• Dashboard refunds are only loggedorder_refunded is logged, not applied. A refund made in Lemon Squeezy does not change the GoCommerce order.