SET Merchant API

For a single business that SET onboards directly. The business holding the key is itself SET's customer; no platform sits between SET and it. It uses the same /v1 calls as the SET API, for exactly one customer: itself.

What differs from a platform key

	SET Merchant API (merchant key)	SET API (platform key)
Customers	One: the merchant. `POST /v1/customers` takes `externalId: "self"` (or none); `name` must match the legal name SET registered	Many: one per merchant
Destination wallets	Always the merchant's own; `beneficiary.type: "platform"` is refused (`400 beneficiary_invalid`)	The merchant's own unless platform funds are allowed
Return address	The merchant registers its own default once (`POST /v1/return_addresses`)	None by default; `returnAddress` required per address
`GET /v1/ping`	`kind: "merchant"`	`kind: "platform"`
Payer details	`/sender` calls, or automatic saved payers and payer links	`/sender` calls

Everything else (the four ways, EUR and GBP, events, webhooks, reports, fees) works the same.

Two ways to onboard

With a key, for a merchant that automates: SET registers the business with its exact legal name, address and tax identifier and issues a set_live_ key; the merchant calls POST /v1/customers with type and email and completes the hosted KYB.
Without a key, through SET's operator order form: SET's operator registers the business, starts its verification and opens its accounts. The merchant receives printed hand-over instructions and never touches the API.

A merchant already verified under SET's account is never verified twice: the order form reuses an approved verification after checking the legal name, status and endorsements.

Compliance

The merchant passes SET's KYB and the provider's hosted KYB. Its money must be its own: a merchant may not use SET to receive or pay money on behalf of others, operate an exchange, or carry on any prohibited activity. Disclosed high-risk activities require enhanced due diligence and SET's written approval before go-live.

SET Invoices (merchant keys only)

A merchant issues invoices (POST /v1/invoices); SET matches the payment that arrives (a unique stablecoin amount, or the invoice number as a bank reference), names the invoice's payer for the Travel Rule, and writes balanced journal entries the merchant reads by webhook, GET /v1/journal_entries or a CSV export. Matching only labels money; it never changes where money goes. A platform key is refused (403 invoices_merchant_only).

Calls

The calls are the SET API's, shown in the sidebar with the merchant-specific behaviour of each, plus Invoices. And: