Accept payments

Get paid into a wallet you control, through a dashboard payment link or a shared address, and find each payment.

To accept a payment, the payer sends tokens to one of your custody wallets and you find that payment. Send a payment link from the dashboard, or share a wallet address and detect payments yourself. Verifying a payment covers when a payment is final, and Indexing and reconciliation covers listing and matching.

Payment requests

In the dashboard, open Payments > Requests, click New, and set the amount, token, destination wallet and when the link expires. You get a link and a Solana Pay QR code that anyone can pay, and SDP pays the network fee for the payer's transaction. Each request gets its own Solana Pay reference, which SDP watches to see when the request is paid.

When a request is paid, SDP records an inbound finalized transfer with kind: request_deposit, which GET /v1/payments/transfers?direction=inbound returns. Create one in the dashboard or with POST /v1/payments/requests, and cancel it with POST /v1/payments/requests/{paymentRequestId}/cancel.

Share a wallet address

Give the payer a custody wallet's Solana address. Copy it from Payments > Deposit, or read publicKey from GET /v1/wallets/{walletId} (add includeBalance=false to skip the balance read). The payer sends an ordinary SOL or SPL transfer from any wallet. To offer a QR code, build a Solana Pay URL from the address, token mint and amount yourself.

SDP does not record these payments. You see them through GET /v1/payments/transfers with that wallet's custodyWalletId and includeObserved=true, which reads the wallet's recent on-chain history. These observed rows carry no memo or reference, and they never reach finalized; see Observed transfers.

Match payments to orders

An observed payment's on-record keys are the wallet it landed in and its destination. To tell payments apart, give each order (or each customer) its own receiving wallet. One wallet per merchant, seller or ledger account works when you don't need to match single payments, such as treasury or settlement flows. To correlate by memo or Solana Pay reference instead, read the transaction from Solana RPC by its signature.

What SDP gives you

  • Payment links: payment requests, from the dashboard or POST /v1/payments/requests, recorded as inbound transfers once paid.
  • Observed payments: a wallet's recent on-chain activity, from GET /v1/payments/transfers?custodyWalletId=…&includeObserved=true. See Indexing and reconciliation.
  • Status reads: GET /v1/payments/transfers/{transferId} for one recorded transfer. See Verifying a payment.
  • Balances: GET /v1/payments/wallets/{walletId}/balances, where walletId is the provider wallet id (walletId from GET /v1/wallets). See Wallet balances.

What SDP does not give you

  • No checkout or payment-intent API: a payment request is the only object you create ahead of a payment. Match payments to a shared wallet address against the order records you keep.
  • No settlement webhooks: poll for status. See Polling cadence.

Example: a marketplace checkout

A minimal accept flow on per-order wallets:

  1. At checkout, create a custody wallet for the order, or take one from a pool you keep. Store its id, its publicKey, the token and the expected amount on your orders row.
  2. Show the payer the address, token and amount, or a Solana Pay QR code you build from them.
  3. The payer's wallet sends the transfer.
  4. Your worker polls each open order's wallet with custodyWalletId and includeObserved=true, and looks for an inbound transfer whose token and amount fit the order. Observed reads have their own quota, so space the polls out.
  5. Check with Solana RPC that the transfer's signature is finalized, then mark the order paid. Store the signature so a rerun of the worker never applies the payment twice.

Treat your orders table as the checkout state machine and SDP as the wallet and settlement backend.

Next steps