PaybytokenDocs
Guide

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.

NeedStart withWhy
Collect one application orderCheckout SessionOne order and one customer checkout attempt.
Offer stablecoin, card and wallets for one orderPayments RouterOne provider-neutral Payment with server-owned routing.
Share a reusable pagePayment LinkFixed or customer-entered amount without creating each order first.
Collect one named receivablePayment RequestDue date, reminders, retries, partial allocation and reconciliation.
Hold customer-owned fundsCustomer balancesPersistent deposits, exact-asset balances, internal payments and withdrawals.
Let a Paybytoken consumer approvePaybytoken PayPrivate-beta consumer authorization from a Paybytoken balance.

Choose how checkout appears

IntegrationWhat the customer seesChoose it when
Hosted checkoutA responsive Paybytoken payment page opened by redirect.You want the fastest launch and the least frontend code.
Embedded checkoutThe payment flow mounted inside your own page.You want customers to stay inside your product.
Custom checkoutYour 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:

  1. 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.
  2. Present checkout in the browser. Redirect to session.url, mount the embedded SDK with its session-scoped client_secret, or render your own custom interface from browser-safe session fields.
  3. Let the customer choose a token and network. Paybytoken creates payment instructions only after the customer confirms the selection.
  4. Watch for the transfer. Paybytoken tracks the selected network and updates the Payment Intent as the transaction progresses.
  5. Fulfill from a verified event. Your server verifies a signed payment_intent.succeeded webhook 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

CredentialWhere it belongs
sk_test_... / sk_live_...Your server only
chk_client_...The matching embedded checkout page, in memory
Checkout Session CSRF tokenYour 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

On this page

API Workbench

Full Explorer

Open in new tab