Merchant and cardholder
While acquirers, issuers, and card networks represent institutional infrastructure, merchants and cardholders are the commercial participants at either end of a transaction. Within card scheme rules, the rights and protections granted to each party are fundamentally asymmetric: consumer protections are protected by federal statutes and card scheme rules, whereas the merchant's operational position is governed by its private merchant service contract.
The merchant agreement and identification
To accept card payments, a business executes a merchant agreement with an acquiring bank or payment facilitator. This contractual document establishes the financial and operational framework of the processing relationship: defining interchange-plus or flat-rate fee schedules, daily funding settlement timetables, chargeback administration fees, and reserve account requirements.
Upon executing the agreement, the provider assigns the business a unique merchant ID (MID). The MID is attached to every authorization request, clearing record, and settlement file submitted by the merchant. Organizations that operate multiple brands, manage independent e-commerce channels, or maintain physical retail locations alongside digital storefronts typically maintain separate MIDs for each operational stream to isolate accounting, funding, and dispute metrics.
Merchant category codes
During merchant underwriting, the acquiring bank assigns the business a four-digit merchant category code (MCC). The MCC classifies the primary nature of the business—such as lodging (7011), digital software (5734), or restaurants (5812).
The assigned MCC influences several critical operational parameters:
- Interchange qualification: Card network interchange schedules establish specialized rates tied directly to specific MCCs. An incorrectly assigned MCC can cause transactions to clear at suboptimal interchange tiers, inflating processing costs across all volume.
- Authorization and clearing rules: Specific industries—such as car rental agencies and hotels—are permitted by scheme rules to execute estimated authorizations and capture delayed incidentals. Standard retail and software MCCs do not possess these privileges.
- Risk classification and underwriting: Certain category codes (such as gaming, travel, or cryptocurrency) are classified as high-risk, requiring elevated financial reserves, specialized underwriting scrutiny, or mandatory registration fees.
- Consumer credit card rewards: Issuing banks evaluate MCCs to determine category-specific cardholder reward points, cash-back multipliers, and corporate card spending restrictions.
Merchants must verify their assigned MCC during onboarding and notify their acquirer if their core product lines change. Intentionally misrepresenting a business model to acquire a cheaper interchange tier violates scheme rules and risks immediate termination of processing privileges.
The cardholder experience: statement descriptors and state transitions
Cardholders never interact directly with the technical message flows of payment processing. Instead, they observe transaction activity through their digital banking applications and monthly statements.
Cardholder statement lines reflect two distinct operational phases:
- An entry marked as pending represents an active authorization hold. The issuer has reserved the funds, reducing available credit, but clearing has not yet completed and no funds have transferred. If an authorization hold expires without being captured, the pending entry disappears from the statement without generating a separate credit line.
- Once the merchant captures the transaction and the day's batch clears through the network, the charge transitions to posted.
The text displayed on the cardholder's statement is the billing descriptor. A confusing or uninformative descriptor is a leading trigger of "friendly fraud" disputes. For example, if a parent company's obscure corporate holding name appears on a statement rather than the customer-facing brand name, the cardholder may conclude their card was compromised and file an unauthorized transaction dispute.
To mitigate this risk, merchants configure recognizable billing descriptors incorporating their trading name, customer service phone number, or support URL. In multi-tenant marketplaces or aggregator platforms, providers support a soft descriptor—a dynamic string passed during authorization that appends the specific sub-seller's trading name to the platform's primary billing descriptor.
Configure statement descriptors to align with the trading name recognized by consumers.
- Display the merchant's consumer-facing trading brand rather than an internal corporate holding entity.
- Include a direct customer service telephone number or concise support URL where character limits permit.
- In multi-vendor marketplace platforms, dynamically pass soft descriptors identifying the specific seller.
- Verify statement appearance by conducting live test purchases across major issuing bank interfaces before launch.
Consumer dispute rights
The central statutory protection enjoyed by cardholders is the right to initiate a formal dispute through their issuing bank for months following a transaction. Consumers are not legally required to contact the merchant before disputing a charge, and many approach their bank directly. Providing transparent cancellation flows and frictionless refund paths offers an effective commercial defense against chargebacks, as prompt merchant refunds deliver funds to customers far faster than multi-week dispute arbitrations.
Cardholders also carry contractual obligations to their issuing banks: safeguarding physical cards, reporting compromised credentials promptly, and avoiding illegitimate chargebacks. When a consumer initiates a dispute against an authentic purchase they legitimately authorized, the event constitutes first-party misuse—one of the most pervasive sources of dispute volume in digital commerce.
Terms introduced
- Merchant agreement: the contract between a merchant and its acquirer or provider that sets fees, funding, reserves, and dispute terms.
- Merchant ID: the identifier a provider assigns to one merchant contract, carried on every transaction. Often shortened to MID.
- Merchant category code: the four-digit code an acquirer assigns to describe what a merchant sells, which drives interchange, authorization rules, and risk treatment. Often shortened to MCC.
- Billing descriptor: the text that appears on the cardholder's statement for a transaction.
- Soft descriptor: a per-transaction descriptor, used to name a seller on a platform.
- Pending and posted: the two states of a charge on a cardholder's statement. Pending is an authorization hold; posted means the transaction cleared.
How providers do it
When running a multi-sided marketplace, booking engine, or vertical SaaS platform, merchant identity, statement descriptors, and compliance underwriting operate on a per-seller basis rather than at the platform corporate level.
How a provider handles merchant identification directly affects cardholder statement clarity, dispute rates, and tax reporting. The table below outlines how leading platform-focused payment providers structure merchant identity and statement descriptor customization.
| Provider | Contractual seller of record | Statement descriptor control | Status |
|---|---|---|---|
| Stripe Connect | The connected account on Direct Charges; the platform entity on Destination and Separate Charges | Configured dynamically via statement_descriptor or inherited from the seller profile when on_behalf_of is passed | confirmed |
| Payrix | Either the underlying sub-merchant or the payment facilitator entity | Configurable per sub-merchant profile or dynamically via transaction API | unconfirmed |
| Square | The underlying seller operating as a sub-merchant under Square's master merchant facility | Assigned per merchant account and physical business location | unconfirmed |
Merchant Category Codes (MCCs) are also assigned individually during seller underwriting. A misclassified MCC can inflate interchange fees on every transaction that seller processes or trigger unexpected authorization declines from issuing banks that block specific merchant categories. Because platform fees are often bundled into blended pricing, an incorrect MCC classification can quietly erode margins for months before anyone notices.
- Stripe Connect
- Payrix
- Square
What they are: the thing that decides whose name the customer sees and whose contract the sale sits under.
On a direct charge the connected account is the merchant. On a destination charge or a separate
transfer the platform is, unless on_behalf_of names the seller. That one field moves the
business of record, and with it the statement descriptor, the settlement country, and the fee
structure applied.
| Standard term | Their term | Status |
|---|---|---|
| Soft descriptor naming the seller | The connected account's statement descriptor, used when on_behalf_of is set | confirmed |
| Merchant ID | The connected account id, acct_… | confirmed |
| Question | Answer | Status |
|---|---|---|
| Whose address and phone appear on the statement? | The connected account's, where on_behalf_of is set and that account is in a different country from the platform | confirmed |
| Which country does the sale settle in? | The connected account's, on direct charges and wherever on_behalf_of is set | confirmed |
| Who assigns the seller's MCC? | unconfirmed; it is set during onboarding, and a wrong one prices every one of that seller's transactions wrongly | |
| Are descriptors checked before a seller goes live? | unconfirmed |
The descriptor rule on this page applies per seller here, not once for the business. A platform with four thousand sellers has four thousand descriptors, and any one of them can read as unrecognisable to a cardholder and produce a fraud dispute the platform then has to defend.
Last verified: 2026-09-09 against Stripe's public Connect documentation.
What they are: the onboarding path for sub-merchants, and the party that decides whether a seller is allowed to trade at all.
| Question | Answer | Status |
|---|---|---|
| Who signs the merchant agreement, and with whom? | unconfirmed; the seller may be contracting with Worldpay, with the platform, or with both | |
| Who assigns the sub-merchant's MCC? | unconfirmed | |
| What happens to a seller the platform wants and they decline? | unconfirmed; in a PayFac-as-a-service model the risk decision is not the platform's to overrule | |
| Can the seller's descriptor be set per sale? | unconfirmed | |
| What underwriting data must be collected at signup? | unconfirmed |
The first row is the one to answer before a sales conversation. If the seller's agreement is with Worldpay, the terms quoted to that seller are not the platform's to change, and finding that out mid-negotiation is expensive.
Last verified: never.
What they are: a facilitator, so a seller on Square is a sub-merchant under Square's master account rather than a merchant with its own agreement.
| Standard term | Their term | Status |
|---|---|---|
| Merchant | Seller | confirmed |
| Site, store, or till location | Location, location_id | confirmed |
| Question | Answer | Status |
|---|---|---|
| What appears on the cardholder's statement? | unconfirmed; check a real statement, because a descriptor the customer does not recognise is the commonest cause of a fraud dispute | |
| Who assigns the seller's MCC? | Square, at onboarding | unconfirmed |
| Can a seller change its own descriptor? | unconfirmed |
Because the location carries the descriptor and the reporting, a business with several sites that puts them all on one location loses the ability to tell which site took a disputed sale. That is worth getting right at setup rather than after the first chargeback.
Last verified: never.