LegalVersion 1.0Effective August 13, 2026

← All legal documents

Merchant-of-Record & Funds-Flow Policy

Effective Date: August 13, 2026
Version: 1.0
Operator: ARYX LLC (aryx.pro). The contracting party named on an Order Form controls for that transaction.

1. Purpose and Scope

1.1 Purpose

This Merchant-of-Record & Funds-Flow Policy (the "Policy") establishes the definitive, authoritative statement of the payments role occupied by ARYX LLC ("ARYX") when its software is used to initiate, schedule, or record payment activity. Its purpose is to draw a bright line: ARYX is not the merchant of record, is not a money transmitter, is not a payment facilitator or payment aggregator, and does not take custody of, hold, commingle, or direct the settlement of Customer or Member funds. ARYX provides software and workflow orchestration only.

This Policy exists because the allocation of payments liability — chargeback exposure, reserve obligations, KYC/underwriting duties, card-network and NACHA/ACH compliance, and money-transmission regulatory posture — turns entirely on who holds the merchant relationship and how funds flow. This Policy answers those questions once, canonically, so that every other ARYX document, contract, and disclosure can reference it rather than re-deriving it.

1.2 Scope

This Policy applies to all ARYX Services that touch payment activity, including without limitation:

  • EnrollFlow — the member enrollment system that initiates and schedules payment activity as part of plan enrollment;
  • ARYX Accounts (aryx.pro / app.aryx.pro) — the identity and billing hub that operates the subscription/billing engine and provisions tenants; and
  • ARYX CRM and supporting apps to the extent they surface, reference, or trigger payment workflows.

This Policy governs the relationship among ARYX, its Customers, and the third-party payment Processor. It does not alter the terms of any Customer agreement, Order Form, Data Processing Agreement, or Business Associate Agreement except to the extent expressly incorporated by reference therein.

1.3 Precedence and Cross-References

This is a core liability-allocation document. It is referenced by, and should be read together with, /legal/terms, /legal/billing, and Tenant administrator responsibilities under the MSA. Financial-state and settlement mechanics are elaborated in ARYX's refund and settlement standards (see also /legal/billing). Where a Customer-facing agreement and this Policy conflict on the payments role, the executed agreement controls as between the parties, but ARYX will not agree to terms that recharacterize ARYX as merchant of record, money transmitter, or custodian of funds.

2. Definitions

Capitalized terms have the meanings below; other capitalized terms not defined here have the meanings given in /legal/terms.

  • ARYX — ARYX, the provider of the Services.
  • Customer (or "Tenant") — the health plan, agency/brokerage, or benefit administrator that contracts for the Services and operates a tenant environment. The Customer is the entity that holds the Merchant Account.
  • Authorized User — a Member/enrollee or Customer staff member permitted to access the Services under the Customer's tenant.
  • Services — the ARYX software applications listed in Section 1.2 and related workflow orchestration.
  • Member Data — data relating to a Customer's members/enrollees, including PII and, in EnrollFlow, PHI.
  • PHI — Protected Health Information as defined under HIPAA, processed in EnrollFlow.
  • Processor — Authorize.Net, the third-party payment gateway/processor that authorizes and settles card transactions to the Customer's Merchant Account.
  • Acquirer (or "Acquiring Bank") — the financial institution that holds and underwrites the Customer's Merchant Account and settles card-network funds to the Customer.
  • Merchant Account — the Authorize.Net-connected merchant account and associated acquiring/bank relationship owned and controlled by the Customer.
  • Merchant of Record ("MoR") — the legal entity that appears on the cardholder's statement, holds the merchant agreement with the Acquirer/Processor, is financially liable to the card networks for transactions and chargebacks, and is the counterparty to the cardholder for the underlying purchase. Under this model, the Customer — not ARYX — is the Merchant of Record.
  • Subprocessor — a third party engaged by ARYX to process data in support of the Services (e.g., Supabase, Vercel, Resend, GoTo); the Processor is a Customer-facing payments provider, not an ARYX Subprocessor, as further described in Section 6.
  • CIM — Authorize.Net Customer Information Manager, used to store tokenized payment profiles.
  • Accept.js — Authorize.Net's in-browser tokenization library that returns opaque payment tokens (opaqueData).

3. Merchant of Record — Definition and Allocation

3.1 What "Merchant of Record" Means

The Merchant of Record is the party that (a) contracts with the Acquirer/Processor under a merchant agreement; (b) is identified to the cardholder and the card networks as the seller/merchant; (c) bears financial responsibility to the networks for authorized transactions, refunds, chargebacks, and associated fees and penalties; and (d) is responsible for underwriting, KYC, and ongoing merchant compliance obligations imposed by the networks, the Acquirer, and applicable law.

3.2 The Customer Is the Merchant of Record

For every payment initiated through the Services:

  • The Customer holds and controls the Authorize.Net Merchant Account and the associated Acquirer/bank relationship.
  • The Customer is the Merchant of Record. The Customer's name (or its designated merchant descriptor) appears on the cardholder's statement.
  • The Customer is the counterparty to its Members for the underlying plan, product, or service being purchased or paid for. ARYX is not a party to that transaction.

3.3 ARYX Is Not the Merchant of Record

ARYX does not hold a merchant agreement covering Customer transactions, does not appear as the merchant to cardholders or card networks, and does not assume network-level financial liability for Customer transactions. ARYX's software instructs the Processor to act on the Customer's Merchant Account under the Customer's authority; ARYX is not itself the merchant.

4. Funds-Flow Architecture

4.1 Funds Never Flow Through ARYX

Funds settle Processor → Customer Merchant Account/bank and never flow through ARYX. ARYX holds no bank account, settlement account, omnibus account, ledger, or wallet into or through which Customer or Member funds pass. ARYX neither receives, holds, commingles, nor disburses funds. There is no point in the architecture at which ARYX takes custody or control of money.

4.2 How a Charge Is Initiated (Technical Description)

  1. Card data is tokenized in the Member's browser via Accept.js, producing an opaque token (opaqueData). The primary account number (PAN) and CVV never reach ARYX servers, the ARYX database, or ARYX logs (PCI-DSS SAQ-A posture).
  2. ARYX stores only a tokenized payment profile via Authorize.Net CIM — a reference to a payment method held by the Processor, not the underlying card data.
  3. For recurring billing, ARYX operates a schedule-driven recurring charge engine (cron) that instructs the Processor, on the Customer's behalf and against the Customer's Merchant Account, to attempt a charge on a stored CIM profile. ARYX uses this schedule-driven model rather than gateway-native ARB (Automated Recurring Billing).
  4. The Processor authorizes and settles the transaction to the Customer's Merchant Account. Settlement funds move from the Processor/Acquirer to the Customer.
  5. ARYX records the transaction's state (see Section 4.4) for reconciliation and display; ARYX does not touch the funds themselves.

4.3 Multi-Tenant Isolation of Payment Records

Payment records, tokenized profiles, and transaction-state data are isolated per Customer in Postgres via Row-Level Security (RLS), org-scoped on Supabase. One Customer's payment data and configuration are not accessible to another Customer. This isolation is a data-security control; it does not change the funds-flow conclusion above.

4.4 Financial-State Integrity

ARYX represents transaction state precisely and never collapses distinct financial states. A charge progresses through Scheduled → Submitted → Authorized → Captured → Settled; a refund progresses through Refund Requested → Refund Authorized → Submitted to Processor → Processor Accepted → Network Processing → Issuer Processing → Posted/Settled. ARYX will never represent a charge or refund as "Completed" or "Settled" merely because an API call returned HTTP 200. Posting and settlement timing are controlled by the Processor, the card networks, and financial institutions and are outside ARYX's control. See ARYX's refund and settlement standards (see also /legal/billing) for the authoritative state model.

4.5 Webhook Verification

Inbound Authorize.Net webhooks used to update transaction state are (to be) verified via Processor-specified signature verification signature validation before any state change is recorded. This is an integrity control on the record of a transaction; it does not give ARYX any custody of or authority over funds.

5. Card-Network, NACHA/ACH, and Merchant-Compliance Responsibilities

5.1 Responsibilities That Sit With the Customer / Processor / Acquirer

The following responsibilities are not ARYX's and are allocated to the Customer, the Processor, and/or the Acquirer as applicable:

  • Card-network rules compliance (Visa, Mastercard, and other networks): the Customer, as Merchant of Record, is responsible for adherence to network operating rules, merchant category classification, and descriptor accuracy.
  • NACHA / ACH rules (to the extent ACH is used through the Customer's Merchant Account): origination authorization, NACHA Operating Rules compliance, and return handling sit with the Customer and its Processor/Acquirer/ODFI.
  • KYC / underwriting / merchant onboarding: the Processor and Acquirer are responsible for know-your-customer, underwriting, and merchant-account approval for the Customer. ARYX does not underwrite merchants and does not perform merchant KYC.
  • Chargebacks and disputes: chargeback liability is the Customer's as Merchant of Record; the dispute process runs between the cardholder, issuer, network, Acquirer, and Customer. ARYX may provide software to surface dispute information but bears no financial liability for chargebacks and does not represent the Customer in disputes. See ARYX's refund and settlement standards (see also /legal/billing).
  • Reserves: any reserve, holdback, or rolling-reserve requirement is a matter between the Customer, the Processor, and the Acquirer. ARYX imposes no reserve and holds no funds against which a reserve could be taken.
  • Refund funding: refunds are funded from the Customer's Merchant Account/settlement, not by ARYX.

5.2 ARYX's Responsibilities

ARYX is responsible only for: (a) providing software that correctly tokenizes (via Accept.js), stores tokens (via CIM), schedules and submits charge instructions, verifies webhooks, and records transaction state; (b) maintaining its SAQ-A PCI posture appropriate to a party that never receives PAN/CVV; and (c) the data-security and availability commitments described in Tenant administrator responsibilities under the MSA and applicable security documentation.

6. Regulatory Posture — Why ARYX Is Not a Money Transmitter

6.1 The Model

Money-transmission, payment-facilitator, and aggregator classifications generally attach to a party that receives, holds, or controls the transfer of another party's funds. Under the ARYX model, no such receipt, holding, or control occurs: funds move directly from the Processor/Acquirer to the Customer's Merchant Account, and ARYX is never in the flow of funds (Section 4). ARYX does not aggregate multiple merchants under a single ARYX-held master merchant account, does not sub-merchant its Customers, and does not net, hold, or disburse settlement.

6.2 Consequences of the Model

Because ARYX (a) is not the Merchant of Record, (b) does not take custody of funds, (c) does not aggregate merchants under a master account, and (d) provides only software and workflow orchestration, ARYX takes the position that it is not a bank, card network, payment processor, money transmitter, money services business, payment facilitator, or payment aggregator. ARYX is a software provider. The Processor (Authorize.Net) and the Acquirer perform the regulated payments functions; the Customer is the merchant.

6.3 No Legal Opinion; Reservation

This Section states ARYX's operational posture and design intent. It is not a legal opinion and does not bind any regulator. Final classification under federal money-transmission law, state money-transmitter licensing statutes, and card-network rules must be confirmed by qualified payments counsel . ARYX will not adopt any product change that would place it in the flow of funds without a corresponding legal and licensing review.

7. What Would Change This Posture

The conclusions in this Policy depend on the specific architecture described in Section 4. The posture would change — and would require prior legal, licensing, and compliance review before implementation — if ARYX were to do any of the following:

  • Take custody of funds: hold Customer or Member funds in an ARYX-controlled bank, omnibus, escrow, or wallet account at any point.
  • Aggregate merchants: operate as a payment facilitator/aggregator by boarding Customers as sub-merchants under an ARYX-held master merchant account.
  • Become Merchant of Record: contract directly with an Acquirer/Processor as the merchant for Customer transactions, appear on cardholder statements as the merchant, or assume network-level chargeback liability.
  • Direct settlement: net, split, hold, delay, or disburse settlement funds, or route settlement through an ARYX-controlled account (including "split payments" or marketplace-style payouts).
  • Issue stored value: issue or hold prepaid balances, credits redeemable for cash, or similar instruments.

Any of the above may trigger money-transmitter licensing, payment-facilitator registration, card-network sponsorship requirements, additional PCI scope (potentially beyond SAQ-A), state MSB obligations, and materially different liability allocation. None of these may be introduced without executive approval and payments-counsel sign-off, and this Policy must be revised accordingly.

8. Customer Acknowledgements

By using the Services to initiate payment activity, the Customer acknowledges and agrees that:

  1. The Customer is the Merchant of Record and holds and controls the Authorize.Net Merchant Account;
  2. Funds settle to the Customer and never flow through ARYX;
  3. Chargeback, reserve, refund-funding, KYC, underwriting, and card-network/NACHA responsibilities are the Customer's and/or the Processor's/Acquirer's, not ARYX's;
  4. ARYX provides software and workflow orchestration only and is not a party to the underlying transaction between the Customer and its Members; and
  5. The Customer is responsible for maintaining its Merchant Account in good standing and for its own regulatory, tax, and disclosure obligations as a merchant.

These acknowledgements are incorporated into and supplement /legal/billing.

9. Governance and Review

This Policy is owned by ARYX LLC and reviewed at least annually or upon any material change to the payments architecture, Processor relationship, or funds-flow model (whichever is sooner). Any change described in Section 7 requires immediate review outside the annual cycle. Governing law and venue for disputes arising under this Policy are as set forth in /legal/terms (the laws of the United States / the courts designated on the applicable Order Form).

Questions about this document? Contact legal@aryx.pro. Related: all legal documents · Privacy Policy · Terms of Service.