AUTH GUIDE / Scenario guide
A login before a purchase
Let people sign up, then buy
Ana wants to try the door before choosing a plan for her company.
A worked example with fictional people and products.
What this gives you
A login first. A company workspace when access is granted.
An unpaid login is not a paid customer account. Give that person a clear next step.
Jump to the implementation recipe ↓See it happen
Follow Ana’s first day
- 01
Meet the product
Ana visits Field Notes and creates a login.
What happens behind this step
Start the registered customer client’s authorization flow. Public signup is allowed; the callback and originating client must survive the hosted flow.
- 02
Prove the email
She follows the verification email. She now has an identity.
What happens behind this step
Verification establishes the customer identity. SignupGrantsAccount is false, so this step does not create an account or seat.
- 03
Find a way in
Without a seat or a purchase, Ana sees the plan page.
What happens behind this step
The no-seat result uses the configured checkout guidance. Do not grant access solely because authentication succeeded.
- 04
Choose and pay
The billing flow records access for Ana’s email.
What happens behind this step
The billing integration supplies an owner grant for the intended recipient. Validate the real payment and entitlement flow separately.
- 05
Return to Field Notes
On sign-in, Ana enters her company’s workspace as its owner.
What happens behind this step
Login redeems the grant. The app validates the customer token, scopes data to account and checks the entitlement for paid operations.
The handover to your app
A person, a context, a clear boundary.
Ana enters as owner.
Use Ana’s company account to decide which records this request may reach. The product still checks what this person may do.
{
"sub": "ana-example-id",
"account": "selected-company-id",
"account_role": "owner"
}Build this scenario
The recipe for your developer or agent.
Start with a registered customer app and the policy below. Then connect the specific access path for this scenario.
1. Register the app
Choose your organization and environment, register the HTTPS callback, then configure the client ID and server secret.
Registration request and prerequisites →2. Apply this access policy
{
"surface": "customer",
"allowSelfRegistration": true,
"signupGrantsAccount": false,
"checkoutUrl": "https://www.example.com/pricing"
}Connect the purchase-to-owner-grant flow, configure the checkout destination and check the license before paid operations.
3. Connect hosted sign-in
The app starts login, auth handles the hosted screens, and the validated callback brings the person back to your product.
Complete .NET example →OIDC for other stacks →
4. Check the boundaries
An unpaid login is not a paid customer account. Give that person a clear next step.
Acceptance checks →Branding and direct return →
Ready-to-use implementation brief
Give this brief and this page’s URL to your developer or agent. Replace the example account and callback values with the approved settings for your app.
Implement the let people sign up, then buy scenario for a new app using ALKEYON.
Use the customer client policy below in the selected environment.
Register the exact HTTPS app callback and keep confidential credentials server-side.
Connect the purchase-to-owner-grant flow, configure the checkout destination and check the license before paid operations.
Keep the hosted login, verification and recovery flow tied to this app.
Validate tokens and enforce the tenant, account and operation boundaries.
Do not treat a successful login as a payment or membership grant.
Use the current SDK and OpenAPI contracts linked in this guide.
Verify permitted entry, refused entry, correct product return and revoked access.
Client policy:
{
"surface": "customer",
"allowSelfRegistration": true,
"signupGrantsAccount": false,
"checkoutUrl": "https://www.example.com/pricing"
}