Configuration

Core settings

• Store defaults: base currency, locale formatting, and tax/shipping rules (including weight-based shipping bands).
• Payment methods: configure Stripe and PayPal credentials, enable or disable each method, and choose redirect or on-page (express) checkout. Cash on Delivery and bank transfer are offline methods that need no gateway credentials — set the bank-transfer instructions customers see, and record payment manually when it arrives. COD is on by default.
• Email templates: enable order confirmation, shipped, and refunded notifications.
• Visual overrides: set storefront colors, choose a light / dark / automatic theme, pick a structure preset (Flat or Classic), and template adapter defaults.
• Catalog & inventory: set the low-stock threshold that drives the "Only N left" / "Low stock" indicators (0 disables them).
• Checkout compliance: require a terms-acceptance checkbox (with a terms version and the link customers see), and show a configurable right-of-withdrawal notice.
• Security controls: require HTTPS at checkout (on by default; local, private, and development hosts — localhost, private IPs, .test/.local domains — are exempt automatically), set trusted proxy IPs when you're behind a reverse proxy or CDN (see Behind a reverse proxy), and tune checkout/coupon rate limits and webhook validation.
• SEO: toggle canonical-URL redirects and set per-product / per-category meta title and description overrides.
• Order operations: configure stale-order cleanup, post-purchase account creation, and offline payment options.

Store settings

Payment gateways

Tax rules

Shipping rules

Recommended setup

1. Set the base currency and locale formatting.
2. Configure payment gateway credentials and test webhooks.
3. Create tax and shipping rules.
4. Review GDPR options and data retention settings.

Advanced configuration notes

• Price display locale: optionally force formatting (for example mk-MK) instead of automatic Joomla language detection.
• Stale order cleanup: enable scheduled cancellation of pending orders after a threshold.
• Auto-send emails: control whether shipped/refunded notifications are sent automatically or manually.
• Offline payments: enable COD/bank transfer only when your operational process is ready.

Behind a reverse proxy, load balancer, or CDN

When Joomla sits behind a proxy that terminates TLS — Cloudflare, an nginx/Apache reverse proxy, or a load balancer — every request reaches Joomla from the proxy's address. Unless you tell NXCart which proxy to trust, two things go wrong:

• Rate limits and audit logs collapse to the proxy. The checkout and coupon rate limits key off the client IP; behind a proxy that's the proxy's IP for every shopper, so they all share one budget (a busy store can throttle legitimate customers) and the security log shows the proxy instead of the real visitor.
• HTTPS at checkout can be blocked on a genuinely-HTTPS site. Most proxies forward an X-Forwarded-Proto: https header and checkout works automatically — but a proxy that forwards the scheme differently (e.g. X-Forwarded-Ssl: on) or not at all leaves NXCart seeing a plain-HTTP hop, so Require HTTPS for checkout blocks it and shoppers see "Secure connection required for checkout."

To fix both, list the proxy under Settings → Security → Trusted proxy IPs:

1. Find the proxy's address — for a self-hosted reverse proxy that's usually the server's internal address (often 127.0.0.1 / ::1); for Cloudflare, its published IP ranges.
2. Enter it comma-separated; CIDR ranges like 10.0.0.0/8 are allowed.
3. Save. NXCart now reads the real client IP from X-Forwarded-For and trusts the forwarded HTTPS scheme — but only from that proxy.

Listing a proxy is deliberately opt-in: until you do, forwarding headers are ignored so a visitor on a directly-exposed HTTP vhost can't spoof them. Set it only for a proxy you actually control.

For payment endpoint setup and diagnostics, see Payments & Webhooks.
For state flow, review flags, and manual transactions, see Order Lifecycle.