Paddle

• Confirm the webhook URL in your Paddle Notifications matches the one shown in PayLexer exactly, with no trailing slash differences

• Verify the webhook destination is set up in both Paddle Sandbox and Paddle Production dashboards

• Check that all required event types are subscribed in Paddle

• Confirm the Webhook Secret in PayLexer matches the signing secret from the Paddle notification destination — a mismatch causes all webhook events to be rejected

• Paddle signs events with a timestamp and HMAC — ensure your server clock is accurate. Signatures older than 30 seconds are rejected by PayLexer

• This is expected behavior immediately after checkout. Paddle creates a transaction first (txn_xxx) and converts it to a subscription (sub_xxx) once payment is confirmed

• The permanent subscription ID arrives via the subscription.created webhook, which PayLexer processes automatically

• If the sub_xxx ID never appears, check that the subscription.created event is subscribed in your Paddle notification destination and that webhooks are being received

• Confirm you are using a sandbox API key with Test mode enabled in PayLexer, and a production API key with Test mode disabled

• API keys and client tokens are environment-specific — a sandbox key does not work against the Paddle production API

• Check that the API key has All permissions scope in the Paddle dashboard

• If you regenerated a key in Paddle, update the saved value in PayLexer — old keys are revoked immediately upon regeneration

• This usually means the transaction.completed or subscription.created webhook was not received

• Check the Paddle Notifications dashboard for failed delivery attempts and re-send them manually if needed

• Confirm your PayLexer webhook URL is publicly reachable (not localhost) when testing outside of Paddle's sandbox

• Paddle acts as the merchant of record and calculates tax automatically based on the customer's location

• You do not control tax rates directly — they are determined by Paddle based on your product's tax category and the buyer's country

• Verify the tax_category on your products is set to the correct value (for most software, standard is correct)

• Contact Paddle Support if tax calculations appear incorrect for specific countries

Live credentials are mandatory to save the configuration. Test credentials are optional but highly recommended so you can safely test payments before going live.

Check the Debug Mode setting in your platform. When Debug Mode is ON, PayLexer uses your Test credentials. When OFF, it uses Live credentials.

Transactions appear in three places: your platform's booking or order pages, PayLexer Dashboard → Orders, and Paddle Dashboard. All three show the same transactions with different IDs.

Payments will still process, but status updates may be delayed. Check webhook event logs in the Paddle Notifications dashboard. Ensure the webhook URL is correct, the signing secret matches, and all required events are subscribed.

Yes. Paddle operates as your merchant of record, which means it is legally responsible for collecting and remitting VAT, GST, and sales tax in all countries where it sells on your behalf. You do not need a separate tax provider or register for tax in each country.

The client token is a public, browser-safe credential that Paddle's checkout JavaScript uses to initialize the payment widget in the customer's browser. It is separate from your API key (which must stay server-side only). Both are required — the API key creates the transaction server-side, and the client token renders the checkout on the frontend.

Paddle's checkout flow creates a transaction first. When a customer completes payment, Paddle converts the transaction into a subscription and fires a subscription.created webhook containing the permanent sub_xxx ID. PayLexer receives this webhook and updates the subscription record automatically. The txn_xxx value is a transient state that lasts only until the webhook arrives.

Yes. PayLexer supports both one-time and recurring (subscription) payments through Paddle. Subscription plans with a recurring interval use Paddle's native subscription billing. One-time payments create a standard Paddle transaction with no billing cycle attached.

Paddle moves the subscription to past_due status and retries the payment according to its retry schedule. PayLexer receives the subscription.updated event and updates your subscription record accordingly. If all retries fail, Paddle cancels the subscription and fires a subscription.canceled event, which PayLexer also processes automatically.

Yes. PayLexer supports pausing a subscription (which takes effect at the next billing period) and resuming it immediately. Paddle sends subscription.updated events for both actions, which PayLexer uses to keep the subscription status in sync.