Skip to main content
Talk to an expert
Accountly - customer account systems logo

Customer account systems integration for ecommerce identity and access

Unified login and trade-account permissions across storefronts and portals iWeb connects your customer account system to storefronts, trade portals and ERP so that login, roles, cost-centre restrictions and permissions stay synchronised across channels. Provisioning, permission updates and deprovisioning flow automatically without manual intervention or orphaned records. Works with Adobe Commerce, Magento Open Source, Shopify Plus, BigCommerce and other storefronts.

Also searched as: SSO, single sign on, identity provider, SAML, OAuth, LDAP, customer accounts.

Customer account systemsiWeb integration layeryour storefront
Talk to an expertSee the estate map ↓
Works with - Adobe Commerce · Magento Open Source · Shopify Plus · BigCommerce · Other storefronts
On this pageGet a brief reviewed
01 · What you get

What a Customer account systems integration gives you.

Single identity across channels

Customers log in once and access online storefronts, trade portals and account self-service consistently. Account status, permissions and preferences synchronise so users experience a unified identity regardless of channel.

Automatic account provisioning

New customer accounts are provisioned into commerce, ERP and trade portals automatically without manual intervention. Buyers gain access to role-appropriate catalogues, pricing and order controls on day one.

Trade-account controls enforced in commerce

Buyer roles, cost-centre restrictions, spending limits and contract-specific pricing are enforced at checkout and product-visibility levels. Commerce respects account attributes so that trade rules are applied consistently.

Safe account deprovisioning

When accounts are disabled or deleted, access is removed cleanly across storefronts, order-management systems and ERP without orphaning customer data or breaking order history visibility for support teams.

Compliance with access-control audit trails

Account provisioning, permission changes and login events are logged and auditable. Teams can demonstrate who had access to what, when and for how long across commerce and trade channels.

02 · When it's worth it

Where a Customer account systems integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Linking customer accounts across online storefronts and trade portals with a single identity provider
Provisioning and deprovisioning customer records and access permissions when accounts are created or closed
Mapping trade-account roles and cost-centre restrictions to product catalogues, pricing and order limits in commerce
Synchronising password changes, multi-factor authentication policy and session timeout rules across channels
Handling B2B account delegation, buyer-on-behalf and procurement-role hierarchies within the commerce experience
Reconciling customer account deactivation across commerce, ERP and customer-service systems without orphaning orders or data
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

Account provisioning delays after storefront signup

Many account systems require manual approval or batch-processing workflows before new storefronts customers are added to the identity provider. This leaves accounts in a limbo state where users can sign up but lack full permissions or role assignment until provisioning catches up.

Trade-account role hierarchies not enforced in commerce

Account systems often support complex role models (buyer, approver, cost-centre manager, delegate) but storefronts lack native support for role-based catalogue visibility, order limits or pricing tiers. Custom logic must be layered on top to make permissions commercially effective.

Deprovisioning lag when accounts are disabled

Removing a customer account from the identity provider does not automatically remove access to commerce sessions or order history. Users who are deprovisioned may retain active sessions, cached tokens or historical order visibility until storefronts are explicitly notified.

No clear mapping between account attributes and commerce rules

Account systems hold buyer role, cost-centre and contract attributes but storefronts have no native mechanism to translate those into commerce pricing, product visibility or checkout behaviour. Teams often build bespoke middleware or custom attributes to bridge the gap.

Password and MFA policy changes don't sync bidirectionally

Updates to MFA enforcement, password complexity or session timeout rules made in the account system often require manual configuration in the storefront or take hours to propagate. Storefronts may enforce outdated policies while policies are being updated in the account system.

04 · The real work

Many teams discover that account-system roles are defined but never enforced in commerce; permissions exist in the identity layer but the storefront has no native way to act on them, leaving manual bridges and custom logic to fill the gap.

05 · Where it sits

Where this integration sits in your estate.

Customer account systems holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.

One integration architecture, any storefront. Customer account systems connects through the same governed layer whatever commerce core you run.

System of record
Source / owner
Customer account systems
Central identity and access-control layer for commerce and trade channels
  • Customer identity and authentication credentials
  • Account status and lifecycle
  • Trade-account roles and permissions
  • Multi-factor authentication policies
  • Group and access-control definitions
iWeb integration layer
Customer-facing commerce
Commerce platform
Adobe CommerceMagento Open SourceShopify PlusBigCommerceOther storefronts
  • Customer session and browsing state
  • Storefront-specific cart and checkout
  • Product visibility and pricing tier enforcement
  • Order creation and submission
Connected neighbours
Integration layer
ERP
Receives customer account creation, status changes and trade-account hierarchy so that order processing and credit limits respect authoritative account data.
Integration layer
Order management (OMS)
Enforces order limits, approval workflows and cost-centre restrictions based on account-system roles and permissions synchronised from the identity provider.
Integration layer
Customer service platform
Accesses customer account history and permission levels so that support teams can understand the customer's role and what they are entitled to see.
Integration layer
Trade-account master data
Receives cost-centre, contract and account-hierarchy definitions from the master-data system and synchronises them to the account platform for enforcement in commerce.
Integration layer
Audit and compliance systems
Receives logs of account provisioning, permission changes and login events for compliance reporting and access-control audit trails.
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.

Ecommerce platforms (examples)
  • Adobe Commerce
  • Magento Open Source
  • Shopify Plus
  • BigCommerce
  • Other storefronts
Surrounding systems (examples)
  • ERP (SAP, NetSuite, Microsoft Dynamics, Sage)
  • Order management system (OMS)
  • Customer relationship management (CRM)
  • Trade-account master data system
  • Identity provider (Okta, Azure AD, Auth0)
  • Customer-service platform
  • Business intelligence and reporting
Not sure?

Not sure if this works with your stack?

Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into COMMERCE & ERP
←From COMMERCE
↔BOTH WAYS
New customer provisioning: New customer records, account hierarchies and buyer roles are created in the account system and provisioned into commerce storefronts and trade portals
Contact details, trade-account status and cost-centre mappings flow through so storefronts can apply role-based pricing, catalogues and order limits from day one.
Authentication and session tokens: Login credentials and multi-factor authentication policies are managed by the account system
Commerce requests authentication assertions or tokens for each session, and the account system validates login, enforces password rules and MFA requirements before issuing session tokens back to the storefront.
Trade-account permissions and pricing rules: Trade-account attributes including buyer role, cost-centre restrictions, account status and contract-specific pricing rules are maintained in the account system and synchronised to commerce
Changes to permissions or pricing rules propagate back so that storefronts enforce the latest access policies.
Account and contact updates: Customer profile updates such as address changes, contact preferences and communication settings can be captured in storefronts and synchronised back to the account system so that the authoritative customer record stays current.
Account and credit-limit changes: Trade-account status changes, credit limits, account hierarchies and customer-type classifications are synchronised from the account system into ERP and order-management systems so that order-processing and credit-control rules respect the live account status.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Mapping account attributes to commerce rules

    iWeb documents which account attributes (buyer role, cost-centre, contract type, account status) drive which commerce behaviours (catalogue visibility, pricing tier, order limits, checkout restrictions). This mapping is built, tested and monitored so that business rules don't drift.

  2. 02
    Building provisioning and deprovisioning automation

    iWeb designs workflows that react to account-system events (user created, role changed, account disabled) and synchronise those changes into commerce, ERP and order-management systems. Idempotency rules ensure that multiple notifications don't cause duplicate or conflicting changes.

  3. 03
    Synchronising account-attribute updates

    iWeb sets up bidirectional flows for attributes like contact details, cost-centre assignments and buyer role changes so that updates made in either the account system or commerce are reflected across the estate. Conflict resolution rules are defined upfront.

  4. 04
    Handling authentication and session token flows

    iWeb configures how commerce requests authentication assertions from the account system and manages token validation, refresh and expiry. Fallback and session-retention rules ensure that brief account-system outages don't break active storefronts.

  5. 05
    Building observability and alerting

    iWeb instruments the integration so that provisioning delays, permission drift, failed deprovisioning and login errors are visible in real time. Exception queues are owned and monitored so that account problems don't cascade silently.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataCustomer identity and authentication credentials
Source / ownerCustomer account system
Maintained byIdentity team or account administrator
NotesCommerce validates logins against the account system; storefronts do not store passwords or authentication tokens.
DataCustomer account status and lifecycle
Source / ownerCustomer account system
Maintained byAccount administrator or provisioning workflow
NotesAccount creation, deactivation and status changes are synchronised to commerce and ERP; commerce reflects the authoritative status but does not independently change it.
DataTrade-account roles, permissions and cost-centre mappings
Source / ownerCustomer account system or contract / master-data system
Maintained byAccount administrator or trade-account manager
NotesRoles and cost-centre rules are synchronised to commerce so that catalogues, pricing and order limits are enforced; commerce applies but does not own the business rules.
DataGroup and role-to-permission mappings
Source / ownerCustomer account system
Maintained byIdentity administrator
NotesGroups and permissions are defined in the account system and provisioned to commerce and ERP so that access control is consistent; storefronts enforce but do not define permissions.
DataSession and multi-factor authentication policies
Source / ownerCustomer account system
Maintained bySecurity or identity team
NotesMFA requirements, session timeout and password-expiry rules are configured in the account system; commerce storefronts enforce these rules at login time.
DataProvisioning and deprovisioning events
Source / ownerCustomer account system
Maintained byProvisioning workflow
NotesAccount creation and termination events are the source of record; commerce and ERP react to these events so that customer records and access are kept in step.
DataIntegration transport, monitoring and exception handling
Source / ownerIntegration layer (owned by iWeb and operations team)
Maintained byOperations team and integration support
NotesAPI calls, data mappings, retry logic and exception queues are monitored and owned by the integration layer so that provisioning, deprovisioning and permission-sync failures are caught and resolved.
10 · Experienced integrator

Built this pattern before

iWeb has connected customer account systems to commerce, trade portals and ERP estates multiple times. We understand how account provisioning, role enforcement, permission drift and deprovisioning fit into a broader commerce architecture and where the operational risks lie.

We map account-system roles, cost-centres and permissions to commerce rules (product visibility, pricing, order limits) so that business policies are enforced consistently at the storefront.
We build provisioning and deprovisioning automation so that account lifecycle events trigger changes in commerce, ERP and order-management systems without manual intervention or orphaned records.
We design fallback policies for account-system outages so that brief failures don't break storefronts and active sessions are managed safely.
We instrument observability and exception handling for authentication failures, permission drift and provisioning delays so that problems are visible and owned.
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Verify that new customer accounts created in the account system are provisioned to commerce within the defined SLA and carry correct roles and cost-centre attributes.
Confirm that deprovisioned accounts are locked out of all storefronts and that active sessions are revoked or expire without manual intervention.
Test that role-based catalogue visibility and pricing tiers are enforced at the storefront so that different buyers see different products and prices.
Validate that permission changes (role updates, cost-centre reassignments) propagate from the account system to commerce and ERP within the agreed time window.
Confirm that authentication requests to the account system are monitored and that failed logins, MFA errors and token-expiry events are logged and alerted on.
Test fallback behaviour when the account system is unavailable: verify that active sessions remain valid, cached tokens are honoured, and login failures are graceful.
Verify that deprovisioning events are idempotent so that duplicate notifications do not create conflicting records or orphaned data in commerce or ERP.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Login breakage after account-system failure

If the account system is down, storefronts may reject all login attempts or allow cached sessions to persist indefinitely. Without clear fallback rules and session retention policies, customers may be locked out or sessions may remain active after the account should have been revoked.

Orphaned accounts after deprovisioning

When an account is disabled in the account system, the corresponding records in commerce, ERP and order-management systems may not be deprovisioned at the same time. Users who are supposed to be locked out may retain order history visibility or active sessions until all systems are updated.

Permission drift between account system and commerce

Changes to buyer roles, cost-centre restrictions or contract-specific pricing made in the account system may not propagate to commerce for hours or may fail silently. Customers see outdated pricing or catalogues, or orders are approved against stale credit limits.

Duplicate or conflicting account records

If account-system events (user created, account merged) trigger provisioning in commerce and ERP without idempotency checking, duplicate customer records, orders or credit-limit entries may be created. Manual reconciliation becomes necessary.

MFA or password-policy changes not enforced

Updates to multi-factor authentication requirements or password-complexity rules made in the account system may not be enforced immediately in storefronts. Sessions started under old policy rules may persist, or storefronts may reject new authentication without warning.

Account attribute mapping breaks after business-rule changes

If trade-account roles, cost-centre definitions or pricing contracts change, the mappings between account-system attributes and commerce rules may become stale or conflicting. No one owns the responsibility to update the mappings, so old rules persist silently.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about Customer account systems integrations.

How are customer accounts provisioned into commerce after sign-up or account creation in the account system?

iWeb sets up an automated workflow so that when a new customer account is created in the account system, a provisioning event triggers the creation of a corresponding customer record in commerce and ERP with the appropriate role, cost-centre and account attributes. The workflow is monitored so that delays or failures are caught immediately.

What happens to a commerce customer record when the account is deprovisioned or deleted in the account system?

iWeb designs a deprovisioning workflow that reacts to account-deletion events by marking the commerce customer record as inactive, revoking active sessions, and notifying ERP and order-management systems so that the customer is locked out and no new orders are accepted. Historical order visibility is preserved for compliance and customer-service reasons.

How are buyer roles, cost-centre restrictions and trade-account attributes enforced in the commerce checkout and product catalogue?

iWeb maps each account-system role and cost-centre attribute to commerce rules (product-visibility rules, pricing tiers, order-limit checks, approval workflows). The mappings are documented, built into the commerce layer and monitored so that storefronts consistently enforce the rules from the account system.

How does the integration handle password changes, multi-factor authentication updates and session timeouts?

The account system is the authoritative source for authentication policy. Commerce storefronts validate login credentials and session tokens against the account system on each request. iWeb ensures that MFA policy changes, password expiry rules and session-timeout changes propagate and are enforced consistently without requiring manual storefront configuration.

What happens to a customer's active session if their account is deprovisioned or their role changes in the account system?

iWeb defines rules for session invalidation and role-change handling. When an account is disabled or a role changes, the integration can either revoke active sessions immediately or allow them to expire naturally based on the timeout policy. The choice depends on security and business requirements.

How are account-attribute updates (address, contact details, cost-centre changes) synchronised between the account system and commerce?

iWeb configures bidirectional synchronisation so that profile updates made in either the account system or commerce are reflected across both systems. Conflict resolution rules are defined upfront (e.g., account system takes precedence for cost-centre changes, commerce takes precedence for delivery address).

What happens if the account system is temporarily unavailable or offline?

iWeb designs fallback policies such as allowing cached authentication tokens to be used for a defined period, preserving active sessions, or routing login requests to a backup authentication endpoint. The fallback rules are documented and tested so that brief outages do not break storefronts.

How are trade-account hierarchies (buyer, approver, delegate) handled in the integration?

iWeb maps account-system hierarchies to commerce so that delegated accounts can act on behalf of primary accounts (if supported), approval workflows respect buyer role restrictions, and cost-centre managers can view subordinate accounts. The mapping is built to match the business model.

How is idempotency managed so that duplicate account provisioning events don't create conflicting records?

iWeb ensures that provisioning and deprovisioning events are idempotent, meaning that the same event triggered multiple times produces only one outcome. Duplicate detection, request deduplication and conflict checking are built into the workflow so that system retries don't cause data corruption.

How are account-system failures and provisioning delays surfaced so that the team knows when something is wrong?

iWeb instruments the integration with observability, alerting and exception queues so that provisioning delays, authentication failures, permission drift and deprovisioning issues are visible in real time. The operations team receives alerts and has a queue of exceptions to investigate.

How does the integration handle account merges or account-status migrations (e.g., converting a consumer account to a trade account)?

iWeb designs workflows for account status changes that synchronise the new account type, roles and permissions to commerce and ERP. The workflow preserves order history, recalculates pricing and access based on the new account type, and notifies dependent systems of the change.

Who owns the mappings between account-system roles and commerce rules, and how are changes managed?

iWeb documents the ownership of each mapping (e.g., business analyst owns cost-centre pricing, commerce team owns product-visibility rules). Changes to mappings are tracked, tested and coordinated across teams so that business-rule changes don't cause silent drift or conflicts.

How are account attributes validated and reconciled between the account system and commerce to ensure data consistency?

iWeb sets up periodic reconciliation jobs that compare account attributes in both systems and flag mismatches. Reconciliation reports are generated so that the team can investigate and resolve drift, such as missing role updates or stale cost-centre mappings.

Can the integration support single sign-on (SSO) across multiple commerce storefronts and trade portals?

Yes. iWeb configures the account system as the central identity provider and connects multiple storefronts and trade portals so that customers log in once and gain access to all channels without re-authenticating. Each channel enforces the same roles and permissions from the account system.

Next step

Have a Customer account systems integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →