Checkout, payments and account activation

New customer or existing workspace#

Use an address your business will continue to control, not a colleague's disposable inbox. Check the selected billing interval before opening Checkout: changing a marketing-page toggle later does not rewrite a checkout already opened in another tab. If you need to alter the plan or interval, return to the legitimate purchase flow and review its newly displayed details before paying. An existing workspace's billing manager should make the change through that workspace, so payment and access remain associated with the correct account. Having two similar browser tabs open is not a reason to complete both purchases.

Amounts and tax information#

Enter accurate business and billing-address information in the hosted checkout. A tax ID should be supplied only through its actual tax-ID field, not pasted into a customer-support chat. Review the final subtotal, tax, total and renewal interval together; the headline price is not the complete transaction in every jurisdiction. If a discount is offered, distinguish an initial discounted charge from the future recurring amount shown in the provider's review. Keep the receipt as the financial record of the transaction. For an invoice-detail correction, identify the invoice and necessary business change without sending complete card information.

What establishes paid access#

A useful way to diagnose the sequence is to keep four states separate: Checkout was created, the payment was confirmed, workspace access was updated, and the user completed activation. A return page can confirm navigation but not all four states. Do not try to repair delayed access by editing a success query parameter or replaying a browser request. Refresh the account once after the verified provider event has time to arrive. If it still differs from the receipt, support can reconcile the purchase using its safe reference and email. Paying twice introduces another transaction rather than clarifying the first.

Complete a new account#

Open the link on a device where you intend to establish the account credentials. Choose a unique password using your password manager, and do not forward the activation message as a casual screenshot: its link is a bearer account-setup credential. Complete the form once. After activation, the ordinary login path is the expected route, so an old activation link failing later can be evidence that it was already consumed rather than that your payment disappeared. If your account already existed, check your existing login and workspace membership before creating another account. Activation and website installation are distinct steps in onboarding.

Missing or expired activation#

For a missing email, first inspect the exact checkout email on your receipt, then spam, quarantine and mailbox rules. A company alias may be configured to receive ordinary mail but reject automated messages. If the link expired or was opened and consumed by an authorised colleague, give support the purchase reference and account email so the next step can be arranged safely. Do not ask anyone to post the token in a public support thread. If the billing interface itself cannot open, note whether the failure happens before Checkout is created or after payment: those stages require different investigations.

Keep payment data in the provider flow#

Navigate to Billing from your signed-in workspace instead of following an unsolicited payment-update message. Confirm that the hosted page belongs to the expected payment provider before entering payment information. For support, the card brand and last four digits displayed in Billing can help describe which method you expected to use, but they are not authentication proof. Your business should limit who can manage subscriptions and review that access when staff leave. A payment-method update can affect renewal and automatic purchases, so verify both states afterward without assuming that changing the card enables every optional purchase control.

Separate billing ownership from website publishing#

Identify the people responsible for purchase, account activation and website deployment before starting. The payer may be the business owner, while a developer has permission to edit the theme and a support manager will maintain Knowledge. These roles can cooperate without sharing a card or forwarding bearer activation links to a group chat. Decide which stable business mailbox will own the account and who can receive its automated messages. A developer installing the public widget does not need to see the payer's complete financial details.

Prepare a short onboarding record containing the chosen plan and interval, workspace name, account email and intended public domain. After payment, the authorised account owner completes credentials and gives colleagues the supported workspace access appropriate to their role. The website publisher obtains the current installation material through that workspace, then verifies it on the real public hostname. This sequence avoids a common handover failure: a correctly paid account that no one can access because its email belongs to a departed contractor, or a published widget attached to a different workspace than the business expected to fund.

Match the receipt, account and workspace#

When access differs from a paid receipt, compare three records: the provider transaction, the account associated with the checkout email and the workspace's effective billing state. Start with the invoice or checkout reference, exact email and transaction time. Check whether the user signed in through a different address or selected another workspace. Those mismatches can produce an apparent missing subscription without proving that payment ingestion failed. Keep the original purchase intact while support checks the relationship; buying the same plan again is not a reliable account-linking mechanism.

Explain any duplicate purchases or changed emails explicitly. A business can have an older account and a new checkout under a second mailbox, and support needs both safe references to understand the intended outcome. The person requesting a correction must use the authorised support path; possession of another company's invoice number alone is not account-management permission. Reconciliation should establish the verified payment and intended access relationship before an adjustment is made. After the issue is resolved, record the effective workspace and future management route so the next renewal or payment-method update does not begin with the same ambiguity.

Continue from access to a useful public experience#

Successful activation establishes access to the portal. It does not mean a website has been connected, its pages processed, a public theme changed or a provider Action enabled. Continue with the installation guide: connect the correct final hostname, publish through one installation owner, and visit the live site to obtain fresh detection. Then review Knowledge and test an ordinary source-backed question. Keep the payment milestone separate from the public operational milestone when reporting that the launch is ready.

For a staged launch, first check a non-sensitive public page using a controlled browser. If the portal is active but the widget is absent, inspect its loader and publishing path. If the widget is detected but cannot answer, inspect access, capacity and the failing conversational request. If answers are inaccurate, review the business sources rather than the invoice. This layered follow-up prevents billing support and the website developer from repeatedly changing unrelated settings. Record one safe success and the normal business-contact fallback before inviting customers to use support; an activation receipt alone is not an acceptance test of the whole experience.

Example: payment completed without a return page#

Consider a customer who pays, closes the browser before the return page appears and cannot find the activation email. The next useful checks are the receipt's email and payment state, followed by the existing account or activation status. The absent redirect does not invalidate a real confirmed invoice. Conversely, a page displaying success after a cancelled or incomplete payment is not authoritative access proof. Record what actually happened and its time rather than reconstructing the purchase from a browser address alone. This sequence helps support reconcile one transaction without creating a duplicate payment or accidentally placing credentials in a public conversation.

Verify the outcome and keep safe evidence#

Before the operational launch, confirm that the intended user can sign in, see the correct workspace and effective plan, and access its current usage period. Record the separate subscription renewal date and usage-period end, particularly for yearly billing. Then verify the website's public installation and a source-backed answer using the installation guide. If payment is correct but membership is wrong, report that specific boundary instead of regenerating website code. If activation succeeds but access remains inactive, report the purchase state. Clear, separate evidence of those milestones is more useful than a single screenshot claiming that everything is complete.