What Is eligibleTransactionVolume Schema?

eligibleTransactionVolume is the Schema.org property for the monetary transaction range in which an Offer or PriceSpecification is valid. It can express a minimum purchase amount, a free-shipping threshold, or a transaction limit for a payment method.

The property expects a PriceSpecification value, not a bare number. That nested value supplies the monetary bounds and currency required to interpret the condition. A threshold of “75” is ambiguous without USD, CAD, or another currency and without knowing whether it is a minimum, maximum, or exact amount.

Use the property only when the page discloses a real transaction rule and checkout enforces it. Do not add a threshold because a campaign once used one, or infer it from average order value. The marked condition must apply to the same Offer or price component that owns it.

1. Frame the decision raised by What Is eligibleTransactionVolume Schema.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Model monetary transaction conditions.
• Include currency and correct bounds.
• Verify the threshold at checkout.

eligibleTransactionVolume is trustworthy only when its monetary range reproduces a real transaction rule.

Schema.org lists eligibleTransactionVolume on Offer, Demand, and PriceSpecification. Place it on the node whose validity depends on transaction value, such as an Offer minimum or a delivery or payment charge that changes at a threshold.

Placement controls scope. A $75 free-shipping threshold belongs to the delivery pricing rule, not automatically to the entire Product. A $20 minimum order may qualify the Offer itself. A card accepted only above $10 may belong to a payment-related condition. Use the PriceSpecification guide to preserve this ownership.

Multi-seller and multi-market pages often require distinct rules. One merchant’s minimum cannot be reused for another seller, and a USD threshold cannot silently qualify a CAD Offer. Connect the item and Offer clearly before adding a nested monetary range.

• Evidence for Where Can eligibleTransactionVolume Be Used: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Identify the rule whose validity depends on value.
2. Select its supported node.
3. Attach the monetary range to that node.

Place eligibleTransactionVolume on the exact Offer or price rule controlled by the transaction amount.

eligibleTransactionVolume describes a monetary range, while eligibleQuantity describes an interval and unit of ordered quantity. One answers “how much money,” and the other answers “how many or how much product.”

A wholesale Offer may require at least 10 units and a $500 order value. Those are two distinct conditions and can both matter. Do not convert quantity into money using a current unit price because discounts, fees, taxes, and product mixes can change the relationship.

eligibleQuantity expects QuantitativeValue, while eligibleTransactionVolume expects PriceSpecification. Preserve the correct nested type and unit. The next dedicated eligibleQuantity article will cover count, weight, volume, and other ordering units without duplicating this monetary intent.

1. Frame the decision raised by How Is It Different From eligibleQuantity.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Use money conditions for transaction volume.
• Use measured order intervals for quantity.
• Model both when checkout requires both.

Keep monetary thresholds and quantity limits separate so each condition remains accurate as prices and baskets change.

Represent minimum and maximum transaction values through the nested PriceSpecification’s supported bounds and currency. Use only the boundaries that exist; a minimum order does not require an invented maximum, and a transaction cap does not imply a minimum.

Define inclusivity. “At least $75” includes $75, while “over $75” does not. “Up to $500” may include $500, depending on the business rule. The page, cart messaging, checkout validation, and structured range must all resolve the same boundary behavior.

Clarify the calculation basis: pre-tax subtotal, post-discount subtotal, shipping-inclusive total, or another approved amount. A threshold displayed as “Free shipping over $75” can fail when coupons reduce the eligible subtotal. Structured data should not simplify a rule that customers experience differently.

• Evidence for How Do Minimum and Maximum Order Values Work: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Define the subtotal basis.
2. Record exact inclusive boundaries.
3. Test just below, at, and above each bound.

A transaction range is accurate only when its boundaries and calculation basis match checkout exactly.

Use eligibleTransactionVolume to qualify the delivery pricing rule that becomes valid at the stated order value. A free-shipping Offer must still preserve the delivery method, eligible region, exclusions, currency, and subtotal calculation used by the real policy.

Review the DeliveryChargeSpecification guide. A zero delivery charge above $75 and a $9.95 charge below $75 are separate outcomes. Do not publish one universal zero fee while ignoring the threshold or excluded products.

US shipping programs can vary for Alaska, Hawaii, territories, oversize products, expedited methods, members, and marketplace sellers. Model only regions and methods supported by the page and checkout. Test discounts because a coupon may move the basket below the eligible transaction volume.

1. Frame the decision raised by How Does It Model Free-Shipping Thresholds.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Attach the threshold to the delivery rule.
• Preserve method and geographic conditions.
• Test coupons and excluded products.

A free-shipping threshold is truthful only when qualifying baskets receive the advertised fee across the stated method and region.

Use eligibleTransactionVolume when a payment method or payment charge is valid only within a monetary range, such as a minimum transaction for card acceptance or a fee waived above a certain value.

Read the PaymentChargeSpecification guide. The transaction range should qualify the payment-related rule, not make every Offer method appear restricted. acceptedPaymentMethod and appliesToPaymentMethod remain separate facts from the value threshold.

Payment thresholds can vary by processor, country, currency, subscription stage, and customer type. Model the approved public rule rather than internal fraud or risk controls. Do not expose sensitive operational logic or claim a method is available when checkout can still reject the transaction.

• Evidence for How Does It Apply to Payment Methods: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Identify the public payment condition.
2. Attach it to the method or charge rule.
3. Test all visible payment paths.

Payment transaction ranges should reflect customer-visible method eligibility without exposing or inventing internal controls.

Create the applicable Offer or PriceSpecification, add eligibleTransactionVolume, then use a nested PriceSpecification with the verified monetary boundary and priceCurrency. Generate the condition from the same commerce rule that checkout enforces.

The source should retain rule ID, owning Offer or price component, minimum and maximum amounts, currency, inclusivity, subtotal basis, region, method, validity, and exclusions. Templates should omit absent bounds rather than converting null values to zero.

{
 "@context":"https://schema.org",
 "@type":"DeliveryChargeSpecification",
 "price":"0",
 "priceCurrency":"USD",
 "eligibleTransactionVolume":{
  "@type":"PriceSpecification",
  "minPrice":"75.00",
  "priceCurrency":"USD"
 }
}

• Evidence for How Do You Mark Up a Transaction Volume: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Resolve the owning rule.
2. Serialize its monetary boundaries.
3. Verify visible wording and checkout behavior.

Transaction-volume markup is complete only when source, page, checkout, and graph agree on the same range.

Common errors include using a bare number, omitting currency, confusing money with quantity, applying one seller’s threshold globally, mishandling inclusive boundaries, ignoring discounts or exclusions, and leaving stale values in cached markup.

A syntactically valid $75 minimum can still be wrong if checkout evaluates post-discount subtotal while the page implies pre-discount value. Multi-currency pages fail when a USD threshold remains beside a CAD Offer. Free-shipping markup often ignores oversize items or remote regions.

Test real baskets around boundaries, with coupons, taxes, shipping, mixed products, memberships, selected methods, currencies, and destinations. Compare the rule ID across source, page, JSON-LD, and checkout. Missing an optional threshold is safer than publishing one customers cannot satisfy.

1. Frame the decision raised by What eligibleTransactionVolume Mistakes Are Common.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Validate monetary semantics beyond syntax.
• Test boundaries with real baskets.
• Re-crawl after policy changes.

Prevent transaction-volume errors by proving every bound with representative carts and the same calculation used at checkout.