Choose the purchase account before checkout#
Choose the plan and billing interval on Pricing, then complete Stripe Checkout using the account email that should manage Reesponder. Agree that email before a colleague pays on your behalf. A finance mailbox that only receives receipts may be inconvenient for the person who needs to activate and maintain the workspace.
For an existing workspace, use its Billing area for supported subscription management. A separate public purchase can conflict with an active subscription and require review; it is not a reliable way to repair lost access. Keep the receipt so support can identify the existing payment if a later stage is unclear. Payment and login access belong to the same account journey, but they are different operations.
Let confirmed payment create the access entitlement#
Reesponder fulfils the purchase after processing the provider's signed payment notification. The return page can temporarily show that the workspace is being prepared while that confirmation is pending. Opening the success URL yourself does not create paid access, and a failed or pending payment cannot be forced through by repeatedly refreshing it.
If you closed the checkout tab after paying, the payment notification can still be processed independently of the browser redirect. Start from the receipt and account email when checking what happened. If your payment method has not completed, follow the payment provider's actual result rather than assuming that reaching a return page proves completion.
Complete the activation form once#
Open the activation link delivered to the purchase email. It is valid for 48 hours and is intended for the recipient. Enter Your name, Company name and What does your company do?, then create a password of at least 12 characters and select Activate workspace. After Workspace activated, choose Continue to login and use the new password for ordinary sign-in.
The company description accepts 20 to 1,000 characters. A useful example is “We sell home accessories online and help customers with delivery, returns and product care.” Describe the actual business and audience. Detailed delivery rules and response instructions belong in Knowledge after activation, not in a company-description field.
Save the account password in your password manager with the portal login address. The private one-use activation URL is not a permanent login bookmark. Avoid putting confidential customer records, card information or integration credentials into any of the activation fields.
Check the mailbox and link result#
Check the exact purchase inbox, spam folder and any company email filtering. An alias or spelling difference matters even if it belongs to the same person. If a colleague completed checkout, confirm which address they actually entered rather than assuming it matches the email on the company's website.
If the link reports that it is expired or already used, stop trying variants of the URL. Its opaque token cannot be repaired by editing it. If account credentials already exist, try ordinary login: a returning account does not need another activation password for every authorised billing change. Use the recovery cases below to decide which stage needs attention.
Check the activated workspace before installing#
After login, select the expected workspace and open Overview. Check its access status, plan and current available allowance. An account can exist without active access to create a website. If a separately issued founder access grant is available to you, use Activate founder access as instructed; it is not a public signup method or a substitute for payment confirmation.
Once the expected entitlement is visible, move to website setup. You do not need to finish an installation to prove that the account activated, and connecting another domain will not fix a billing mismatch. Keep these stages separate when asking for help.
Worked cases: the purchaser and returning user#
A finance colleague pays using the agreed operations email while the person maintaining the website controls that mailbox. After payment confirmation, that person opens the activation email, completes the form and saves the portal password. They then invite colleagues using the supported team flow, if their plan includes it. They do not forward the activation URL around the team as a shared login.
A returning owner completes an authorised billing operation for an account that already has a password. They sign in with those established credentials and inspect the workspace's Billing state. If they cannot remember the password, the password-reset flow is the relevant recovery route. Creating a second account or making another payment would add an unrelated problem rather than establish access to the first purchase.
Both cases end with an accessible workspace, but only the first requires the first-time activation form. Describe which case applies when contacting support; that helps distinguish an onboarding problem from a normal account-recovery request.
Record the three facts that make setup ready#
Before connecting a production domain, confirm that ordinary sign-in works, the intended workspace is selected and its plan/access state matches the purchase you expected. Record the workspace's name and the date of this check in a launch note; keep credentials out of that note.
If one of those facts is unclear, investigate it before asking a developer to install the widget. A successful website deployment cannot resolve the wrong account email or an unconfirmed purchase. When all three are correct, continue with the first website's domain, Knowledge and installation procedure. This completion point is account readiness, not a claim that every customer-facing feature has been configured.
Use visible evidence to choose the next step#
Compare the evidence you actually have. A checkout receipt with no portal access points to purchase or onboarding reconciliation. A successful login with the wrong workspace points to account or workspace selection. A visible workspace with unexpected paid access points to its billing state. A correct active workspace with no launcher on the public site points to installation.
The appropriate support description follows the same distinction. “I can sign in, but the purchased workspace is absent” gives more useful information than “activation is broken”. Include whether this was a first purchase, a returning account or a separate access grant. Describe the visible result without sending the activation credential itself.
Do not use an installation screenshot as payment evidence or a receipt as proof that a particular browser is signed in. Each document establishes a different stage. Choosing the stage first avoids repeating operations that have already succeeded and makes it possible to resolve the original purchase rather than create a duplicate.
If the form does not accept the details#
Before submitting, the browser checks required fields and minimum lengths. If it identifies an invalid field, correct that field before continuing. Check that the company description is a meaningful sentence within its supported length, that the name and company fields are completed, and that the password satisfies the form's requirement. A password manager may fill the password field with an existing password for another site instead of the new one you intended. Check the field without exposing its value to anyone else.
If the form appears to have submitted but the result is uncertain, try ordinary portal login with the intended account credentials before submitting another account setup. Success may have consumed the activation link. If login does not work and the link now reports invalid, ask support to reconcile that exact attempt. Record the time and safe error text, not the URL token.
A company description change is not a way to resolve unsupported customer answers. Finish account setup first, then maintain customer-facing facts and behaviour in the correct Knowledge sources. This keeps validation and answer quality as separate problems.
Send a useful, credential-free recovery request#
Use Contact with the purchase email, approximate purchase time, safe receipt reference and the step that failed. Explain whether you can sign in, whether any workspace is visible and what the activation page says. If the purchaser used a different company mailbox, state that relationship so support can investigate the correct account.
Exclude the full activation URL, password, reset code and card details. A private setup link is access information, not a safe reference to paste into a public ticket. Support can request an appropriate safe purchase reference when needed; sending credentials does not establish payment and creates unnecessary exposure.
If your company mail service filters the activation message, ask its administrator to inspect delivery using the intended recipient and timing. If the account is already active but the password is lost, use the documented recovery form instead. If access is correct and the website still lacks chat, provide the public domain and installation symptom through the widget troubleshooting route. These distinct recovery actions keep the working account and purchase intact.
Need help with this?
Tell us which website, guide and step you are working on. Keep passwords and private customer details out of the message.