Test Mode

Every new Plirin account starts in test mode. It’s not a demo state layered on top of the real product — it’s the same dashboard, the same checkout, the same settlement logic, running on testnets instead of mainnets. You can build your entire integration, invoice a fake customer, and watch a payment settle before you ever connect a real wallet or complete verification.

This guide covers what test mode separates in the dashboard and the guided first payment. For how the switch itself works, what unlocks live mode, and how API keys interact with your dashboard mode, see Test and Live Mode.

What test mode separates

Once you flip the switch in the sidebar, the dashboard becomes mode-aware. Everything you see is scoped to whichever mode is currently active:

Transactions and invoices — the lists only show records that belong to the current mode. A payment is classified by its chain (any chain id containing mainnet is live; everything else, including devnet/sepolia/amoy, is test).
Dashboard KPIs and analytics — revenue, transaction counts, the revenue time series, and payment mix are all computed only from the current mode’s records, so a morning of testing never inflates your real numbers.
CSV exports — invoice exports are filtered the same way, so test rows can’t end up in your accounting software.
Refunds and credit notes — follow whichever mode their parent transaction or invoice belongs to.
Attached files: a file on a test invoice or estimate is a test file: it is only visible in test mode and is never shown on a live document or to a live API key. Test files do use the same plan storage as live ones, so remove the ones you no longer need. See Attachments.

If a list looks emptier than you expect, check for a small hint above it — “N test payments hidden — switch to test mode” (or the live-mode equivalent). It only appears when the other mode actually has records, and it’s one click to switch.

While you’re in test mode, a strip reading “Viewing test data” stays visible across list pages with a Switch to live action beside it, so it’s never ambiguous which world you’re looking at and you never have to go hunting for the toggle.

What test mode does not separate

Test mode is a dashboard filter and a settlement guard, not a second account. A few things are deliberately shared:

Public payment links and checkout pages stay payable regardless of your dashboard’s current mode. A checkout page doesn’t check what mode your dashboard is currently in — a customer who opens a link you sent them can pay it whether you’re currently viewing test or live. The environment filter is a merchant-dashboard concern only; it never hides or blocks a payer-facing page.
Customers are not environment-scoped. A customer’s existence isn’t itself test or live data — the same way a product or coupon isn’t. Your Customers list shows everyone regardless of mode; only the payment history tied to each customer respects the filter.
The dashboard’s subscription views are not filtered by mode. Each subscription does belong to an environment, the one it was created in, and it collects on that environment’s networks only. But the Subscriptions list and subscription metrics (MRR, active subscribers, churn) in the dashboard show subscriptions of both environments. An API key sees only its own environment’s subscriptions and figures. See Test and Live Mode.

Try a payment: the guided first-run flow

If you’re new and haven’t taken a test payment yet, your dashboard shows a “See your product work — right now” card. It walks you through the entire flow without requiring an API key or any code:

Click “Try a test payment.” Plirin creates a real payment link — the exact hosted checkout page a customer would see — for a small fixed amount ($12.00 USDC) on Solana devnet.
See the actual checkout page. You get the real link and QR code. You can pay it yourself with a devnet wallet if you have one, or skip straight to simulating it.
Click “Simulate the customer paying.” This settles the payment for real, on the test network’s data path — no wallet required.
Watch it confirm. The card celebrates with “Payment confirmed — this is exactly what a real sale looks like,” and links to the transaction, adding a product, and starting verification for live payments.

The card disappears permanently once you have any test transaction — it isn’t a dismissible flag, it’s derived from whether you’ve done this yet.

What simulating a payment actually does

The “simulate” button calls a dedicated mutation that settles a transaction with no money moving. It is not a shortcut around the real settlement path — it drives the same confirmation logic a genuine on-chain payment uses, so webhooks, the invoice flip to paid, and inventory decrements all behave identically to a real payment.

Simulation is refused unless all four of the following hold, checked in this order:

Refusal	Why
Your account is in test mode	Simulating on a live account would mint fake settlement on a dashboard someone might mistake for real revenue.
The transaction belongs to your account	Checked before revealing anything about a transaction’s chain or status.
The transaction’s chain is not mainnet — or is unknown	A pending transaction’s chain is resolved from its wallet, payment link, or invoice. If none of those can name a chain, simulation refuses rather than assume an unknown chain is safe to settle.
The transaction is still pending	Simulating an already-confirmed, expired, or held transaction would double-fire the settlement side effects.

Any failure leaves the transaction completely untouched — no partial writes.

On success, the row is permanently marked as simulated. This can never be cleared:

A “simulated” badge shows on the transaction in the dashboard.
The simulated field is true on the related webhook payload.
Simulated volume never counts as organic revenue in future analytics.

A simulated payment also writes its own audit log entry, with the actor, transaction reference, and amount — simulation is a first-class audited event, not a backdoor.

How to go live

Test mode covers everything you need to build and demo your integration. When you’re ready to accept real payments:

Complete business verification (KYB) from the dashboard.
Once verified, switch the sidebar toggle from Test to Live.
Connect a real payout wallet, if you haven’t already.

Live mode does not stop you from also taking testnet payments — it only unlocks mainnet. Your test-mode history stays exactly where it is, filtered out of your live views, permanently distinguishable from real activity.