Paybytoken overview
Understand the Paybytoken stablecoin checkout model and choose an integration path.
Paybytoken gives merchants one stablecoin payment lifecycle for application-owned checkout, reusable payment pages, customer receivables and merchant-scoped customer balances. Every funds movement is server-authenticated, mode-isolated and observable through signed events.
Choose the right resource
Read Payment resource model for the complete relationship between customer-facing checkout, durable collection resources and the underlying Payment Intent.
| Need | Start with | Why |
|---|---|---|
| Collect one application order | Checkout Session | One order and one customer checkout attempt. |
| Offer stablecoin, card and wallets for one order | Payments Router | One provider-neutral Payment with server-owned routing. |
| Share a reusable page | Payment Link | Fixed or customer-entered amount without creating each order first. |
| Collect one named receivable | Payment Request | Due date, reminders, retries, partial allocation and reconciliation. |
| Hold customer-owned funds | Customer balances | Persistent deposits, exact-asset balances, internal payments and withdrawals. |
| Let a Paybytoken consumer approve | Paybytoken Pay | Private-beta consumer authorization from a Paybytoken balance. |
Choose how checkout appears
| Integration | What the customer sees | Choose it when |
|---|---|---|
| Hosted checkout | A responsive Paybytoken payment page opened by redirect. | You want the fastest launch and the least frontend code. |
| Embedded checkout | The payment flow mounted inside your own page. | You want customers to stay inside your product. |
| Custom checkout | Your own currency, chain and transfer interface backed by Paybytoken sessions. | You need complete UI ownership and can build every customer state. |
Start with hosted checkout or follow the embedded checkout quickstart. Use custom checkout when your product must own the complete interface. You can switch presentation modes without changing how your server defines prices or fulfills an order.
Checkout is one presentation layer within this model; it does not replace the Payment Intent, balance, refund, event or reconciliation records used by the server.
The payment lifecycle
Every Checkout integration follows the same boundary:
- Create the order on your server. Authenticate the customer, load products and prices from your database, then create a Checkout Session with a secret API key.
- Present checkout in the browser. Redirect to
session.url, mount the embedded SDK with its session-scopedclient_secret, or render your own custom interface from browser-safe session fields. - Let the customer choose a token and network. Paybytoken creates payment instructions only after the customer confirms the selection.
- Watch for the transfer. Paybytoken tracks the selected network and updates the Payment Intent as the transaction progresses.
- Fulfill from a verified event. Your server verifies a signed
payment_intent.succeededwebhook and processes the order exactly once.
Browser redirects and SDK completion events improve the customer experience, but they are not proof of payment.
What Paybytoken owns
Paybytoken provides:
- hosted and embedded checkout, plus session and confirmation APIs for custom interfaces;
- enabled token and network selection;
- connected-wallet and manual transfer instructions;
- one-time payment destinations and payment status tracking;
- merchant checkout branding;
- server SDKs, browser SDKs and React bindings; and
- signed webhook delivery for reliable fulfillment.
Your application remains responsible for:
- authenticating the customer;
- defining the authoritative order, quantity and price;
- deciding which products or services to fulfill;
- storing API and webhook secrets securely; and
- handling refunds, support and business-specific reconciliation.
Credentials stay in their runtime
| Credential | Where it belongs |
|---|---|
sk_test_... / sk_live_... | Your server only |
chk_client_... | The matching embedded checkout page, in memory |
| Checkout Session CSRF token | Your server only, bound to the matching custom session |
whsec_... | Your webhook handler only |
Never place a merchant secret key in browser code. Never send a price, token contract or destination address from untrusted browser input to your API unchanged.
Start building
- Follow Get started for the shortest end-to-end integration.
- Learn how orders, Sessions and payment attempts fit together before deciding how retries work in your application.
- Compare all three modes in the Checkout overview.
- Build a merchant-owned experience with Custom checkout.
- Learn the API authentication model.
- Read Fulfill orders with webhooks before accepting live payments.
- Use Payment operations for support, refunds, ledger reconciliation and asynchronous transfer investigation.
- Use the go-live checklist to move from test keys to production without reusing test resources or browser credentials.
- Publish a reusable page with Payment Links.
- Build stored customer funds with Customer balances.
- Test single-item, multi-item and custom-amount checkout in the Paybytoken Playground.
Did this page answer your question?
Your feedback helps us improve the integration path.