Carts / eCommerce

When a new vendor is approved on a marketplace, they need the right security group memberships so they can do their job — list products, manage orders, communicate with buyers — without accidentally gaining admin access.

Why Defaults Matter

• Approval should be a single click — admins shouldn't have to remember to assign 3 groups every time.
• Consistency: every vendor gets the same baseline permissions; deviations are deliberate.
• Onboarding: their first sign-in lands them in the right experience without further setup.
• Compliance: documented default reduces risk of one vendor being over-privileged.

Recommended Default Set

• Vendor: The baseline “you are a vendor” group — controls visibility of vendor menus.
• Marketplace Seller: Permission to create/edit/delete own listings.
• Order Manager: View and update orders for their own listings.
• Vendor Messaging: Send/receive messages with buyers.

Setting Defaults

1. Open Site Settings → eCommerce → Vendor Defaults.
2. Pick the groups to apply on approval (multi-select).
3. Optionally configure per-vendor overrides for specialised vendors (e.g. an Enterprise Vendor gets an extra reporting group).
4. Save.

Worked Examples

• Basic marketplace: Default = Vendor + Marketplace Seller. Everything else is admin-only.
• Two-tier marketplace: Standard vendors get the default set; Premium vendors additionally get the Premium Vendor group with analytics access.
• Healthcare marketplace: Default groups plus a mandatory Compliance Acknowledged sub-group that requires the vendor to accept additional terms before activating.
• B2B wholesale: Defaults include access to bulk-order tools and net-30 invoicing permissions.

Tip: Review default groups annually. As your product evolves, what's appropriate for a new vendor may change — and inertia means stale defaults persist if no-one checks.

ActiveManage's Carts feature gives you a complete eCommerce stack out of the box — product catalogues, baskets, checkout, vendor applications, discount codes, multiple payment methods, and recurring subscriptions. Suitable for B2C storefronts, B2B order portals, and marketplace-style multi-vendor setups.

The platform handles the heavy lifting (payment processing via Stripe, cart state management, order workflow, email notifications, refund handling) so you can focus on the product-specific configuration — what you're selling, how it's priced, and what the checkout looks like.

The main pieces

An eCommerce setup is composed of several related features, each managed independently:

• Carts — the central shopping basket and checkout flow.
• Stripe Integration — the payment processor. Required for any real-money transactions.
• Vendor Applications — for marketplaces with third-party vendors who list their own products.
• Discount Codes — promotional reductions.
• Payment Methods — configurable payment options (credit cards, BACS Direct Debit, Apple/Google Pay, etc.).
• Subscription Packages — recurring product offerings (see the Subscriptions & Feature Sets section).
• Feature Sets — bundles of platform features sold under subscription packages.

Where they all fit together

A user's path from product discovery to confirmed purchase typically:

1. Browses products via a Browse View on the products datastore.
2. Clicks Add to Cart, which inserts a row into a per-user cart-items datastore.
3. Proceeds to checkout, which collects shipping/billing details (via a Custom Form or User Input View) and a payment method.
4. Submits payment, which the platform sends to Stripe.
5. Stripe processes and notifies back via webhook.
6. The platform marks the order as paid, generates an invoice via Document Templates, sends a confirmation email, and (if applicable) notifies the vendor.

Most of that is configurable rather than code-driven, but each step has hooks for customisation when the standard flow isn't quite right.

Three real-world eCommerce configurations

Example 1: Single-vendor B2C storefront

Selling consumer goods directly to customers. One Carts configuration, Stripe connected, products in a single products datastore. No vendor applications. Discount codes used for seasonal promotions. Standard credit/debit card and Apple/Google Pay.

Example 2: B2B order portal

Existing customers (each represented by a Customer record) log in and place orders. Products are priced per-customer (custom price lists). Payment is on invoice rather than at checkout. Carts configuration uses BACS Direct Debit and Bank Transfer as the only payment methods.

Example 3: Multi-vendor marketplace

Multiple independent vendors sell their own products via the platform. Each vendor goes through the Vendor Applications workflow before being approved. Once approved, they list products into their own catalogue (a vendor-scoped Browse View on the products table with row-level security). When a customer buys, the order is split per vendor and each vendor gets a notification.

Where to start

If you're building eCommerce on ActiveManage for the first time, work in this order:

1. Build the products datastore — name, SKU, price, stock level, image, description.
2. Configure Stripe in Site Settings → Stripe (test mode first).
3. Create a Carts configuration pointing at your products datastore.
4. Run an end-to-end test purchase using Stripe's test cards.
5. Add discount codes, payment methods, and any other tunings.
6. Switch Stripe to live mode only after everything works in test.

Force Single Payment Method restricts a cart to one specific payment method, hiding the picker. Useful for subscription-only flows, enterprise invoicing arrangements, and country-specific payment requirements.

When to Use It

• Recurring subscriptions: Force direct debit only — cheaper renewals than card.
• Enterprise contracts: Force invoice — net-30 billing.
• High-value transactions: Force bank transfer for orders over £10k.
• Regional requirements: Force iDEAL for Dutch customers, Bancontact for Belgian.
• Loyalty cashbacks: Force account-credit redemption for cashback uses.

Where to Set It

• Per-cart: Override on a specific cart record.
• Per-product: A subscription product enforces direct debit.
• Per-customer: Trusted enterprise customer forces invoice.
• Per-tenant: A B2B tenant forces invoice across all their carts.

User Experience

With force enabled, the checkout payment step shows the forced method as the only option — no “Use a different method” link, no picker. Communicate the constraint clearly on the product or cart page to avoid surprise.

Worked Examples

• SaaS subscription: Pro plan enforces direct debit; product page says “Pro is billed monthly by direct debit only”.
• Enterprise tenant: All carts force invoice; checkout skips payment step entirely and goes straight to confirmation.
• EU consumer site: Cart-level rule detects Dutch buyer → force iDEAL.
• Cashback redemption: Cart with cashback applied forces account-credit redemption rather than charging card.

Warning: Force a method only when you've validated the customer can use it. Forcing direct debit on customers who don't have a UK bank account leaves them unable to complete checkout.

Setting up a Cart is a multi-step process — picking the product datastore, configuring the checkout flow, and connecting a payment provider. Each piece is independently configurable, so once you have one working Cart, additional ones (for different product lines, different audiences, different regions) are quick to create.

1. Pick the product datastore

Every Cart needs a backing datastore for its products. Either use an existing one (if you've already modelled your products elsewhere) or create a new datastore with the fields the cart will need.

Typical product datastore fields:

• Name (Text Box).
• SKU (Text Box, Unique).
• Description (Text Area or WYSIWYG Editor).
• Price (Number, with appropriate decimals).
• Currency (Dropdown Manual with valid options — though most carts run a single currency platform-wide).
• Stock Level (Number).
• Image (File Upload).
• Categories / Tags (Dropdown DB or Tickbox Multiple DB).
• Active (Toggle Switch — only Active products appear in the catalogue).

For B2B catalogues where prices vary per customer, add additional fields like list_price, contract_price, discount_percent and compute the displayed price at render time.

2. Configure the cart settings

From the Architect Panel → Commercial → Carts, create a new Cart configuration:

• Name — internal name ("Main Storefront", "B2B Order Portal", "Subscription Sales").
• Product Datastore — pick the one you just set up.
• Currency — the cart's primary currency. Multi-currency requires more work (covered separately).
• Tax Handling — single rate, per-product rate, or zero (when prices include tax already).
• Shipping Options — fixed, calculated, free, or no shipping. Configure shipping zones if applicable.
• Allowed Payment Methods — pick from the configured Payment Methods list.
• Approval required? — for B2B carts, sometimes orders need admin approval before being processed. Configure this here.

3. Connect Stripe

Carts and Stripe go together — almost every cart needs payment processing, and Stripe is the platform's primary provider.

Add your Stripe API keys (public + secret) under Site Settings → Stripe. Test mode keys first; live mode keys after you've verified the full flow.

4. Test the checkout flow

Use Stripe's test mode to run a full purchase before going live:

1. Browse the catalogue, add a product to cart.
2. Proceed to checkout, fill in details.
3. Use Stripe's test card 4242 4242 4242 4242 with any future expiry, any CVC.
4. Submit payment. Stripe should accept and the order should complete.
5. Verify the confirmation email arrives.
6. Verify the order appears in the orders datastore with the correct details and status.
7. Verify Stripe's dashboard shows the test transaction.

Once that works, switch Stripe keys to live mode and run one more end-to-end test with a small real transaction. Refund yourself after.

Three real-world cart configurations

Example 1: Single-currency consumer storefront

Currency: GBP. Tax: 20% VAT on all products. Shipping: £4.99 fixed, free over £50. Payment methods: Card, Apple Pay, Google Pay. Approval: not required.

Example 2: B2B trade portal

Currency: GBP. Tax: 20% VAT, with per-customer tax exemption flag honoured. Shipping: tiered by weight. Payment methods: Card, BACS Direct Debit, Bank Transfer (invoice). Approval: required for orders over £5,000.

Example 3: Subscription-only product

Currency: USD. No physical shipping. Payment methods: Card. Initial purchase ties to a Subscription Package; renewals process automatically. Approval: not required.

Tip: Configure your Cart in Stripe test mode and run at least 5-10 dummy purchases before going live. Each iteration reveals different gotchas — a typo in a tax calculation, a missing confirmation email, a broken thank-you page. It's much cheaper to find these in test than in production.