checkout.nanocorp.so/c/{slug}). Your site can add URL parameters to them to control the checkout it opens: lock in a quantity, attach your own order reference, and prefill the buyer’s email. This is how sites build flows like auctions, bids, and pay-what-you-want pricing on top of a fixed-price product.
In the Products tab, each one-time product row carries its own buy link (hover it and press Copy), and the Links panel holds the all-products link and the test link. See Your business dashboard.
The parameters
Values must be URL-encoded (for example
jane%40acme.com). Any parameter your site does not set is simply omitted; unrecognized parameters are ignored.
customer_email travels in the URL, so it appears wherever URLs are recorded: the buyer’s browser history, and any analytics on your own site that capture link addresses. If that matters for your use case, pass only client_reference_id (an opaque id) and let the buyer type their email on the payment page; the webhook still returns whatever email the buyer used.Monthly plans do not use these links
A monthly plan is not sold from a checkout link. Your site creates the subscribe address for the visitor who is signed in, so the subscription belongs to their account, and a plan address opened on its own shows a branded page that sends the visitor back to your site.qty and the
email prefill do not apply to a plan: the quantity is always one, and the
buyer’s email comes from the account they signed in with.
Strict and lenient behavior
The three parameters are validated differently, on purpose:qtyis strict. An invalid quantity (not a whole number, out of range, a total over the card-payment maximum, orqtyon the all-products link) shows the buyer a branded “This checkout link is invalid” page with the specific reason. It never falls back to quantity 1 and never rounds: a broken link fails loudly instead of charging the wrong amount. If your site builds links from a template, test every shape it can generate.client_reference_idandcustomer_emailare lenient. A malformed value is dropped and the checkout proceeds without it.
Locked quantity: the bid pattern
Becauseqty locks the amount, a site controls bid increments by rendering several links to the same product with different quantities. The usual mechanic is a bid-unit product: a $1 product where ?qty=715 means a $715 bid. The checkout headline shows the computed total (for example “$715.00”), not a unit breakdown.
Ask your business’s agents to build this: the pattern (bid buttons, webhook settlement, outbid notifications) is something they know how to wire end to end.
Capping the quantity on the product itself
qty decides the amount for one click. When the limit belongs to the product rather than the link, set it on the product instead, and it applies to every link that sells it, including the ones already published in your ads and site code.
By default a buyer can pick 1 to 99 of a product on the payment page. Your agents cap that with max_quantity (1 to 999,999):
--max-quantity 1 is the right setting for a single seat, a named pass or a booking: the payment page then shows no quantity control at all. It changes no price and no URL, so the product’s checkout_url keeps working exactly as before. A ?qty=N link still wins over the product’s ceiling, so your bid flows are unaffected.
The language and the name on the payment page
The payment page shows your business’s own name at the top, so it matches the brand the buyer just read on your site. NanoCorp is the merchant of record for the sale, so NanoCorp still appears in the receipt and the terms. For a one-off purchase, the buyer’s card statement line readsNANOCORP* followed by up to 12 characters of your business’s name, cut at a word when enough of the name fits and with accents simplified, so the purchase is recognisable at the bank too. A monthly plan charge reads NANOCORP alone, and so does a one-off purchase when your business’s name cannot go on a card statement (letters a card statement cannot print, a phone number, or a word that reads as a card network, as one of NanoCorp’s own charges or as NanoCorp itself); nanocorp payments settings shows the name that will follow NANOCORP*, or nothing when your name cannot go on a statement.
The page is rendered in the buyer’s own browser language. If you sell into a single language market and want it always in that language, pin it:
What comes back on the webhook
After a successful payment, NanoCorp forwards thecheckout.session.completed event to your site at /api/webhooks/nanocorp. The fields that close the loop:
data.object.amount_total: what the buyer actually paid, in the smallest currency unit (cents for USD).data.object.client_reference_id: exactly what your link carried, ornullif it carried none.data.object.customer_details.email: the buyer’s email (withcustomer_emailset, the same address you passed).
client_reference_id as a correlation key, not authentication: the forwarded webhook is not signed, so use the id to look up your own record, and verify anything high-stakes against your revenue via the CLI (nanocorp payments revenue).
The success page is cosmetic
After paying, the buyer’s browser is redirected to/checkout/success?session_id=... on your site. That page is a thank-you screen only: the buyer can close the tab before it loads. Do fulfillment in the webhook handler, never in the success page.
Testing
The same parameters work on your test checkout link with Stripe’s test card4242 4242 4242 4242. Open {test_checkout_url}?qty=7&client_reference_id=test_1, pay with the test card, and check that your webhook receives amount_total equal to 7 times the unit price along with your reference. See Testing your checkout.