Hosted checkout

A hosted checkout is a signup page yRecurring hosts for you. You set it up once, share its link, and customers use it to subscribe themselves. Behind the link, it creates the customer, the subscription, and takes the first payment.

The builder shows a live picture of your checkout page. Click any part of it, like your branding, the headline, the plan, the details you collect, the payment section, or the button. Its settings open in a panel on the right, where you rename things, choose which details to ask for, and turn sections on or off. An After payment tab flips the page over to the thank-you screen so you can edit that too.

Plans and add-ons are picked by search: type a plan's name, pick it, and it appears as a card showing its pricing. Your first pick is the main plan; pick more and buyers choose between them, with a Make main action to swap which one leads. Add-ons work the same way, so it does not matter whether you have three prices or three hundred.

While you set one up, the Preview button shows the page exactly as buyers will see it, rendered from your unsaved edits. You can switch between the checkout and its thank-you page, and between desktop and phone width. Preview in new tab opens the same page full size in its own browser tab.

How that payment is taken mirrors your gateway setup: a connected gateway shows its card form or redirect, and an organization collecting offline shows its own payment instructions instead, with an optional payment reference field for the buyer. See connecting a gateway and recording payments.

Letting buyers choose how to pay

If you have more than one way to pay connected, the checkout shows them as a list and the buyer picks one. A card gateway appears as Card, PayPal as PayPal, a bank debit provider as Bank debit, and your offline instructions as Bank transfer / other. Each option opens its own payment step in place, and the small print names the provider securing it.

You control the list per checkout under Payment options on the checkout form:

• Untick any option you do not want this checkout to offer. New gateways you connect appear automatically on every checkout until you hide them.
• Choose how your offline instructions behave: Automatic shows them only when no gateway applies, Always offer lists them beside your gateways, and Never offer keeps them off this checkout.

With a single way to pay there is no list at all; the page looks exactly as before. Invoice payment pages offer the same choices, and list your offline instructions by default, so an unpaid invoice always shows every way to settle it.

What a checkout offers

A checkout is built around one plan price: that is what the customer is signing up for. On top of that, you choose what else it offers and asks:

• Add-ons. Let the customer add optional extras to their subscription during signup.
• A coupon field. Let them enter a coupon code for a discount.
• A future start. Let them pick a date for the subscription to begin, rather than starting right away.
• Which details to collect. Decide which fields to ask for, and which are required. An address, for example, can be off, optional, or required.
• A quantity. Let buyers choose how many they need (seats, licences, users) within a range you set. The order summary re-prices as they change it, and the subscription is created for the number they chose. This only appears on plans whose price actually varies with quantity (per-unit, tiered, volume, package or step); on a flat-priced plan the builder tells you it would have no effect.
• A tax ID. Ask business buyers for their VAT number, ABN, GSTIN or local equivalent. The field names itself after the buyer's country, so a German business is asked for a "VAT number" and an Australian one for its "ABN", with an example of the right shape. The number is checked for that shape before the order goes through and stored in one canonical form however it was punctuated. EU VAT numbers are then verified against the VIES registry; a verified number is what lets cross-border B2B invoices be reverse charged instead of carrying VAT. Leave it optional unless you only sell to businesses; a required tax ID turns away every consumer buyer.
• Your own questions. Any custom field you have defined for customers can be asked during signup too, with the same off, optional, or required choice. A dropdown field shows its choices, a checkbox shows a checkbox, and so on. Answers are saved straight onto the new customer's record.
• A terms gate. Require the customer to accept your terms before they can finish.

When a card is declined

A refused card is not a dead end. The buyer sees the decline in plain words, the button re-arms, and pressing it tries the payment again on the order they already placed: a fresh attempt against the same invoice, with no risk of a second subscription or a double charge. They can switch cards or retry the same one; if the invoice gets paid some other way in the meantime (say you recorded a payment for it), the retry notices and shows them it is already settled instead of charging again.

Putting the checkout on your own website

Every checkout has a public link you can share anywhere: email, social posts, a QR code on print.

For your own website, the checkout's detail page also gives you a ready-made embed snippet. Paste it into any site builder that accepts HTML (WordPress, Shopify, Webflow, plain HTML) and it renders a "Subscribe" button in your brand color. Clicking it opens the checkout in a small popup window on top of your page. If the visitor's browser blocks popups, the button simply opens the checkout as a normal link instead, so it always works.

You will find the snippet under Checkouts, open a checkout, Embed on your site. Copy it once; if you later change your brand color, copy it again to pick up the new color.

Sending one buyer their own link

A checkout's link is shared and reusable, which suits a "Subscribe" button but not a named buyer. For that, your application can open a checkout session: a one-use link to the same page with that buyer's details already filled in.

A session can also fix things the buyer does not get to change: which plan term is billed, how many seats, and which existing customer the subscription attaches to (so an upgrade lands on the account they already have rather than creating a second one). You can attach your own reference, such as an order number or a user id, and read it back afterwards to find out which customer, subscription and invoice the signup produced.

Sessions expire (a day by default, 30 days at most), stop working once used, and can be revoked. A buyer opening a link that has expired or already been used is told which, so they know to ask for a new one.

Sessions are created through the API; see the Checkouts section of the API reference.

Choosing the link, and duplicating a page

When you create a checkout you can choose the ending of its public URL, so the link reads as something you can say out loud: yourdomain/c/pro-annual rather than a generated code. Leave it blank and one is built from the name. Letters, numbers and dashes; anything else becomes a dash. If the ending is already in use, you are told to pick another rather than being given a different link than the one you asked for.

The link cannot be changed after the checkout is created. Every copy already shared would stop working, and a stable URL is the point of having one. Duplicate is the answer instead: it copies the plan, the add-ons, every field rule and all your copy into a new draft with its own link, leaving the original working for everyone who already has it. Duplicating an archived checkout is a normal way to bring back a previous offer.

Sharing the link

A checkout link now previews properly when you paste it into an email, a chat or a social post: the card shows your page headline, your subtitle and your business name, with your logo as the image when you have set one. Before this it unfurled to nothing, which reads as suspicious right when somebody is deciding whether to type a card number.

The preview uses only what you have configured. There is deliberately no yRecurring fallback image: a preview for your product should not carry our logo, because it would confuse buyers about who they are paying.

Checkout pages stay out of search engines. A link preview is not a search listing, so both are true at once: shareable, but not something a competitor finds by searching for your prices.

Invoice links, card update links and per-buyer checkout links deliberately preview as nothing at all. Each of those URLs is a credential and describes one customer, so a preview would leak an invoice into whatever group chat it was pasted into.

Keeping bots off your signup form

A public checkout link is a form anyone on the internet can post to, and a free trial makes it worth their while: automated signups leave you junk customers and junk subscriptions, and every accepted one sends a welcome email to an address the bot picked.

Three things stand in the way, and none of them asks your buyers to solve a puzzle. The form carries a decoy field a person never sees and never tabs into, which most automation fills in anyway. The server checks how long the form took to complete and refuses one that came back faster than anybody could type. And one checkout link accepting an implausible number of signups in a few minutes is frozen for a short while, then recovers on its own.

A refused submit creates nothing at all: no customer, no subscription, no email. It answers with the same wording every time, deliberately, so an automated attempt learns nothing about which check stopped it.

Refusals show up in the abuse signals your operators can see. If a link is under sustained attack, that is where the evidence will be.

When the tax estimate appears

The order summary shows estimated tax as soon as the buyer's address can determine a rate, quoted through the same engine that will tax the invoice, so the total they agree to matches the first invoice.

What counts as enough address depends on where they are. In a country with a single national rate, such as the United Kingdom or any EU member state, the country alone settles it and the estimate appears immediately. Where the rate depends on where inside the country they are, the estimate waits for a state or a postal code: United States sales tax is postal-code specific, Canadian tax depends on the province, Indian GST on the place of supply, and Brazilian tax on the state and municipality. Showing a country-level guess in those places would name a figure that changes the moment the buyer finishes typing.

What the buyer is told before they pay

Directly above the pay button, every checkout states the terms of the payment the buyer is about to authorise: what is charged today, what is charged after that, how often, and the date of the next payment. It says the charges are automatic and continue until cancelled, names your business as who to contact to cancel, and links your terms when you have set a terms URL.

This is not optional decoration. Card network rules require the terms of a recurring agreement at the point of enrolment, auto-renewal laws in several markets require the price and frequency to be clear and conspicuous before purchase, and Apple and Google require the same before their payment sheet opens.

The wording is generated from the same priced preview that produces the order summary, so it can never quote a figure the checkout will not bill, and it updates the moment a buyer changes seats, adds an option or enters a coupon. A free trial gets an explicit sentence: the date the trial ends, the exact amount charged on that date, and that it repeats.

The card update page carries the matching authorisation: saving a card there authorises you to charge it automatically for invoices as they fall due.

After a successful checkout

When the customer finishes, you choose where they land:

• A thank-you page. yRecurring shows a completion page, with wording you set.
• A redirect. yRecurring sends them on to a URL of your choice, so you can take them into your own app or a welcome page.

Draft, active, archived

A checkout has a simple lifecycle:

Edge cases

• A checkout is built around one plan price. Add-ons are extras on top; the plan is what the page is for.
• One checkout, one currency. Every price offered on the page (the main plan, alternatives, and add-ons) must share a currency, because the payment form and the charge follow one. To sell in another currency, make a separate checkout with that currency's prices.
• You decide which details are required, not the payment gateway. If your setup needs a field, mark it required.
• Archiving stops new signups. The customers who already signed up through it keep their subscriptions.