Clarification on seat selection "fee"

[ManuelQuemerais]

We'd be interested into some clarifications on OSDM stance for seat selection "fee".
Below § in https://osdm.io/spec/processes/

looks to hint at "fee" model to be used whenever it comes to price associated to seat selection (being using a seatmap or not).

But ... most fare managers actually model their optional seat selection as an optional service (subscribing or buying the option, the service, ...) with a price, not a fee.
That's the case when you look a DB ToS, at Ouigo ToS, ... which is not super suprising, from a commercial regulation standpoint fees you don't buy fees, you buy services.

here's a Gemini summary on fee/service distinction from a regulatory standpoint (french context ... but EU regulation is fairly consistent across countries a we know) :

1. What is a "Fee" in consumer law?
   A fee generally corresponds to the passing on of an administrative, technical, or management cost inherent to providing the main service.
   The accessory nature: The fee brings no autonomous added value to the customer. It is simply the processing cost (e.g., booking fees, management fees, credit card processing fees).
   The mandatory nature and price display: If a fee is unavoidable for the contract to be executed, the law (Article L. 112-1 of the French Consumer Code) requires that it be included in the base price displayed to the consumer from the start of the process. A professional cannot attract a customer with a low baseline price, and then add "mandatory fees" at the end of the checkout process (an illegal practice called drip pricing).
2. What is an "Optional service"?
   An optional service is a distinct provision, severable from the main obligation of the contract (the main obligation being, for example, transporting you to a destination or granting you access to a venue).
   The added value: The optional service provides an advantage of comfort, enjoyment, or flexibility that is not strictly necessary for the fulfillment of the basic contract (e.g., cancellation insurance, extra luggage, onboard meal).
   Active consent (Opt-in): This is the major legal difference. Article L. 221-22 of the French Consumer Code requires the express consent of the consumer for any additional payment added to the main obligation. The addition of this service can only be done through a positive action on your part. The use of pre-checked boxes by default is strictly prohibited.

So, we'd need to understand if

• there's a general OSDM requirement to model all optional paying seat selection as fees (bookedOffer/fees)
• or if this is a more limited requirement, that
  • would only apply in the limited cases (I don't know any to be fair ...) in which a given fare manager actually model their seat selection feat as a fee (which I guess would be fairly strange from a legal standpoint).
  • other cases (optional services) being likely modeled in OSDM as optional ancillary offer/bookingParts associated to the "base" reservation offer/bookingParts

It seems to me that if the later is true (i.e. most seat selection should actually be modeled as ancillary services), we may need some rework in POST /availabilities/vehicle-place-map, which to date only seems to use "fee" concept (c.f. "selectionFee")

Thanks for your help ^^

[CGantert345]

The seat selection fee is a fee for selecting a specific seat from a graphical seat map. It is optional, as you are not forced to select a seat, you can use the seat selected by the provider for you. The fee depends on the seat selected. This seems to be implemented at Samtrafiken only.

The reservation fee usually used for optional reservation is also modelled as fee and the reservanion(s) are linked to the fee object (There can be multiple reservations included in the same fee).

In case of a mandatory reservation and following teh consumer law description abouve the "fee" should then be added eigther as the price of the reservation offer part or the admission offer part, but not as a fee.

[ManuelQuemerais]

Hi Clemens, thanks for the feedback.

I'm mostly interested in the seat selection "fee", and understanding if aforementioned https://osdm.io/spec/processes/ should be understood as a mandatory requirement (i.e. seat selection price should be implemented as an OSDM fee) or if it is more of a recommandation, allowing an implementer to model this fee as a service (and therefore a an optional ancillary offerPart/bookingPart).

I get that we're used to "fee" wording for this feature, but from a contractual perspective, these fees are actually optional services, and there would be benefits into handling them as any optional services (from a pricing, selection, buying standpoint).

• c.f.
  Ouigo : "The SEAT CHOICE option is included in your OUIGO PLUS and OUIGO FULL offers. Are you traveling with the OUIGO ESSENTIEL offer? You will need to subscribe to the SEAT CHOICE option to benefit from it. [...] This option will be billed to you at €3 (Free with the OUIGO PLUS and OUIGO FULL offer)."
  Trenitalia : The seat selection option. On Frecciarossa, Frecciargento and Frecciabianca trains, in all classes and service levels, you can choose your seat by paying €3 for each selected seat
  Avlo : The Basic Fare does not allow you to choose your seat; however, you can add this service as an extra for just €8 (per journey) when purchasing your ticket. This way, you can guarantee your comfort by choosing where you travel. Graphic seat selection. Not available within the initial attributes of the Basic Ticket. Available by purchasing the 'Graphic seat selection' Add-on

[CGantert345]

maybe we need a type in fee to separate handling fees from service fees.

[ManuelQuemerais]

to be fair, I'd rather go OSDM 4.0 way, with fees being modeled as offerParts/bookingParts, but given that we can't make that move in OSM 3.x, small adaptations may help with current design.
As far as it comes to me, I'd tend to use actual OSDM 3.x fees mostly for handling fees (booking, delivery, ....) and model service fees as optional ancillary offerParts/bookingParts, but to do so I need to understand if it's compatible with OSDM functional requirements.