Skip to content

Developers

A small API you can hold in your head

Four endpoints, JSON over HTTPS, authenticated with a wallet signature. No SDK to install, and nothing proprietary in the payment path — the QR is a standard EIP-681 URI.

Read the docsTry it in the UI

Shape of it

What you can build

Invoice automation

Generate a link per invoice from your billing system, embed the QR in the PDF, and reconcile from the transaction hash.

Point of sale

Create a link at the till, display the QR, and poll status until it reads paid. The whole loop is two calls.

Storefront checkout

Redirect to the hosted checkout with your order id attached, then confirm settlement server-side before you fulfil.

Authentication

Sign in with a wallet, get a session

There are no API keys yet. A client requests a nonce, signs an EIP-4361 message with the merchant wallet, and exchanges it for an HttpOnly session cookie used on subsequent calls.

1. Request a challenge
POST /api/auth/nonce

{
  "nonce": "81e7e88266f6808b65545814f1550ce8",
  "expiresAt": "2026-09-09T02:56:46.709Z",
  "statement": "Sign in to Droppy..."
}
2. Exchange a signature
POST /api/auth/verify

{
  "message": "<the EIP-4361 message you signed>",
  "signature": "0x..."
}

→ 200, Set-Cookie: droppy_session=...

Nonces are single-use and expire in ten minutes. The server checks domain, origin, statement, chain and timestamps before the signature, so a signature captured elsewhere will not work.

Endpoints

The whole surface

POST /api/links
Create a payment link. Session required. Returns the link with its id and exact base-unit amount.
GET /api/links
List your own links, newest first. Scoped by session, not by a parameter.
GET /api/links/:id
Public. What a payer needs: amount, asset, chain, address, status.
POST /api/links/:id/verify
Public and idempotent. Submit a transaction hash; the server reads the chain and returns the settled status.
GET /api/merchant · PUT /api/merchant
Read and update your own profile and defaults.

Parameters, errors and rate limits →

Polling

Confirming settlement from your backend

There are no webhooks yet. Poll the verify endpoint with the hash your customer paid with; it is idempotent, so repeated calls are safe and always converge on the same answer.

  • Budget is 60 requests per minute — a few seconds between polls is plenty.
  • 202 means confirming, 200 with ok means settled, 422 means it failed and why.
  • Never fulfil an order on a 202. Wait for the paid status.
POST /api/links/:id/verify
{ "txHash": "0x8f3a...c41d" }

→ 200
{
  "ok": true,
  "status": "paid",
  "from": "0x1c9d...77aE",
  "paidBaseUnits": "250000000",
  "blockNumber": "57938764",
  "confirmations": 4
}

Network

Connection details

Chain
Robinhood Chain mainnet — chain id 4663
RPC
https://rpc.mainnet.chain.robinhood.com
Explorer
https://robinhoodchain.blockscout.com
Native asset
ETH, 18 decimals
USDG
0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168, 6 decimals
Testnet
Chain id 46630 — https://rpc.testnet.chain.robinhood.com

Build your first integration

Create a link in the dashboard, then reproduce it with a single POST.

Create Payment LinkSee how it works