OurPay operates as merchant of record (MoR) and authorized reseller for products and services. The customer buys through OurPay; the supplier fulfills and supports the product. Every lawful product and service category is eligible, subject to the actual transaction’s legal and provider requirements. The reseller role covers the sale contract, customer charge, invoice, refunds, disputes, and applicable transaction-tax obligations under the seller and buyer terms. Payment software and a central processor account do not create that legal status by themselves.

​
Current implementation

The current deployment uses a central PayPal Business account. Some implementation details still identify the organization as the seller and invoice issuer and require alignment with the reseller model. The table below describes the existing code, rather than a separate commercial model: This is a central collection arrangement. It does not onboard the organization as a PayPal merchant or transfer captured funds to a seller while the payout feature remains disabled.
The merchant-of-record model is confirmed. Current invoice identity, the configured Numeral role, processor permissions, and supplier settlement must still agree with that model before a live resale. Website terms do not change invoice templates, activate tax services, or execute payouts.

​
Payment Service Provider versus Merchant of Record

A payment service provider supplies the rail used to authorize, capture, refund, and dispute a payment. The seller usually retains the sale and tax obligations. An MoR adds a separate legal and operational layer by becoming the seller or reseller. That can reduce a supplier’s indirect-tax work, but only when the contracts and actual transaction flow make the MoR responsible. Higher-level billing APIs, tax calculations, or a platform-branded checkout are not enough on their own. OurPay provides product, checkout, subscription, invoice, tax-record, and ledger machinery. The deployment operator must configure and verify those records for OurPay’s reseller role.

​
Invoice issuer and taxes

Before live PayPal acceptance, every organization must save a legal invoice name and address. Those details are printed as the seller. The invoice also identifies OurPay as payment collector. The production path is wired to use Numeral as the sole tax calculation and transaction-recording provider. Seller-verification submission provisions each organization as a Numeral merchant, and OurPay sends every non-zero sale through Numeral’s platform API with the product’s explicit tax classification and the marketplace_provider role, including sales that resolve to zero tax. It does not declare merchant_of_record. The path remains inactive until the Taxes dashboard verifies a valid production account and an active seller profile. Checkout applies tax where Numeral says the platform must collect; completed sales, refunds, lost disputes, and reversals carry their event times so Numeral can include them in the correct filing period. The Taxes dashboard reports action required when any local record still needs provider reconciliation. Collected tax is excluded from Seller Payable. Once production is verified, Numeral supplies nexus and compliance state. It operates registrations, filing, and remittance for the platform account’s marketplace-facilitator obligations only where those workflows are separately enabled, authorized, and funded. Its live provider state — not an OurPay transaction aggregate — is authoritative for those workflows. Numeral identifies merchant-responsible sales separately; the organization remains responsible for liabilities that the platform does not assume. The contracts, invoice issuer, processor approvals, and configured Numeral role must agree. Organizations remain responsible for their own income and business taxes even when another party is legally responsible for transaction taxes.

​
Requirements before live central collection

At minimum, the deployment operator should have:
  1. A verified PayPal Business account and live REST application for the actual recipient of funds.
  2. Written PayPal approval for the intended seller/collector or MoR arrangement.
  3. Customer terms, seller agreements, invoice wording, refund policy, and statement descriptor that consistently describe the parties.
  4. A production Numeral account for the legally liable entity, with required registrations and filing approvals completed or in progress.
  5. Seller verification, sanctions, acceptable-use, fraud, refund, and dispute controls.
  6. A legally and operationally sound method for paying seller liabilities before promising payouts.
PayPal’s current Application Guidelines address the recipient of payments and payment aggregation. A technically successful live capture is not evidence that the commercial model has been approved.

​
Keeping the model consistent

Customer documents must identify OurPay as reseller and distinguish the supplier that fulfills the order. Processor permissions, tax registrations, and settlement records must support the same sale. Direct-to-supplier receipts need their own documented treatment and must not be counted again as funds held by OurPay. See Payment providers for implementation details and Account reviews for the current seller-verification flow.