RevenueCat Web Billing for GoCommerce

What it does

Configuration

Two settings are required: the Web Purchase Link token and the exact Authorization header RevenueCat is configured to send. 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. Match the priceIn RevenueCat, the product’s price must equal the order total — so leave GoCommerce’s tax rates empty, as for a merchant of record.
2. Configure the webhookPoint RevenueCat’s webhook at https://your-api-host/api/checkout/revenuecat/webhook, set its Authorization header, and switch signing on.
3. Install and configurePass revenuecat.New to gocommerce.New as below, or run the reference binary with -gateways and fill in Settings › Payment methods.
4. Take a paymentPOST /api/checkout/revenuecat answers with a redirect intent whose url is the purchase link. A matching purchase event marks the order paid.

import (
	"os"

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

app, err := gocommerce.New(cfg,
	revenuecat.New(revenuecat.Config{
		LinkToken:            os.Getenv("REVENUECAT_LINK_TOKEN"),
		WebhookAuthorization: os.Getenv("REVENUECAT_WEBHOOK_AUTHORIZATION"),
	}),
)

How it works

• No API call at checkout

  The purchase link is a URL the module builds from the link token, the order number, the email and the currency. RevenueCat hears about the order only when the shopper pays.

• Two layers of verification

  The Authorization header must match exactly, in constant time. With a signing secret set, X-RevenueCat-Webhook-Signature must also verify: t=…,v1=…, an HMAC-SHA256 over the timestamp and the body, within five minutes.

• The price is checked

  RevenueCat reports the price as a decimal. The module converts it to minor units — zero- and three-decimal currencies such as JPY and KWD included — and settles only on an exact match with the order’s total and currency.

• Each event once

  Claims are keyed on RevenueCat’s event id. A redelivery is answered 200; a TEST event from the dashboard is acknowledged and nothing else.

• A failed update is retried

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

• Warnings where they help

  An order with a shipping address logs a warning at checkout, because Web Billing will not carry it. A CANCELLATION logs that the order still reads as paid.

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.

• No refundsRevenueCat has no API to refund a Web Billing purchase, so the module does not claim the capability. A refund from the admin is answered 409 — the payment method does not support refunds. Refund in RevenueCat or the underlying processor.
• The price is RevenueCat’sThe link carries no amount. If the product’s price and the order total differ by one minor unit, the order is not settled and the mismatch is logged for an operator.
• Digital goods onlyPer the package, Web Billing collects no shipping address and does not support B2B sales. A store that ships parcels should use another provider.
• Not for merchants in IndiaThe package cites RevenueCat’s documentation: Web Billing is not available to merchants in India.
• One customer per orderThe order number is the app user id, so each order is a new RevenueCat customer. A project that also sells subscriptions to the same people would need to alias them in RevenueCat; the module does not.
• Cancellations are only loggedA CANCELLATION — how RevenueCat reports a refund — is logged, and the GoCommerce order keeps reading as paid.