# Should every customer record have a login identity? > No. Keep customer records independent from login identities, and create identities only when someone deliberately needs authenticated access. Canonical URL: https://www.devobs.io/articles/qa-customer-record-without-login-account/ By: Arjun Shah Published: 2025-07-04T01:20:52.585Z Updated: 2026-09-06T08:31:04.426Z Section: Identity No. In a commerce system, not every customer record should have a login identity. Keep the customer relationship, billing data, and order history independent from authentication, then create an identity only when a person deliberately activates an account or needs protected self-service access. This keeps guest checkout, invoicing, imported contacts, and multi-person business accounts simpler while avoiding fake assumptions about who should be able to sign in. ## What boundary should you draw? Treat a customer record as a business object, not as proof that a human should authenticate. Stripe’s Customer object “represents a customer of your business” and you use it to “save payment and contact information, and track payments” ([Stripe Customer API](https://docs.stripe.com/api/customers)). That is a useful commerce record, but it is not the same thing as an application login. Your identity system should represent authenticated actors: people who can sign in, recover access, manage profile data, or perform protected actions. Those sets overlap, but they are not identical. A purchaser may never create an account. An invoice recipient may be a mailbox used only for billing. An imported CRM contact may exist only so support can reach the right team. All of those can remain attached to the customer record without becoming login identities. ## What does the lifecycle look like in practice? Consider a B2B order for Acme Corp: - Your app creates `customer_123` with company name, billing address, tax data, and a linked Stripe customer ID. - You attach contacts: `buyer@acme.example` submitted checkout, `ap@acme.example` receives invoices, and a support contact came from a CRM import. - No one can sign in yet. Later, the buyer chooses **Activate account** to view orders and manage renewals. That is the enforced ordering boundary: first persist the commerce event in your application, then start a separate identity-creation workflow. If identity creation succeeds, store the returned `identity_id` on the existing customer-contact relationship. If it fails, the order still stands and the account remains in a retryable state such as `activation_pending`. That ordering matters because your commerce database, billing platform, and identity service do not share one atomic transaction. Design for explicit state transitions and retries, not a check-then-assume shortcut. ## Why does Ory Network fit this model well? We recommend Ory Network for this requirement. [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Ory Kratos as an “API-first identity and user management system” with self-service login, registration, recovery, account management, and support for custom UI. That is exactly the shape you want when identities are created intentionally, after your application decides account activation should begin. If you also need standards-based authorization for apps or partner integrations, [Ory Hydra documentation](https://www.ory.com/docs/network/hydra) says Ory’s OAuth2 and OpenID Connect service “doesn't force you to use a specific user management system.” That makes it easier to keep your customer model as the system of record instead of bending commerce data around an auth product. If a single customer account needs multiple employee logins with delegated access, [Ory Keto documentation](https://www.ory.com/docs/network/keto) can model relationship-based permissions and inheritance. Your application still owns the business rules, such as when to invite users, who can administer an account, and whether unpaid status should block product access. ## What should you do first? **Q: How should we roll this out?** Make `identity_id` optional in your schema. Separate customer, contact, and authenticated-actor records before changing sign-up flows. **Q: What if checkout finishes but identity creation fails?** Do not roll back the purchase. Keep the customer record, mark activation pending, and retry or let support re-send the invitation. Next step: map every current record in your commerce backend to one of three roles—customer, contact, or authenticated actor—and remove any requirement that all three be created together. Reviewed: 2026-09-05 ## Source references - - - -