Use cases

Each use case names the API, the way money moves, the calls in order, and the compliance points that apply. Every case assumes the customer has passed verification (KYB or KYC) and is not in a prohibited activity or jurisdiction.

1. A B2B platform gives each merchant its own US account details

API: SET API (Platforms) · Way: 3, collect to the bank (or 1, to a wallet)

A software platform for, say, recruiting agencies or freight brokers wants every client business to receive ACH and wire payments in its own name, and have them land in that business's own bank.

1. POST /v1/customers with type: "business"; send the merchant the returned tosLink and kycLink.
2. Wait for customer.updated with status: "approved" (or poll GET /v1/customers/{id}).
3. POST /v1/payment_setups with way: "bank" and the merchant's bank details.
4. Give the merchant payTo.depositInstructions; its payers pay those numbers.
5. Watch deposit.* and cash_out_payment.payment_processed; the second means the merchant's bank was paid.

Compliance: the platform names each payer with POST /v1/deposits/{id}/sender (Travel Rule). Third-party payers follow the provider's rules for virtual accounts (Third parties). The platform never receives or holds merchant funds unless SET has approved platform funds for it in writing (Platform oversight).

2. A payment service provider settles merchants in stablecoin

API: SET API (Platforms) · Way: 1, collect in stablecoin

A regulated PSP (for example a Swiss financial intermediary affiliated to a self-regulatory organisation) collects USD, EUR or GBP bank transfers for its merchants and wants each merchant settled in USDC or EURC to the merchant's own wallet.

1. Customer and approval as above; for EUR or GBP request the sepa endorsement (POST /v1/customers/{id}/endorsements).
2. POST /v1/payment_setups with way: "wallet", currency, asset (for example usdc-base, eurc-base), the wallet address, and beneficiary: {type: "customer", walletType, ownershipVerifiedAt}.
3. Hand the merchant payTo.depositInstructions.
4. Each deposit raises deposit.payment_processed, then deposit.delivered once confirmed on chain.

Compliance: SET's programme applies to the PSP as SET's customer and to every merchant as a verified customer, independently of the PSP's own programme (Platform oversight, Switzerland annex). The wallet's ownership must be verified by the platform before the call (ownershipVerifiedAt).

3. A business takes stablecoin and gets paid in its own currency

API: SET Merchant API (or SET API) · Way: 2, cash out stablecoin

An online seller, agency or software company accepts USDC from customers worldwide and wants USD by ACH (or EUR by SEPA, GBP by Faster Payments) in its own account.

1. POST /v1/payment_setups with way: "cash_out" and bankAccount.
2. Publish payTo.address (the Cash-Out Address) on invoices, with payTo.minimumPayout.
3. Each payment raises cash_out_payment.*; paidToBank: true once the bank is paid.

Compliance: any wallet may pay a Cash-Out Address, so SET names each sender per payment: through POST /v1/cash_out_payments/{id}/sender, or for merchants SET onboarded without a key, through saved payers and single-use payer links (Payer links). An open address that accepts payments from unknown senders is disclosed to the provider as a product model.

4. A bounty, audit or contest platform pays US winners in dollars

API: SET Direct Deposit API

The platform keeps paying USDC on Base or Ethereum. A US payee opens a SET Wallet, verifies, links their bank and gets a Cash-Out Address; the platform pays it like any wallet and the payee receives dollars by ACH.

1. The payee gives the platform their Cash-Out Address. The platform checks it with GET /api/partner/address.
2. The platform pays it from a sender wallet it registered with SET.
3. SET reads the sender on chain, submits the platform as the Travel Rule originator, and the payout reaches the payee's bank.
4. GET /api/partner/statement?month= shows payouts paid and the platform's share of SET's fee.

5. Pay someone by email before they have a wallet

API: SET Direct Deposit API (Payable Email)

1. POST /api/partner/payees with the payee's email and chain: "base".
2. claimable: pay the returned wallet, then POST /api/partner/payments with the transaction hash. direct: pay the returned Cash-Out Address. invited: no address; the person already has a SET Wallet and must grant your platform.
3. The payee claims once; afterwards every payment from that platform goes straight to their bank.

Compliance: the email goes to the wallet provider only. An invited answer is not consent to contact the person (KYC policy, Privacy Policy §2).

6. Move between stablecoins or chains

API: SET API or SET Merchant API · Way: 4, convert crypto

A treasury or marketplace receives USDC on Base and needs USDC on Solana, or EURC.

1. GET /v1/conversion_routes for the pair and its minimum.
2. POST /v1/conversion_addresses with the destination {asset, address, beneficiary}.
3. Payments raise conversion_payment.* and conversion_payment.delivered.

7. Dollars in, euros out

API: SET API or SET Merchant API · Way: 3 with a SEPA bank

A European merchant sells to US buyers. POST /v1/payment_setups with way: "bank", currency: "usd" and an EUR bankAccount (IBAN): US payers pay a US account; the merchant receives euros by SEPA. SET's fee is taken once. No rate is locked: GET /v1/exchange_rates?from=usd&to=eur&amount= gives an estimate only.

What SET does not support

• Payments to a bank account that is not the customer's own (supplier payouts, payroll to third parties) through a Cash-Out Address: every address pays the customer itself.
• Games of chance, gambling, sweepstakes, lotteries and every other prohibited activity.
• Customers whose principal residence or operating address is in New York, or in a prohibited jurisdiction.
• Locked exchange rates; RTP (FedNow is offered); USDT on Tron.