Self-service payment portal — real-time invoices, balances, payments & credits

Customers log into a branded payment portal, see their ERP-sourced real-time account detail — open invoices, total outstanding balance, available account credits, saved payment methods, payment history, statements — and act on any of it.

They can pay a single invoice, pay several invoices consolidated into one transaction, make a partial payment, apply an account credit, download a statement or receipt, save a new payment method (tokenized), update billing contacts, or enroll in autopay. All of it is available 24/7 without a phone call to your AR team.

Yes. The same real-time ERP-sourced data drives both the customer-facing portal and the internal team view — your AR clerk, sales rep, controller, or branch manager sees the customer's current open invoices, balance, credits, payment history, and saved methods in a team-facing version of the same portal.

When a customer calls asking "what do I owe", the rep on the phone is looking at the identical number the customer would see if they logged in — no lookups, no spreadsheet, no "let me check with accounting and call you back." The team view adds operational context (credit hold notes, collections history, payment-method expiration flags, cross-sell opportunities) that the customer doesn't see, but the core balance and invoice data is identical across both audiences.

Sub-second in the typical case. When a new invoice posts in the ERP, the customer portal reflects it within seconds. When a payment captures through Payment Hub, the customer's balance updates immediately — the customer sees "payment processed" with the new balance on the screen they're still looking at.

When AR adjusts an invoice or applies a credit in the ERP, the customer's portal picks up the change on next refresh. There's no nightly-batch "portal sync" that leaves customers looking at yesterday's data. The portal isn't a copy of ERP data — it's a live read from the ERP through Clarity Connect every time it renders.

Yes. The customer portal includes an aging view — Current, 31–60, 61–90, 90+ — showing which invoices are in each bucket and the total owed in each. Past-due invoices are flagged on the main open-invoices list with a visual indicator so customers see at a glance what needs attention. Customers can click any past-due invoice to pay it directly.

For businesses where automated past-due reminders are configured, customers receive an email with a direct pay link that takes them to the exact invoice in the portal ready to pay in one click. This combination — portal visibility plus proactive reminder emails — typically clears a meaningful share of 30–60 day aging without staff time.

No. A customer who does business with multiple locations, entities, or subsidiaries of your organization sees a consolidated view across all of them — total outstanding across all entities, invoices from each, aging rolled up or broken down by entity.

They have one login that represents their overall relationship with your business, regardless of how many ERP entities or branches they buy from. This matters for multi-location distributors and franchise operators where the customer has one procurement relationship but buys from five of your branches.

Yes. Credit card (Visa, Mastercard, AmEx, Discover), ACH / eCheck, saved tokenized methods, wallet methods (Apple Pay, Google Pay, Amazon Pay, PayPal) where your gateway supports them, and customer account credits.

The portal respects whatever method configuration you've set — if your policy allows ACH for invoice payments over $2,000 but requires card below that threshold, the portal enforces that. Commercial cards automatically trigger Level III enrichment for the interchange savings. Surcharging (where permitted by state law) is configured centrally and applied uniformly to portal transactions.

Yes. Payment methods (cards and ACH) are tokenized at the gateway vault and stored on the customer's account — not on Payment Hub's servers or on the customer's browser. The customer selects "save this card" at any payment moment and the tokenized reference attaches to their profile.

On next login, they see the method listed (last 4 digits, expiration, nickname) and can pick it for one-click payment. They can add or remove methods, mark one as default for autopay, and delete methods they no longer use. Raw PAN never touches Payment Hub; this is also why the portal keeps your compliance footprint light (lower PCI SAQ scope).

Yes. Customers self-enroll in autopay from the portal — pick a saved payment method, pick the trigger rule (every invoice, every invoice over $X, monthly statement, etc.), review terms, and confirm. The enrollment stores in Payment Hub; every triggering event runs the scheduled payment automatically.

Customers can pause, update, or cancel autopay anytime from the same portal. Your AR team also sees which customers are on autopay and can enroll or unenroll on a customer's behalf if the customer prefers to handle it over the phone. Autopay runs the existing saved method; if the method fails or expires, the customer gets an email and the autopay pauses until they update.

Fully branded. The portal lives at your subdomain (e.g., pay.yourcompany.com or app.yourcompany.com/pay), uses your logo, your color palette, your receipt templates, your terms-of-service language. Customers experience it as part of your business, not as a Clarity product. Email notifications (receipts, past-due reminders, autopay confirmations) come from your sender address with your branding.

White-label deployment is standard. Co-branded deployments (your branding plus "Powered by Clarity Payment Hub") are available when partners want the attribution.

Raw card data never touches Payment Hub infrastructure or your servers. The customer's payment-form keystrokes post directly to the gateway's PCI-scoped vault through a hosted iframe / JS-token pattern; a tokenized reference comes back to Payment Hub for future use. This keeps the portal in SAQ A / SAQ A-EP scope (the lightest PCI scope), dramatically lowering your compliance burden versus self-hosting card handling.

Authentication supports SSO (SAML, OAuth, Microsoft / Google identity providers) for B2B customers who want to use their corporate login; it also supports magic-link email authentication for customers whose AP teams don't have corporate SSO. Two-factor authentication is optional / configurable.

Yes. Partial payment: customer selects an invoice and enters any amount less than or equal to the invoice balance; the payment applies, invoice balance decrements in the ERP in real time. Split-payment: customer applies an account credit to an invoice and pays the remainder with a saved card, or splits a payment across two cards if the gateway supports it.

Every partial / split payment posts cleanly to the ERP — no manual reconciliation between the invoice record and the partial-payment records, no stranded cash receipts on the customer's account.

48 hours to go-live once Clarity receives your ERP sandbox credentials, gateway credentials, customer portal subdomain preference, and basic branding assets (logo, color, terms text). The portal is available to customers the moment the DNS points to the right endpoint.

For a complete rollout — communicating to customers, training AR / sales staff on the team-facing view, configuring autopay rules, setting up past-due reminder templates — most businesses budget 2–4 weeks from go-live to full adoption. Your existing gateway, merchant account, ERP, and customer records all carry forward; nothing needs to be migrated or reconfigured on the backend.