What Is FulfillmentType in Shipping Schema?

FulfillmentType identifies how a ShippingService gets a purchased product to the customer, such as delivery to an address or shipment to a collection point for pickup.

The property belongs on ShippingService and uses a FulfillmentTypeEnumeration value. It describes the service mode, not inventory availability, return method, or the customer's selected address. Rate, destination, handling, and transit still require their own shipping properties.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Choose the real customer handoff mode.
• Use the supported enumeration URL.
• Keep each service's conditions separate.

Use the free backlink checker while reviewing linked commerce pages.

Primary specification: Schema.org definition for fulfillmentType.

FulfillmentType is accurate when it names the actual delivery or collection journey represented by the ShippingService.

FulfillmentType belongs directly on ShippingService, which can be connected to Organization through hasShippingService and can contain multiple ShippingConditions.

It should not be placed on Product as an identity field or inside shippingRate as a cost. If one merchant supports both home delivery and collection-point pickup, model them as separate services so each keeps its own name, handling, conditions, rates, destinations, and timing.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Map the merchant Organization.
2. List each customer handoff method.
3. Create one ShippingService per distinct mode.
4. Attach matching conditions.
5. Validate the complete graph.

Review Merchant Shipping Policy schema for the organization-level model.

Correct placement keeps fulfillment mode at service level and commercial rules inside that service's conditions.

FulfillmentTypeDelivery describes a service that ships the product to the customer's address under the destinations, rates, handling, and transit rules in that ShippingService.

Delivery may include economy, standard, expedited, freight, or regional services. If those options have meaningfully different policies, use separate named ShippingService entities rather than one generic delivery value with conflicting conditions. The destination must identify where the address can be served.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Keep each rate paired with its speed.
• Use DefinedRegion for coverage.
• Model handling and transit separately.
• Do not promise delivery where checkout rejects the address.

Delivery fulfillment describes physical handoff to an address, not whether the item is currently in stock.

A delivery service is truthful when its geographic, cost, and timing rules reproduce the address-based option at checkout.

Collection-point fulfillment describes shipment to a locker, partner store, or other designated point where the customer retrieves the order.

This differs from home delivery because destination eligibility is tied to a pickup network, not simply a postal address. It also differs from immediate in-store pickup when no shipping journey occurs. The service should explain location selection, readiness timing, holding period, identification requirements, and any fee in visible policy content.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Determine whether goods are shipped to the point.
2. Map eligible collection locations.
3. Define rate and transit to the point.
4. State customer collection requirements.
5. Test location availability.

Do not force every pickup experience into a shipping policy when the operational model is store inventory rather than shipment.

Collection-point markup is accurate when it represents a real shipped-to-location service and its complete pickup journey.

Collection-point shipping moves the product through a shipping service to a pickup location, while store pickup may reserve inventory already held at the selected store.

The customer action looks similar, but the logistics evidence differs. Ship-to-store has handling and transit before readiness. Local pickup can have reservation and preparation without carrier transit. Combining them can show a delivery window where only readiness time exists or publish a shipping rate for a free local reservation.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Identify the source inventory.
• Check whether a carrier handoff occurs.
• Separate delivery ETA from pickup readiness.
• Do not reuse home-delivery conditions.

The structured model should follow the actual flow of goods rather than the shared word “pickup.”

Store pickup may use inventory already held at the selected location, so no ShippingService journey occurs. Collection-point fulfillment instead begins with an eligible item leaving a warehouse or seller and ends when the designated point receives it for customer collection. Audit the inventory source, transfer event, readiness notification, holding period, cancellation rule, and location capacity. If a merchant supports both flows, keep separate service identifiers and customer messages so a same-day store reservation cannot inherit a multi-day collection-point transit estimate.

Store pickup and collection-point shipping require separate modeling whenever their inventory, timing, or transport differs.

Each fulfillment type needs conditions that keep its own rate, destination, handling, transit, cutoff, and service calendar together.

A free locker service can be slower than paid home delivery. Mixing the locker rate with the home-delivery speed creates an option customers cannot select. Handling may be shared at the warehouse, while transit and destination networks differ. Separate services make these relationships auditable.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. List every selectable service.
2. Attach the correct fulfillmentType.
3. Define its ShippingConditions.
4. Model handling and transit.
5. Compare each option with checkout.

Use ServicePeriod for policy-level timing.

Fulfillment options remain truthful when each cost and time belongs to the same customer-selectable method.

FulfillmentType should describe the service mode, while inventory and location systems determine whether that mode is available for the exact product and selected destination.

A merchant can offer collection points generally but exclude oversized, regulated, perishable, or vendor-shipped products. A locker may also have size limits or temporary capacity. Publishing a service does not prove every Offer qualifies. Product exceptions need narrower Offer-level shipping details or honest omission.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Check product eligibility before publishing the option.
• Keep location coverage current.
• Separate service capability from inventory availability.
• Verify unusual products and remote regions.

A general Organization policy should not overrule a known product-specific restriction.

Fulfillment markup is complete only when service mode and product-location eligibility agree.

Common mistakes include using free text, treating store pickup as shipped collection, combining delivery and pickup conditions, publishing unavailable methods, and attaching the wrong rate or timing.

Another defect is assuming omission always communicates the desired mode. Although delivery can be treated as the default in a shipping policy context, an explicit supported value is clearer when multiple services exist. Syntax validation cannot confirm that checkout offers the named fulfillment path.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Extract each ShippingService and fulfillmentType.
2. Trace the mode to operations.
3. Separate distinct customer journeys.
4. Repair conditions and eligibility.
5. Verify real selectable options.

A source-level correction prevents the same false service from appearing across the catalog.

Fulfillment errors require reconciliation with the physical delivery journey and checkout selection, not only valid enumeration syntax.