Using Payday

Environments

Two isolated services with the same API. Production settles real USDC on Monad, Base, and Arbitrum One; the sandbox settles Circle's test USDC on their testnets, with its own accounts, keys, and database.

Every deposit request lists the networks it may be paid on, each with its exact USDC contract. The payer picks one on the hosted checkout before signing, unless the request was created with chain_id, which pins the list to that network; from then on chain and token name it. Read them from the response rather than hard-coding them, and show them to the payer: a matching symbol is not enough, and USDC on another network, bridged USDC, and look-alike tokens do not count.

Using the sandbox#

Point the client at the sandbox origin with a test key. Everything else is the same: the routes, the fields, the statuses, the webhooks, the proof.

const payday = new PaydayClient({
  apiKey: process.env.PAYDAY_TEST_API_KEY!,
  baseUrl: "https://api.sandbox.payday.sh",
});

curl -fsS "https://api.sandbox.payday.sh/v1/deposit-requests/dr_…" \
  -H "Authorization: Bearer payday_test_..."

There is deliberately no "mark as paid" button. To settle a sandbox request, open its link as the payer, sign the wallet step, and send test USDC from that wallet. What you then watch is the real pipeline: finalized transfer, credit, settlement, proof.

Status and health#

• GET /health is unauthenticated readiness: ok when the API can reach its database.
• GET /v1/status, with a key, reports each network's finalized position, the indexer's cursor and lag there, and its settlement queue. See Account and status.
• Every response carries X-Request-Id. Quote it to support.