Order-to-cash — payments on sales orders, not just invoices

No — invoice payment is one step in order-to-cash. The full order-to-cash loop starts when a quote converts to an order and runs through fulfillment, invoicing, payment, and cash application. Payment Hub is usually thought of as "the invoice-payment tool" but actually integrates across the whole loop — it can accept payment at the point of order entry (deposit or full authorization), track the authorization through fulfillment, capture against the final invoice at shipment, and post the cash receipt to the ERP.

The "order-to-cash" use case on this page focuses specifically on the capabilities that light up when payment is embedded at order-entry rather than waiting until an invoice is generated and emailed. Most merchants benefit from both patterns — some orders take deposits at entry, some invoice post-delivery and collect after — and Payment Hub supports both patterns running in parallel.

Any channel where your business takes orders. Sales reps enter orders inside your CRM or ERP (NetSuite, Dynamics, Acumatica, Sage, SAP, Epicor, Infor, etc.) with Payment Hub embedded in the order-entry screen for taking card or ACH on the spot. Customers enter orders through your B2B portal (self-service ordering with saved payment methods). Shoppers check out on your eCommerce storefront. Counter staff ring up walk-in orders on certified POS terminals.

Field-service techs take payment on-site using Tap to Pay on iPhone / Android or Bluetooth-paired terminals. Phone-in / email-in orders key through the Virtual Terminal for MOTO. The same payment-acceptance and ERP-integration layer handles every channel.

Yes. Clarity Connect embeds Payment Hub's payment-acceptance flow inside the ERP's sales-order or quote-to-order screen. The rep builds the order, selects "take payment", and Payment Hub presents a card-entry form (or a saved-method selection if the customer has tokenized methods on file) inside the ERP UI — no app-switching, no copy-paste of card numbers, no emailed invoice-link for the customer to click later.

Payment captures, the transaction ID attaches to the sales order, and the deposit or full payment posts to the ERP as a cash receipt. This is especially useful for order-entry-heavy businesses (inside-sales teams taking a steady flow of phone orders, trade-show order-taking, pre-sale deposit-capture on custom configurations, and the like).

Payment Hub supports three common order-time payment patterns. (1) Deposit at order: the customer pays a percentage (say 30%) at order entry; the balance is invoiced and collected at delivery or on Net terms. (2) Full payment at order: the customer pays 100% at order entry (common for eCommerce, for non-account B2B, and for pre-sold services). (3) Authorization at order, capture at shipment: the full amount is authorized on the card at order entry (funds reserved but not settled) and captured — for real — when the order actually ships.

This is useful for backorder situations where the merchant doesn't want to charge the card until goods move, but wants to lock the authorization to avoid declined cards mid-fulfillment. All three patterns post to the ERP correctly — deposit as a customer deposit, full payment as a cash receipt against the order, authorization-then-capture as a cash receipt on the invoice at the time of capture.

Payment Hub handles partial shipments cleanly. When an order authorizes at entry for the full amount, Payment Hub holds the authorization; each shipment triggers a partial capture against the authorization up to the shipped line-items' value. The last shipment releases the remaining authorization.

For deposits, the deposit sits on the customer's account; partial invoices generated from partial shipments draw against the deposit until it's consumed, then invoicing and collection continue on Net terms or through customer-portal payment. The ERP record stays accurate throughout — deposit applied, partial captures logged, remaining balance visible — without manual reconciliation between shipment events and payment events.

No. Payment Hub integrates with whichever CRM / CPQ / quote-to-order tool your sales team already uses — Salesforce, Dynamics 365 CRM, HubSpot, SAP, Oracle, Acumatica CRM, NetSuite CRM+, and others. The integration provides payment-acceptance inside the tool your team lives in rather than requiring them to jump to a separate payment system. Quotes, configurations, opportunity tracking, commissions, and sales-pipeline reporting stay where they already are.

Payment Hub adds the payment-acceptance layer and the ERP-side cash-application layer so that when an opportunity converts to an order, payment can be taken without switching contexts and the resulting cash receipt posts to the ERP automatically.

Yes. Field-service techs take payment at the customer site using Tap to Pay on iPhone / Android, Bluetooth-paired mobile terminals, or a phone-friendly web payment form sent to the customer via SMS or QR code on the service ticket. The payment attaches to the field-service work order / job in the ERP, applies to any deposit or existing invoice, and posts as a cash receipt in real time.

For service-industry order-to-cash (plumbing, HVAC, locksmith, IT services, and similar), this closes the gap between "job done" and "payment in the ERP" from days to minutes — and eliminates the "I'll mail you a check" conversation that converts 30% of field invoices into 60-day aging.

The channels and timing patterns vary by industry. Distribution: sales reps take phone/field orders with 30% deposit; branch counters take walk-in orders with full payment; eCommerce / B2B portal takes customer self-serve orders with full or authorization-capture. Manufacturing: large configured orders often take 30–50% deposits at entry with balance on delivery; high-dollar capital goods may take milestone-based payments.

Professional services: engagements invoice on completion with Net terms (classic AR), but retainers and fixed-scope projects often take payment at engagement-start. Field service: payment at job-completion using mobile, card-present. Healthcare: copay at appointment, procedure balance after insurance processing. Payment Hub handles all these patterns against the same ERP; industry-specific configurations dictate which patterns light up where.

Payment Hub deployments go live in 48 hours once Clarity receives ERP sandbox credentials, gateway credentials, and confirmed channel configuration. Which channels are enabled (sales rep, portal, eCommerce, counter, field, MOTO) depends on your business — a distribution client might light up rep + counter + portal at go-live; a field-service client might start with mobile + MOTO. Additional channels can be added in subsequent 24–48 hour windows as the rollout matures.

For clients already running Payment Hub on invoice-payment, extending to order-to-cash is typically a matter of additional Clarity Connect configuration on the ERP's sales-order + CRM side, not a new deployment. Your existing gateway, merchant account, negotiated rates, and payment-acceptance infrastructure all carry forward.

Yes. L3 enrichment applies to order-time payments the same way it applies to invoice payments. When a deposit or full-payment-at-order captures on a qualifying commercial card (Visa / MC Corporate, Purchasing, Fleet, Government, Business), Payment Hub pulls the order-line data from your ERP — line items, UoM, product codes, freight, tax, customer code, destination ZIP — and packages it into the L3 envelope submitted to the gateway.

The 0.3–1.0% interchange savings apply on order-time commercial-card payments exactly as they do on invoice-time payments. For businesses with sales-rep-driven B2B / B2G order flow, order-time L3 optimization is often the single largest share of total L3 savings across the business.

Payment Hub handles partial refunds natively. If a partial shipment has gone out and been paid for, a refund returns only the shipped-and-paid portion to the card; the un-shipped balance of the order can be canceled (releasing the remaining authorization) or left in place to ship later. If a deposit has been paid and the entire order is canceled before shipment, the deposit refunds to the original card. All refund events post back to the ERP as reversing cash receipts, and the ERP's customer deposit / AR records stay in sync.

Refund authority is role-controlled — counter staff can do small refunds up to a threshold; larger refunds require branch-manager or controller approval. Audit trail captures which staff member authorized each refund and why.

Yes. Payment timing is set per-order, not per-customer. A single customer might pay 100% upfront on a $400 counter walk-in, pay a 30% deposit on a $12,000 phone order for custom goods, and be Net-30 on a recurring $2,000 catalog order — all at the same time. Payment Hub routes each order's timing pattern based on how the order was entered (channel), the order size, and any customer-profile overrides.

This matters in practice because most B2B businesses don't operate on a single payment-timing pattern. Rigid "invoice-only" or "pay-upfront-only" systems force customers into one pattern; Payment Hub meets the customer where the order actually needs to land.