Settlement

v0.1.0 Draft

Commercial roles and payment flows in multi-party bookings.

Namespace URI: https://agenticbooking.org/folio/settlement/v1


1. Overview

When a guest books through an agent, multiple parties are involved:

Guest → Agent → Venue
         ↓
      Platform

Each party has a commercial role that determines who receives payment, who provides service, and who handles disputes.

This specification defines the vocabulary for declaring commercial roles. It does not mandate any particular payment provider or implementation.


2. Commercial Roles

2.1 Role Types

RoleDescriptionResponsibilities
merchant_of_recordThe legal sellerReceives payment, appears on statements, handles disputes
service_providerDelivers the serviceProvides the stay, meal, or experience
facilitatorPlatform infrastructureConnects parties, provides tooling, may collect platform fee, no customer liability

2.2 Role Declaration

{
  "settlement": {
    "merchant_of_record": {
      "party": "agent",
      "id": "did:web:travel.example.com"
    },
    "service_provider": {
      "party": "venue",
      "id": "did:web:theroste.co.uk"
    },
    "facilitator": {
      "party": "platform",
      "id": "did:web:platform.example.com"
    }
  }
}

2.3 Party Values

ValueMeaning
venueThe hotel, restaurant, or experience provider
agentThe AI agent or travel service booking on behalf of the guest
platformInfrastructure provider connecting agents and venues
otaOnline travel agency acting as intermediary

3. Settlement Models

How funds flow depends on who is Merchant of Record:

3.1 Venue Collects

Traditional model—venue receives payment directly.

Guest → Venue (MoR)
          ↓ commission
        Agent
{
  "settlement": {
    "model": "venue_collects",
    "merchant_of_record": { "party": "venue" }
  }
}

3.2 Agent Collects

Agent receives payment, remits to venue.

Guest → Agent (MoR)
          ↓ payout
        Venue
{
  "settlement": {
    "model": "agent_collects",
    "merchant_of_record": { "party": "agent" }
  }
}

3.3 Model Comparison

AspectVenue CollectsAgent Collects
Statement showsVenue nameAgent name
Refund authorityVenueAgent
Chargeback liabilityVenueAgent
Guest relationshipDirect with venueThrough agent

3.4 Payout Schedule

When funds flow from MoR to service provider, the payout timing can be specified:

{
  "settlement": {
    "model": "agent_collects",
    "merchant_of_record": { "party": "agent" },
    "payout_schedule": {
      "service_provider": "venue",
      "timing": "after_checkout",
      "delay_days": 2
    }
  }
}
Timing ValueDescription
on_bookingPayout when booking confirmed
before_checkinPayout N days before arrival
on_checkinPayout on check-in date
after_checkoutPayout after stay completes
on_scheduleFixed schedule (daily, weekly)

4. Refund Authority

Who can initiate and execute refunds depends on MoR designation.

4.1 Authority Chain

{
  "refund_authority": {
    "initiators": ["guest", "agent", "venue"],
    "executor": "merchant_of_record",
    "requires_authorization": true
  }
}
FieldDescription
initiatorsParties who can request a refund
executorParty who executes the refund (always MoR)
requires_authorizationWhether initiator needs MoR approval

4.2 Refund Scenarios

ScenarioInitiatorExecutorCost Allocation
Guest cancels (within policy)GuestMoRPer cancellation tier
Guest cancels (outside policy)GuestMoRGuest forfeits per policy
Venue cannot fulfilVenueMoRVenue reimburses
Agent errorAgentMoRAgent absorbs
Force majeureAnyMoRPer terms or negotiated

4.3 Cost Allocation

{
  "refund_cost_allocation": {
    "guest_cancellation": "per_policy",
    "venue_failure": "venue_reimburses",
    "agent_error": "agent_absorbs",
    "force_majeure": "negotiated"
  }
}

5. Liability Chain

Consumer protection responsibilities follow the MoR.

5.1 Consumer Responsibilities

ResponsibilityFalls to
Cooling-off rightsMoR
Cancellation termsMoR
Refund timelinesMoR
Service quality claimsMoR (may seek recourse from venue)
Chargeback defenceMoR

5.2 Declaration

{
  "liability": {
    "consumer_contract": "merchant_of_record",
    "service_delivery": "service_provider",
    "dispute_first_contact": "merchant_of_record"
  }
}

5.3 Dispute Handling

The MoR is responsible for dispute resolution, but facilitators may provide supporting infrastructure:

PartyRole in Disputes
MoRReceives dispute, provides response, defends chargeback
Service ProviderProvides evidence (booking records, check-in logs, service delivery proof)
FacilitatorMay provide tooling, evidence aggregation, and process support
{
  "dispute_support": {
    "evidence_sources": ["venue_pms", "booking_system", "communication_logs"],
    "facilitator_tooling": true
  }
}

The facilitator's role is to assist—not to assume liability or act as the customer's counterparty.


6. Multi-Party Bookings

Itineraries spanning multiple venues:

{
  "settlement": {
    "model": "agent_collects",
    "merchant_of_record": { "party": "agent" },
    "service_providers": [
      { "party": "venue", "id": "did:web:hotel.example.com", "portion": 60 },
      { "party": "venue", "id": "did:web:restaurant.example.com", "portion": 25 },
      { "party": "venue", "id": "did:web:tour.example.com", "portion": 15 }
    ]
  }
}

The MoR receives full payment and distributes to service providers per agreed terms.


7. Payment Token Requirements

When using payment tokens (SPT, AP2 mandates), hospitality requires:

RequirementDescriptionStandard Support
valid_fromDon't charge before dateNeeded for balance payments
valid_untilDon't charge after dateSupported
max_amountMaximum chargeableSupported
conditionCharge only if condition metNeeded for no-show

Current SPT implementations support expires_at but not valid_from. This gap is being addressed in hospitality protocol extensions.

See ACP Protocol for details.


8. Implementation Notes

What This Spec Defines

  • Vocabulary for commercial roles
  • Declaration format for settlement models
  • Refund authority semantics
  • Liability allocation patterns

What This Spec Does Not Define

  • Payment provider APIs
  • Fee structures or percentages
  • Account onboarding flows
  • Transaction reconciliation

These are implementation concerns left to platforms and payment providers.



Settlement is an open specification under MIT license.