Skip to main content
Commerce processes payments through your account’s connected payment processor — Stripe via OAuth or Authorize.Net via API credentials. Once connected, clients can pay invoices through the client portal using cards, ACH (where supported), and Apple Pay / Google Pay. The Payments UI is at /dashboard/commerce/payments/, with processor connections stored in crm_payment_integrations.

​
Supported processors

You can only have one active processor at a time per account. If you switch processors mid-stream, existing saved payment methods don’t migrate — clients will need to add their cards again on the new processor.

​
Connecting Stripe

1

Open Payment Settings

Go to /dashboard/commerce/settings/ and click Connect Stripe.
2

Authorize via Stripe OAuth

You’re redirected to Stripe’s hosted OAuth page. Sign in to your Stripe account and authorize Hiveku to charge customers on your behalf.
3

Pick test or live mode

Stripe accounts have separate test and live environments. Pick which mode this connection is for. Most accounts run live in production with a separate test account for staging.
4

Verify the connection

Hiveku stores the OAuth access token in crm_payment_integrations. The connection page shows “Connected” with your Stripe account ID.
Stripe OAuth tokens can expire if your Stripe account changes ownership or if you revoke access from Stripe’s side. Keep an eye on the connection health indicator — a disconnected processor means clients can’t pay invoices.

​
Connecting Authorize.Net

1

Get your credentials

From your Authorize.Net merchant account, get the API Login ID and Transaction Key. For webhooks, you’ll also need a Signature Key.
2

Open Payment Settings

Go to /dashboard/commerce/settings/ and click Connect Authorize.Net.
3

Enter credentials

Paste the API Login ID, Transaction Key, and Signature Key. Pick sandbox or production.
4

Test a sandbox transaction

Run a test charge from the settings page to verify credentials work. The sandbox test card 4111 1111 1111 1111 should succeed.
5

Configure webhooks (optional but recommended)

Set up Authorize.Net to send transaction webhooks to Hiveku for automatic reconciliation. The settings page shows the webhook URL.

​
Accepting payments

Once connected, three places clients can pay:
  • Client portal — Most common. Click pay, enter or pick card, submit.
  • One-time payment links — For invoices sent to people who don’t have CRM records.
  • Saved-method auto-charge — For subscriptions, the saved card on file is charged automatically each cycle.
Apple Pay and Google Pay are available on portal payment pages when the client’s browser supports them — no extra setup needed for Stripe; Authorize.Net’s wallet support varies.

​
Saved payment methods

Saved methods are stored at the processor (not at Hiveku) for PCI compliance. Clients can:
  • Save a card or ACH on first payment
  • View masked last-4 digits in the portal
  • Set a default method for subscriptions
  • Remove old methods
You can attach a saved method to a subscription so each cycle’s invoice auto-charges without client action. The first time the method fails, the dunning policy kicks in — see Subscriptions — failed payments.

​
Refunds

From the invoice’s payment record, click Refund. The full amount goes back to the original payment method. The invoice transitions to refunded.
Refund timing depends on the original payment method:
  • Cards — 5–10 business days to appear on the client’s statement
  • ACH — 7–10 business days, sometimes longer
The processor’s transaction log is the source of truth. Hiveku reflects the refund as soon as the processor confirms it via webhook.

​
Failed payment retry policy

For subscription-driven payments, the dunning policy controls retries. Configure in /dashboard/commerce/settings/:
  • Retry intervals — Default: 24 hours, 3 days, 7 days
  • Retry count — Default: 3 attempts
  • Past-due grace period — Default: 14 days before auto-cancellation
  • Email cadence — Notify client on each failure (default on)
  • Internal alerts — Notify your team when a sub goes past_due (default on)
For one-off invoice payments, retries don’t apply — the client retries manually from the portal if their first attempt fails.

​
Reconciliation

Reconciliation is matching incoming payments to outstanding invoices. Three paths:
Stripe and Authorize.Net webhooks carry the invoice ID. Hiveku marks the invoice paid and records the transaction. No manual step needed for the vast majority of online payments.

​
Tax configuration

Tax settings live in /dashboard/commerce/settings/:
  • Default tax jurisdictions — Per state, province, or country, with the applicable rate
  • Tax-exempt clients — Set on the contact or company; their invoices skip tax
  • Per-product taxable flag — Set on the product; non-taxable products skip tax even on taxable clients
  • Tax ID display — Your business’s tax ID shown on invoice PDFs (VAT number, EIN, ABN, etc.)
For complex multi-jurisdiction tax (e.g., US sales tax across many states), most accounts pair Hiveku’s tax with an external service like Avalara or TaxJar — set the rates Hiveku uses based on what your tax service determines, or call out to the tax service via API at invoice generation time.

​
PCI scope

Hiveku’s payment flow is designed to keep your PCI scope minimal:
  • Card data is tokenized client-side. The browser sends card details directly to Stripe/Authorize.Net via their JS SDKs.
  • Hiveku stores only the token reference. No card numbers, no CVCs, no expiration dates touch your servers.
  • Saved methods live at the processor. Hiveku uses Stripe Customer IDs and Authorize.Net Customer Profile IDs.
This puts you in PCI SAQ-A scope, the lowest tier — you self-attest to a short questionnaire annually rather than going through full PCI audits.
Don’t bypass the tokenization flow by emailing yourself card numbers, taking them over the phone, or storing them in a spreadsheet. That moves you into a much higher PCI scope and creates real liability. Always direct clients to the portal.

​
API patterns

Common operations against /api/crm/billing/*:
  • GET /api/crm/billing/integrations — list connected processors
  • POST /api/crm/billing/integrations — initiate a new connection
  • POST /api/crm/billing/refunds — issue a refund
  • POST /api/crm/billing/charges — direct charge against a saved method (rare; usually subscriptions handle this)
  • GET /api/crm/billing/transactions — list transactions across processors

​
Troubleshooting

The OAuth token may be valid but the underlying Stripe account is restricted (Stripe puts new accounts through review for high-risk industries). Log into Stripe Dashboard and check for any verification requirements or restrictions on your account.
The API Login ID is account-specific and case-sensitive. Re-copy from Authorize.Net’s settings, paste without trailing whitespace. Also verify you picked the right environment — sandbox credentials don’t work against production and vice versa.
Refunds need the original payment to be in succeeded status at the processor. If the original was an ACH that’s still pending settlement, you can’t refund yet — wait for it to clear. Also: refunds older than the processor’s window (90 days for Stripe, varies for Authorize.Net) may need to go through the processor directly.
Stripe webhooks are auto-configured by the OAuth flow; if events aren’t arriving, check the connection health and re-authorize if needed. For Authorize.Net, the webhook URL must be set in your Authorize.Net dashboard pointing to Hiveku — paste the URL shown in payment settings.
Three things to check: (1) the line item’s taxable flag is on, (2) the client isn’t flagged tax-exempt, (3) the tax rate is configured for the client’s billing jurisdiction. Edit the draft invoice and look at the line item — the tax rate should display next to the amount.

​
What’s next?

Send Your First Invoice

End-to-end including processor connection.

Subscriptions

Recurring billing and dunning policy.

Client Portal

Where clients enter their payment info.

Reports & Analytics

Cash collected, transaction volume, and refund reporting.