Payment sessions page

A Payment session is a single-charge checkout — a customer pays you a fixed amount, once. Recurring charges live under Subscriptions instead.

The Payment sessions page shows every session your account has ever created, most recent first. If you accept payments through a hosted checkout, an embedded checkout, an invoice link, or a storefront product, they all land in this table.

The layout

At the top:

• KPI cards. Total sessions, confirmed count, pending count, and gross value in USD. Test-mode counts stay small because you're seeing Testnet activity only.
• New session button. Opens a dialog for creating a session manually — same fields the API takes. Useful when you want a one-off payment link without wiring your app.
• Export CSV. Downloads the visible rows for accounting.

Below, a searchable table with one row per session.

Reading a row

Each row shows:

• Amount and stablecoin (USDC or EURC)
• Status — pending, succeeded, or expired
• Customer email — the address the payer entered at checkout, if any
• Payer wallet — the on-chain address that signed and paid, if the session confirmed
• Session id — click it to open the session detail page
• Created — relative time

The row is a link. The detail page shows:

• The full session envelope, including on-chain fields (chainMerchantId, token address, contract address)
• The confirmed transaction hash, linked to the block explorer
• Every webhook delivery this session triggered
• The receipt email history sent to the payer

Statuses explained

Pending. The session was created but nothing has been paid yet. Sessions expire after a configurable window (default 30 minutes); on expiry they move to expired.

Succeeded. The indexer saw a matching on-chain transaction and confirmed it. The payment.completed webhook fires. If the payer left an email, a receipt goes out via the payer notifier cron.

Expired. No matching on-chain transaction landed before the expiry window. Firing again just means starting a new session; the old one stays in the table for audit.

Common workflows

A customer says they paid but the session is still pending. Check the payer wallet field — is it populated? If yes, the indexer has already linked the transaction and the row is probably one refresh behind. If no, either the customer paid to the wrong address (unlikely if they used your checkout) or the transaction hasn't confirmed on-chain yet. Give Arc Testnet's confirmations window (~30s) time; if it's been minutes, click into the detail page and inspect the raw envelope.

I need to reconcile Strimz revenue with accounting. Use Export CSV. Filter by status = succeeded and the date range you're closing.

I want to create a session from the dashboard without touching the API. Click New session, fill in the amount, currency, and (optionally) customer email + description, and submit. The dialog returns a checkout URL you can paste into an email or chat.