When displaying a price to a customer, there are two common conventions: either the displayed price already includes tax (inclusive), or tax is calculated and added on top at checkout (exclusive). OurPay stores this preference at both the organization level and on individual product prices for deployments that have configured a tax service.
The production path is wired to use Numeral as its sole tax calculation and compliance provider, but it is active only when the Taxes dashboard reports Numeral production connected. In that mode, each organization is sent as its own Numeral merchant and OurPay declares its marketplace_provider role. Numeral returns tax only where the platform’s production account has an active collection obligation, and completed sales, refunds, lost disputes, and their reversals are sent to Numeral for the correct filing period. An sk_test_ integration is sandbox-only and never files or remits.

​
Tax Behavior Options

There are three options available:
Location-based is the product default. With a configured tax service, customers in the United States, Canada, and India see exclusive presentation, while customers elsewhere see inclusive presentation. Confirm that this convention is appropriate for your products and jurisdictions before enabling tax calculation.

​
How it affects checkout

  • Inclusive: If an enabled tax service returns a 20% rate for a product priced at $12.00, the customer pays $12.00 — $2.00 is recorded as tax and $10.00 as the net amount.
  • Exclusive: If an enabled tax service returns a 20% rate for a product priced at $10.00, the customer pays $12.00 — $10.00 net plus $2.00 recorded tax added on top.
The provider-returned tax amount is itemized on checkout and receipts. OurPay uses Numeral’s actual per-jurisdiction amounts rather than reconstructing tax from displayed statutory rates. When a checkout has a validated customer IP address, OurPay sends it to Numeral together with the billing address as additional location evidence; Numeral remains responsible for selecting and reporting the location source used for the calculation. Every non-zero checkout in a tax-enabled deployment requires a complete billing address, including products classified as non-taxable, because the completed sale still needs a provider record. A subscription preview may remain available while an older customer repairs missing details, but OurPay will not create the real renewal charge with a silent zero-tax fallback when the address is missing or Numeral rejects it. The seller must also have an active Numeral merchant profile. Submitting seller verification creates or updates that profile from the seller-submitted legal name, registered address, and GSTIN (when provided); a missing profile blocks payment instead of assigning the sale to another tax account. Customer-sale tax and tax on OurPay’s own fee are separate records. Customer sales use Numeral’s platform calculation with the organization as merchant. After payment, the exact OurPay fee left after fee credits is recorded as an inclusive business-to-business payment-processing service with OurPay as seller. Its tax is contained within the configured fee, so it does not increase either the customer charge or the seller’s fee deduction. Legacy subscriptions that were previously marked to avoid a post-registration price increase keep their existing gross customer price by switching to inclusive presentation. The tax provider still calculates and records tax, and the seller absorbs it inside that price. That legacy price flag is not treated as evidence that the customer is legally exempt.

​
Production activation

Code deployment does not create tax registrations or authorize withdrawals for remittance. Before turning on tax calculation and transaction reporting, the deployment operator must:
  1. Complete Numeral’s production onboarding for the OurPay platform entity, including legal documents, portal credentials, filing approvals, and a funded remittance method.
  2. Confirm with qualified counsel which jurisdictions make OurPay a marketplace facilitator and which liabilities remain merchant-responsible.
  3. Enable Numeral’s registration and filing automation for the approved jurisdictions in the Numeral dashboard. Ask Numeral to enable the gated approve_filing MCP capability if filing approval should be available from the OurPay operator workflow; otherwise approvals remain in the Numeral dashboard.
  4. Configure OURPAY_NUMERAL_API_KEY with an sk_prod_ key and use Numeral as the only calculation and recording processor. Production API, worker, and scheduler processes refuse to start with a sandbox key or a different tax processor, so an unsafe tax runtime cannot accept payments.
  5. Synchronize sellers submitted before the integration was enabled:
  6. Verify the Taxes dashboard reports Numeral production connected, Seller profile ready, Provider reconciliation: 0, no unexplained nexus gaps, and no filing approval, payment, or problem states.
OurPay retries recent sale, refund, refund-reversal, lost-dispute, and dispute-reversal events that are still missing the expected Numeral record or reversal, using idempotent low-priority jobs. The Taxes dashboard counts those pending provider actions; it does not claim to compare every field in the remote transaction. A daily production audit also verifies that the authenticated Numeral account exposes the required nexus, registration, and filing capabilities, then fails the operational check when a registration gap, filing approval, remittance payment, provider problem, or reconciliation item needs attention. Operators can inspect older history without writing anything, then enqueue the same repairs:
Do not approve a filing while Provider reconciliation is nonzero. Review returns from the same authenticated provider account before approving them:
The first approve run is a dry run. It prints the current provider record, its SHA-256 review digest, the pending-record count, and whether Numeral has enabled API approval. The operator must compare the provider filing’s calculated sales data with the accounting ledger; a zero count only means no known local event is waiting for creation or reversal. When the record has been reviewed and the count is zero, an operator can submit that exact version:
OurPay never retries the approval write: an interrupted request has an unknown outcome and must be checked in Numeral before another attempt. Registration, return calculation, submission, payment, and the final filed state remain provider-owned. Numeral currently exposes registrations and remittance as read-only compliance state; complete those actions and supply authority credentials or funding in the Numeral dashboard. OurPay records commerce events, monitors provider state, and does not fabricate a filed or remitted state from its own ledger.

​
Setting the Default Tax Behavior

The default tax behavior applies to all products in your organization that don’t have a price-level override. To change it:
  1. Go to your organization’s settings.
  2. Find the Default tax behavior selector under the Payments section.
  3. Choose Location-based, Inclusive, or Exclusive.
  4. The setting is saved automatically.

​
Location-based Behavior in Detail

When tax calculation is enabled and behavior is set to Location-based, OurPay resolves the inclusive/exclusive presentation at checkout from the customer’s billing address: This is a presentation default, not a tax determination. Confirm the correct treatment and customer-location evidence for every jurisdiction in which you sell.

​
Relationship with the current collection model

Your organization is the invoice issuer in the current collection model. When the Taxes dashboard verifies production mode, tax behavior controls whether the Numeral-calculated amount is included in the listed price or added on top. OurPay then records the returned breakdown on checkout, orders, invoices, and receipts and commits completed transactions, refunds, and lost-dispute adjustments to Numeral. The Taxes dashboard separates organization-specific merchant readiness and sales totals from Numeral’s platform-account registrations and filings. Those provider counts cover OurPay’s marketplace-facilitator obligations; they are not proof of a seller-specific return or payment. This integration does not make OurPay the legal Merchant of Record, and sellers remain responsible for merchant-responsible transaction taxes plus their own income and business taxes.
Changing the tax behavior on a price does not change the effective tax rate or your tax obligations. When tax calculation is enabled, it changes whether the stated price is presented as tax-included or tax-excluded to the customer.