Payment link or checkout API: pick by who starts the checkout.

What is the difference between a payment link and a checkout session?

A Fianto payment link and an API checkout differ in who creates the checkout session: the payer, by pressing the link's button, or your server, by calling the API. A checkout session is one checkout page for one order, open for a limited time, and every Fianto payment runs through one. The hosted checkout the payer lands on is identical either way.

A payment link, at checkout.fianto.xyz/l/ plus 16 random characters, is a standing offer: one price, many payers, made in the dashboard and shared anywhere. The full how-to is in USDC payment links. The API makes one session per order, when your code decides a sale is happening, and returns its URL once.

Payment link vs checkout API, feature by feature

Every row below is how Fianto works on 15 October 2026.

Both need an approved merchant account, both accept a discount code typed on the checkout page, and both sell one-time or recurring prices.

When should you use a payment link?

Use a payment link when you can describe the sale in one sentence with one price in it and nothing in your own system has to change when someone pays. Typical cases:

• A fixed-price consultation, workshop seat or ticket posted in a bio, a chat or an email footer.
• A single monthly plan, where a person can check the Subscriptions list for new members. A recurring payment link covers that case end to end.
• A first test of demand before anyone writes code. A link can go live minutes after approval.
• A limited run: 50 seats, or sales until a date, which the link counts for you.

The trade-off is control. You cannot pass your own order number, you cannot change the amount per buyer, and the only thing tying a payment to a person is their wallet and whatever email they typed.

When do you need the checkout API?

You need the checkout API when the payment must match a record in your system: a cart total, a booking reference, a user account that gets upgraded. Your server sends exactly one of price_id or amount (a string from "0.01" to "1000000" with at most 6 decimals), your order_id, and https success_url and cancel_url. A subscription uses mode: 'subscription' with a recurring price_id. Shortened from the docs' example, with your user ID attached:

import { Fianto } from '@fianto/sdk';

const fianto = new Fianto(); // reads FIANTO_APP_ID and FIANTO_APP_SECRET

export async function startSubscription(userId: string, priceId: string) {
  const session = await fianto.checkoutSessions.create({
    mode: 'subscription',
    order_id: `signup_${userId}`,
    price_id: priceId,
    customer_reference: userId,
    success_url: 'https://example.com/welcome',
    cancel_url: 'https://example.com/pricing',
  });
  return session.url; // send the payer here
}

The API also handles the cases a link cannot: reissuing a checkout URL for an order that already has an open session, cancelling a session, choosing a popup instead of a redirect, and reading every order and subscription back. Fulfil from the webhook, never from the browser: a one-time order sends order.paid once the payment is finalized, and a subscription sends subscription.created, because a subscription creates no order. The checkout sessions docs list every field and error code, and the developers page covers the SDKs for Next.js, Express and Hono, and adding USDC checkout with an AI coding agent shows how a coding agent can write the integration for you.

What stays the same whichever way you sell?

The payment itself does not change with the route. The payer connects a Solana wallet, signs one transaction, and the USDC goes straight to your wallet; Fianto never holds it. You pay nothing. The payer pays a Solana transaction fee under $0.01, no Fianto fee during the beta (after it, about 0.1 to 0.5% on top of your price), and, on a subscription, a network fee of 0.01 USDC with each charge today plus account rent in SOL. Solana's fee documentation puts the base fee at "5,000 lamports per signature".

Sales from both routes appear in the same dashboard lists, the Overview figures and the CSV exports, so your books do not care which one a payment came through. Refunds work the same way too: there is no refund API, and you send USDC back from your own wallet.

Can you start with a payment link and move to the API later?

Yes, and the price you created for the link can be sold through the API from the same day, but the sales already made through the link stay where they are. Three things to plan for:

1. Two webhook endpoints. Link sales belong to the hidden application named "Shop", which appears under Developers after the first press of a link's button. Your API sales belong to your own application. Set a webhook URL on both, and tell link events apart by metadata.source equal to "payment_link" or the plink_ order prefix. The payment link sales docs show the payload.
2. No API control over link subscribers. Every v1 subscription route is scoped to the application that made the sale, and the Shop application cannot hold a secret, so your API key cannot list or cancel a subscription bought through a link. Cancel those in the dashboard.
3. Matching people. A link subscriber has no customer_reference. To attach them to accounts in your app, match on the email they typed or the paying wallet, or ask them to subscribe again through your site after their current period ends.

When the API route is live, close the old link so new buyers come through your site. Closing stops new payments and leaves existing link subscribers renewing.

How do Fianto links compare with card processors' payment links?

Fianto payment links do less than Stripe's: they have no API, no QR code and no custom domain. Stripe, as of 15 October 2026, documents payment links that can be created through its API, shown as a QR code, used for subscriptions, and sent with automatic receipts, and its page is headed "Accept payments online without writing code". Fianto links do one job: they open a USDC checkout for one price, and they send the payer no email.

If you need links generated per customer by code, Fianto's answer is the API itself: a checkout session is already a link, made for one order, and its url can go into an email or a chat like any other.