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
| Role | Description | Responsibilities |
|---|---|---|
merchant_of_record | The legal seller | Receives payment, appears on statements, handles disputes |
service_provider | Delivers the service | Provides the stay, meal, or experience |
facilitator | Platform infrastructure | Connects 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
| Value | Meaning |
|---|---|
venue | The hotel, restaurant, or experience provider |
agent | The AI agent or travel service booking on behalf of the guest |
platform | Infrastructure provider connecting agents and venues |
ota | Online 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
| Aspect | Venue Collects | Agent Collects |
|---|---|---|
| Statement shows | Venue name | Agent name |
| Refund authority | Venue | Agent |
| Chargeback liability | Venue | Agent |
| Guest relationship | Direct with venue | Through 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 Value | Description |
|---|---|
on_booking | Payout when booking confirmed |
before_checkin | Payout N days before arrival |
on_checkin | Payout on check-in date |
after_checkout | Payout after stay completes |
on_schedule | Fixed 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
}
}
| Field | Description |
|---|---|
initiators | Parties who can request a refund |
executor | Party who executes the refund (always MoR) |
requires_authorization | Whether initiator needs MoR approval |
4.2 Refund Scenarios
| Scenario | Initiator | Executor | Cost Allocation |
|---|---|---|---|
| Guest cancels (within policy) | Guest | MoR | Per cancellation tier |
| Guest cancels (outside policy) | Guest | MoR | Guest forfeits per policy |
| Venue cannot fulfil | Venue | MoR | Venue reimburses |
| Agent error | Agent | MoR | Agent absorbs |
| Force majeure | Any | MoR | Per 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
| Responsibility | Falls to |
|---|---|
| Cooling-off rights | MoR |
| Cancellation terms | MoR |
| Refund timelines | MoR |
| Service quality claims | MoR (may seek recourse from venue) |
| Chargeback defence | MoR |
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:
| Party | Role in Disputes |
|---|---|
| MoR | Receives dispute, provides response, defends chargeback |
| Service Provider | Provides evidence (booking records, check-in logs, service delivery proof) |
| Facilitator | May 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:
| Requirement | Description | Standard Support |
|---|---|---|
valid_from | Don't charge before date | Needed for balance payments |
valid_until | Don't charge after date | Supported |
max_amount | Maximum chargeable | Supported |
condition | Charge only if condition met | Needed 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.
Related Specifications
- Folio Spec — Payment schedules and policies
- AP2 Protocol — Mandate authorization
- ACP Protocol — Checkout and SPT
Settlement is an open specification under MIT license.