Using Payday

Dashboard

The dashboard at payday.sh/dashboard is the browser face of the same API the SDK uses. It issues deposit requests, keeps customers, uploads the one PDF a request may carry, and shows what happened to each one.

It adds no rules of its own. Every limit, policy check, and status comes from the API; the forms only give immediate feedback before the API has the final word. Anything you see in the dashboard, your integration can read through the API, and anything your integration issues appears in the dashboard.

Signing in#

Choose Start Building on the landing page and enter your email. A one-time code arrives; entering it signs you in. There is no separate registration: the first accepted code creates the account, every later one signs into it. Each account gets its own EVM wallet at that first sign-in. It is yours, and it is where deposits settle unless you choose another address.

The session lives in your browser and refreshes while you stay signed in. No API key ever exists in the browser; the dashboard authenticates with the session itself, and the API accepts that on every merchant route.

Your first request#

A new account is not shown a tour. It is put to work on the one thing the product needs first: an issuer identity, the party your requests are issued under. Once one exists with a proven mailbox, issuing follows straight out of it.

Name the identity and its contact address
The name appears on every request as the issuer. The contact address is where payers are told to write, so Payday proves it with an emailed code before any request carries it.
Confirm the code
Enter the six digits sent to that mailbox. The identity is now usable. The flow resumes from wherever it was left, so an abandoned tab reopens at the unfinished step.
Issue
The composer opens in place. When the API answers, the issued link takes its place, ready to copy and send.

The dashboard page#

Signing in lands on /dashboard, which is the whole dashboard: the deposit requests, the identities they are issued under, the customers they are addressed to, the account and its API key, and the flow that issues a new request. There are no section tabs; the only other pages are the detail of one record.

Deposit requests#

A table of every request, five at a time, newest first, with filters for status, verification, and customer. Each filter is the API's own parameter, so it narrows the query rather than the page. A row shows the heading or reference, the payer, the amount with the token's mark, the status, the policy mode, the verification state, the identity it was issued under, and a paperclip when a PDF is attached.

Clicking a row opens it in place. The open row leads with two things a list cannot show: a bar for how much of the amount has arrived, and a three-point rail for how far through its life the request is. Under that, grouped by what you came for:

Section	What it holds
Document	The payer's address and details, the notes, and a link to the saved customer.
Verification	For gated requests: the policy, your assertion, the verdict, and every attempt the payer made with its status and time. Never the code or the session.
Deposit	The one-time address, the payout address, network and token, the funded time, the settlement transaction, and any attention message. Addresses link to the explorer.
Recovered funds	Anything that went back to the payer's wallet, with its transaction and reason.
Payer's view	Exactly what the payer sees, read through the public route. For a gated request, exactly what an unverified visitor would see, so you can check before sending. The shareable link sits beside it, and a preview opens the unlocked page for you alone.
Files	The attached PDF, Payday's own PDF rendering of the request, and, once settled, the Proof of Payment as JSON.

New deposit request#

The only way to issue one by hand, in four steps with a running preview beside them that doubles as the review. Every field POST /v1/deposit-requests takes is here.

Amount. The USDC amount, used directly. The identity when you have more than one, the payout wallet when the identity offers alternatives to your Payday wallet, and the deadline: 24 hours, 7 days, 30 days, or a moment you pick.
Payer. Pick a saved customer, or type the payer fresh and it is saved as one. Then the heading, a reference, notes, and the PDF. The file uploads straight to storage and shows its own stages: uploading, scanning, ready with its size and hash, or rejected with the reason.
Verification. Permissionless, or verified email with the expected address, pre-filled from the payer's email until you type your own. Merchant session is not offered here; it is created through the API by an application that can hand the payer the secret.
Review. Every value as it will be sent, with a plain statement that an issued request is immutable.

Issuer identities#

An identity is your side of a request, saved once instead of retyped: the name, the contact mailbox, and optionally saved payout wallets. An open row is its own form: rename it, move the contact address (which drops the proof, because a different mailbox is a different claim), and attach or drop saved wallets. Names are unique within the account. Editing an identity never changes a request already issued; each request keeps its own snapshot and remembers the identity's id, so "issued under Acme" stays answerable after a rename.

Customers#

A customer is a reusable payer record: name, optional email, optional details. The list pages below the requests. A customer's own page edits it, shows how many requests it has and what they collected, and links to a new request pre-filled from it.

Account and API key#

The foot of the page is the account: the mailbox you signed in with, your Payday wallet in full with its USDC and gas balance read from the public chain, and a sign-out. Below it, the API key section generates, rolls, and revokes the key your own server calls the API with.

Generate shows the key exactly once. Store it in a secret manager.
Roll issues a replacement while the previous key keeps working for 24 hours, so a deployment can move over without downtime.
Revoke invalidates the current key and any key in its grace window at once. Use it for a suspected compromise.

Reading the indicators#

Indicator	Meaning
Status	The deposit's lifecycle state, from awaiting deposit to settled or returned. See the lifecycle.
Verification	Not required, pending, or verified with a time. Separate from status: a gated request can be funded before its payer has verified.
Payer wallet	The wallet the payer signed with, shown beside the address once it exists. Only that wallet's transfers are the payer's.
Likely unsolicited	Finalized funds arrived from a wallet other than the attested one. They count and settle, but no Proof of Payment will claim the payer paid them. Check who actually paid.
Returned to the payer	Present only when something went back: an overpayment remainder, an expired balance, or a late transfer, each with its transaction.