Skip to content
Plinth
Create account

Use cases

Five ways to take USDC, each on real product objects

Every flow below uses surfaces and API objects that exist today. Where something does not exist yet, the section says so. The data in the pictures is sample data, not a customer.

Online stores

Create one payment per order, send the customer to the checkout page, and release the order when a verified webhook says the funds are final.

  1. 1Your backend creates a payment intent with the order reference and success URL.
  2. 2The customer opens checkout_url and pays by wallet or by sending USDC to the unique address.
  3. 3Plinth verifies the transfer and waits for finality, then sweeps it into your vault.
  4. 4Your webhook handler fulfils the order on payment.confirmed, or strictly on payment.completed.
payment_intent
amount, order_reference, success_url, cancel_url, expires_in_seconds, metadata
webhook event
payment.confirmed, payment.completed, payment.underpaid, payment.late
POST /v1/payment-intents
Idempotent via Idempotency-Key

Not today: There are no store plugins yet. You call the API from your own backend.

Payment detailSample data

order_reference

order-1042

Settled
25.00USDC
Paid on
Arc Testnet
Deposit address
0x7Ac3…1e02
Webhook sent
payment.confirmed

SaaS and subscription billing

Bill each period as its own payment. Because a customer pushes USDC from their own wallet, Plinth cannot pull a recurring charge, so your scheduler creates the payment and sends the link.

  1. 1At each renewal your scheduler creates a payment intent with the customer email and a period reference.
  2. 2You send the checkout link yourself. Plinth does not send email.
  3. 3The webhook marks the period paid. An expired or underpaid intent tells you to follow up.
  4. 4Overpayments and late payments arrive as their own events, so nothing is silently absorbed.
payment_intent
amount, customer_email, order_reference, expires_in_seconds
webhook event
payment.confirmed, payment.expired, payment.overpaid
GET /v1/payments
List and search payments by reference

Not today: No subscription object, no auto-charge and no dunning exists. Recurrence lives in your system.

Payments for one customerSample data
  • sub_204-2026-0849.00USDCSettled
  • sub_204-2026-0949.00USDCSettled
  • sub_204-2026-1049.00USDCAwaiting payment

Each period is a separate payment intent that your own scheduler creates, with its own checkout link.

Freelancers and small marketplaces

Send a numbered invoice with line items and a due date. The customer pays from the invoice link and you see settlement in your own vault.

  1. 1Create an invoice from the dashboard or the API with the customer and line items.
  2. 2Share the invoice link. Invoices are not emailed by Plinth yet.
  3. 3The customer pays by wallet or address; partial payments add up until the invoice is covered.
  4. 4The invoice moves to paid when the verified, final total reaches the amount.
invoice
customer_name, customer_email, memo, due_in_days, line_items[description, quantity, unit_amount]
POST /v1/invoices
Idempotent; returns the invoice and its payment
refund request
A refund is a transfer you send from your vault, then prove with its hash

Not today: There is no split payment or sub-merchant API. A marketplace would give each seller their own account, or pay sellers from its own vault.

InvoiceSample data

Billed to

Customer name

customer@example.com

Awaiting payment
Invoice line items
DescriptionQtyUnit
Brand identity, phase one11,200.00
Revision rounds2150.00
Total, due in 14 days1,500.00USDC

Platforms and agencies

Give each team the access it needs, keep every API call and webhook attempt on record, and let a client's own multisig own the vault.

  1. 1Each client or project signs up and creates a vault owned by an address the client controls.
  2. 2Teammates get an owner, admin, developer or viewer role.
  3. 3Developers create API keys, register webhook endpoints and inspect every delivery attempt.
  4. 4The audit log records sensitive actions, with secrets and signatures redacted.
team member
email, role (OWNER, ADMIN, DEVELOPER, VIEWER)
api key
a test key for testnets, a live key for mainnets; shown once, rotatable
webhook endpoint
https only; signed with Plinth-Signature; manual retry from the log

Not today: Each account is isolated. There is no multi-account console for agencies yet.

Team and webhook logSample data
  • OwnerEverything; only role that can add owners
  • AdminWallets, team, settings, payments, developer tools
  • DeveloperPayments, API keys, webhooks
  • ViewerRead only
  • payment.confirmed200
  • payment.completed200
  • settlement.failed503, retry scheduled

Donations and tips

Publish a payment link with a fixed amount. Each visit opens a fresh payment, so one link can take any number of payments.

  1. 1Create a payment link with a name, a fixed amount and an optional success URL.
  2. 2Share the link anywhere. No code or backend is needed.
  3. 3Opening the link creates a new payment and sends the visitor to the checkout page.
  4. 4Funds land in your vault; the dashboard lists every payment under that link.
payment_link
name, amount, description, success_url, intent_expires_in_seconds
POST /v1/payment-links
Idempotent; PATCH to switch a link off
payment_intent
One is created each time the link is opened

Not today: Amounts are fixed. For several tip sizes, create several links. There is no pay-what-you-want amount yet.

Payment linkSample data

Support the studio

Fixed amount, reusable

5.00USDCPay 5.00 USDC
/l/support-the-studioOpening it creates a fresh payment

Try the flow that matches yours

Everything here runs on testnets today. Create a free sandbox account and make your first test payment.

Open the demoRead the API docsSee integrations