# Checkout and self-service Checkout lets an Alunta team's end customers purchase plans made available in checkout. The displayed payment method, currency, price, and resulting subscription depend on plan configuration and active payment providers. Stripe SEPA purchases and paid resumptions can remain under processing for several business days. The confirmation page and portal show processing until Stripe confirms the payment; returning from Stripe is not proof of payment. Reopening the form, changing the quote or changing provider in the same browser while the same purchase is processing does not start a second debit. Expired local payment links needed to complete an unresolved Stripe payment are retained until its outcome is known. ## Choose the right link A subscription signup link creates a new subscription when the buyer completes checkout. A new one-off invoice link offers the team’s supported payment methods. Online payment creates a paid invoice after payment is confirmed; bank transfer creates an unpaid invoice when the buyer accepts checkout. This applies to both the app and the API. Neither flow pays an invoice that already exists. To collect an existing invoice, use **Copy payment link** in its invoice menu; this uses the original invoice and does not create another subscription or invoice. The invoice email includes the same payment route when the invoice is eligible for online payment. Checkout must be enabled before creating any checkout link or sending a subscription offer. A card-only link requires a connected payment gateway; an invoice-based subscription signup does not. Only payment methods supported by the plan or bundle and available to the team can be offered. The app shows the missing setup and links to the appropriate settings. Links can become unavailable later if settings or plans change. Known expired or unavailable checkout links explain the problem and direct the buyer to the sender. Deleted and unknown links stay unavailable. ## Before a purchase can complete The plan must be visible in checkout and have a price for the selected interval and currency. A supported payment provider must be active when online payment is required. Tiered plans must have a valid price on the selected tier. ## Notice period in checkout If the plan has a notice period, it is shown as a line ("Notice period: ...") in the checkout summary and on the confirmation page. This also applies in a bundle, where each subscription with a notice period gets its own line. The order confirmation shows it as a line under the subscription's name. The subscription gets the notice period the buyer was shown when the purchase was priced, not the plan's value at a later time. The checkout page remembers the notice period it showed. If the team changes the plan's notice period before the buyer submits the purchase, whether it is a single subscription or a bundle, the purchase is refused with a message ("The cancellation terms changed. Please review and submit again."), the page shows the new notice period, and the buyer can try again on it, so the buyer never agrees to one notice period and gets another. The notice period is not part of a payment's identity and moves no money, so a change does not open a new payment session: an open payment that has not yet bought anything is resumed and carries the notice period the buyer is now shown. A purchase that has already completed is not bought again and is never changed: if the buyer comes back to it, the existing purchase is resumed with the notice period the buyer was shown, even if the team has changed the plan since. See the notice period section in the subscription lifecycle guide for how the notice period is calculated. ## After checkout A completed purchase can create an end customer, a subscription, payment details, and later invoicing depending on the flow. The notification catalogue describes `checkout_completed` when available and which delivery channels the selected Alunta team has effectively enabled. Recipient addresses and message contents are not shared. ## First partial period with the next renewal When the team charges a first partial period with the next renewal (renewal settings), a checkout purchase of a plan with fixed renewal that starts between two renewal dates takes no payment for that partial period at purchase. This only happens when the next renewal is billed without the team acting: the plan invoices automatically and, for card payment, the team charges cards automatically. Otherwise checkout charges or invoices the partial period at purchase as usual. A card purchase saves the card, and the first card payment on the next renewal date covers both the partial period and the next period; an invoice purchase gets its first invoice for both periods with that renewal. Checkout and its confirmation show when the first payment or invoice comes and which period it covers, and for card payment the amount. A bundle's one-off amounts are billed as without the setting: at purchase, or on a future start date. The decision is fixed when checkout prices the purchase, so changing the setting while a customer is paying does not change what that customer was shown. ## Start dates on payment links The start-date feature applies only to new purchases through payment links with an explicitly chosen start date. Existing subscriptions, invoices and historical periods are unchanged. Payment links without a start date and ordinary renewals retain their existing calculation and invoicing schedule. Choose a fixed start date when creating a payment link, or leave it blank to keep the existing checkout flow. The date can be up to ten years in the past or twenty years in the future. For a historical date, periods are calculated from the chosen date: card checkout settles the first payable period, and the remaining periods follow normal collection. Invoice purchases follow normal back-billing rules. For a future date, checkout stores the card without charging it. Subscription charging and invoicing start no earlier than the start date or the end of a trial. Usage remains billed in arrears based on actual consumption. All amounts in a payment link with a future start date wait until that date, including subscriptions and one-off amounts for both card and invoice payment. With invoice payment, bundle one-off amounts are on the same invoice as the first period when one of the bundle's subscriptions has a fixed paid period from the start date. Otherwise - with card payment, or when every subscription has a trial or is usage-based - the one-off amounts receive a separate invoice on the start date. Automatic invoicing and card charging settings are respected; manual collection cannot happen before the start date. ## Language and appearance Checkout and the customer portal have their own public language choices. The signed-in team administration has a separate language setting. In checkout settings, the team can customize fields for brand colour, terms, and confirmation; this does not automatically change every email or PDF. ## Offers, bundles, and usage A personal payment link can have an agreed price without changing the plan catalogue price. Copying the link does not itself send an email. For plans that support trials, the offer has a three-way trial choice, in the app and in the API (`apply_plan_trial`): the plan's default trial, an own trial for this offer, or no trial. A tiered plan can be offered with a percentage discount; it is quoted from the starting (lowest) tier and the customer is placed on a tier at checkout, so a custom price or a fixed-amount discount is not available for it. The checkout of an offer stays in the interval and currency the offer was created in, even if the buyer's country prefers another currency the plan also prices in. A bundle combines the purchase experience, but the subscriptions created afterwards have their own periods, trials, and renewals. A one-off amount may be paid at purchase while a trial or usage moves the subscription amount later. Usage is billed in arrears from reported values and is not a fixed monthly amount. ## Customer portal and cancellation Bundle checkout currently supports one shared VAT profile and rate for all VATable lines. If the plans or one-off lines resolve to different VAT profiles or rates for the buyer, checkout blocks the purchase before payment; buy those items separately or ask the seller to adjust the bundle. A portal login link is time-limited and must be generated again after it expires. The team chooses whether an end customer can cancel in self-service and can show a contact message. Cancellation displays an end date under the subscription's applicable rules; it is not an automatic refund. If the subscription has a notice period, it is shown on the subscription card (with "(applies after the trial)" or "(applies once the subscription has started)" when it does not apply yet) and the customer cannot opt out of it: the cancellation dialog shows the end date that will be stored and mentions the notice period before the customer confirms. The date shown also takes into account a later period that has already been invoiced or charged. If the date changes before the customer confirms (for example because the page was open across midnight), nothing is saved: the portal shows the new date and the customer confirms again. If the subscription is in a trial, or has not started yet, the notice period does not apply. Resumption depends on subscription status and payment. A cancelled subscription that is still running can be resumed by the customer with one click in the portal. That is not offered if the subscription ended because of a failed payment, if it is a card subscription without a saved card, if its end date came with an import (for example a fixed term from e-conomic), or if it belongs to a deactivated customer; the customer is pointed to the team instead, and the team can still resume it from the administration or the API. A card subscription without a saved card is not charged, though, until the customer adds a card in the customer portal; that card is then used automatically. A card subscription that has already ended can be resumed in the portal by paying with a card, where the payment provider supports it (OnPay and Stripe); the first card payment is charged immediately. With SEPA through Stripe, the resumption instead awaits the bank payment confirmation. For other card providers this is not offered online. ## What your AI can see about checkout One tool, `get_checkout_overview`, covers this app, and only for owners and administrators: other roles, including members who can open the checkout settings, cannot use it through AI. It needs no further opt-in and appears once the Checkout app is switched on, or while checkouts remain from before it was switched off. When the app is switched on, the AI client must reconnect or reload its tool list to see it. It shows whether the app is on, which payment sources could be offered today, how many payment links are still open, and a period report of up to 366 days (the last 30 days by default): how many checkouts were completed, failed, expired unfinished or are still in progress, the completion rate, how many distinct customers bought (including one-off invoice payments), what was paid at checkout per currency, what was only invoiced at checkout per currency, and the same split by payment source and by subscription type or bundle with the best sellers first. There is no page in the app that shows these figures. Some things must be kept apart. A checkout is one submission of the checkout form to payment, so a buyer who retries after a declined card counts again, a buyer who leaves before choosing how to pay is never counted, and the completion rate is per submission, not per buyer. A checkout that is still pending after its payment window is not proof that the buyer gave up: a payment provider can still confirm the payment afterwards. The amount paid at checkout is the first charge including VAT taken through a card or wallet payment, which is 0 for a trial or a usage-based plan, and is never the recurring subscription value. A checkout where the buyer chose to pay by invoice only creates an unpaid invoice, so it is shown separately as invoiced at checkout and is not money received. Expired payment links without unresolved Stripe payments are deleted every night, so only the links open right now can be counted. AI never sees a buyer's name, email, phone or address, purchase tokens, payment-session links or idempotency keys. Every scan of rows is bounded; when there are too many, the tool returns an error instead of a partial answer.