Selltics Docs

English

Русский

English

Русский

Appearance

Payments provider ​

Updated

What a merchant of record is, and how Paddle Billing models what it sells, its API environments and its webhooks.

As Paddle publishes it

The subject matter as Paddle publishes it. Nothing on this page describes a particular application; every statement restates the public documentation listed under Sources.

In short ​

  • Paddle acts as a merchant of record: the buyer buys from Paddle.
  • Paddle Billing models products, prices, customers, transactions, subscriptions and adjustments.
  • Sandbox and live are separate accounts with separate keys, data and dashboards.
  • Paddle sends signed notifications; a delivery succeeds only on HTTP 200 within five seconds.

Merchant of record ​

  • A merchant of record is the legal seller in a sale.
  • Paddle acts as one: the buyer buys from Paddle, which resells the software on the vendor's behalf.
  • Paddle therefore calculates, collects and remits sales tax and VAT, processes the payment, issues the invoice, handles refunds, chargebacks and fraud, and pays the vendor out after deducting its fees.

The Paddle Billing model ​

  • Product — what is sold, with a tax category (for example standard or software as a service) that decides how tax is applied.
  • Price — an amount and currency for a product, one-time or recurring.
  • Customer — the buyer, with addresses and businesses.
  • Transaction — one checkout or invoice: the items, the totals with tax, and the payments made against it.
  • Subscription — a recurring agreement that creates transactions on each billing cycle.
  • Adjustment — a change to a completed transaction: a refund or a credit.

Checkout runs in the browser through Paddle.js (an overlay or an inline frame) and is opened for a transaction.

Before the first transaction

A default payment link must be set in the checkout settings before transactions can be created, and the domains a checkout runs on must be approved.

API and environments ​

  • The REST API authenticates with an API key sent as a bearer token. Keys carry permissions per entity.
  • Sandbox and live are separate accounts with separate keys, data and dashboards: the sandbox API is sandbox-api.paddle.com, the live API is api.paddle.com.
  • In the sandbox, Paddle's test cards complete a checkout without moving money.

Webhooks ​

  • Paddle sends notifications for events such as transaction.completed or adjustment.updated to notification destinations configured in the account; each destination has its own secret key.
  • Every notification carries a Paddle-Signature header with a timestamp and an HMAC-SHA256 signature of the timestamp and the raw request body, made with the destination's secret key. The receiver recomputes it and rejects a mismatch or a stale timestamp.
  • A failed notification can be replayed from the dashboard.

Answer within five seconds

A delivery counts as successful only when the receiver answers HTTP 200 within five seconds; any other outcome is retried on a schedule (a few attempts over minutes in the sandbox, many over days in live).

In this section ​

  • Merchant of record — what a merchant of record is and which liabilities it takes on
  • Paddle facts — prerequisites, keys and versions, sandbox, transactions, webhook signatures and retries

Sources ​