---
tags: lpms-server
---

Voucher States
===

## High-Level Graph

    flowchart LR 
    subgraph Direct Payment
    P(booking)
    O(funds transferred)
    end
    subgraph Escrow Contract
    A(funds are sent to escrow contract)
    1(check-in based transfer execution)
    2(cancellation policy based execution)
    X(Closed)
    
    a(check-in triggers transfer of funds)
    b(date of cancellation policy triggers transfer of funds)
    end
    subgraph Funds Verification
    Q(booking confirmed - verification)
    W(check-in completed - funds transferred)
    3(payment at property is possible)
    X(Closed)
    end

    subgraph No Funds Validation Upon Booking
    X(Closed)
    end 
    

## Legenda
Based on the chart above there are a 4 main flows for the `stays` voucher.

All voucher states can be encoded with the following conditions:
`refund` - 0 to 100%
`cancellation` - DD/MM/YYYY
`modification` - DD/MM/YYYY

Each should be set by the service provider at the `facility` level (default) and `space` level.

**Examples:**
1. `Facility` creates a rule they have a `refund` policy of 50% when `cancellation` 30-days prior to the booking start date.
2. `Facility` creates a rule that `modification` of `spaces` can be done up to 72h prior to the booking start date.

### Direct payment
To minimize fees and for bookings that are non-refundable, non-cancellable and non-changeable. This means that as soon as the traveller confirms the booking the funds are transferred to the service provider.

### Escrow contract
Upon booking the funds would leave the travellers wallet and are held in escrow. The funds get transferred based on two rules that can be set by the service provider.

C/I based; upon succesful check-in funds get transferred (QR code scanning, manual confirmation, API trigger with PMS)
C/P based; when the policy_date is reached the funds get transferred to the service provider (e.g. 72h cancellation period)

The reason to have two different rules is to enable a state for the use case of a booking that can be cancelled and partially refunded up until check-in for e.g.
Also this provides service providers to create more granular configuration for prices and policies.

questions/problems:
- how to deal when traveller changes their booking after the cancellation notice is reached and funds are transferred? would require refunds or extra payment...

### Funds verification
This requires the traveller to provide some form of verification that they have the funds available to make the payment at the property.

questions/problems:
- how would validation work without a crypto wallet? pre-charge on a VISA would require a PSP...

### No Verification
This means setting no verification or need to transfer funds into escrow to make a booking for a `facility` or `space`. Here are some examples of when this could be useful:
1. When a traveller is making a booking for +365 days from now, it would not require verification, but if no verification provided by required date then booking would get cancelled. Would require us to attach a date rule to it use it in combination with `notice_required`.
2. if the traveller is already at the property and decides to make another booking to extend the `stay` then the service provider could allow the traveller to make a booking via a UI running on Videre but settle on the local payment terminal.
3. If a service provider decides to allow returning travellers (that hold a `stay` token for that specific `facility`) to make bookings without verification.

questions/problems:
- how would protocol fees be paid out? who pays them in these scenarios?

## More Voucher States
- partial refund vs full-refunds? -> protocol fees
- cancellation by the `facility` (e.g. overbooking)?
- change of duration of stay during the `stay`?
- dispute process? Kleros?
- `entity` level rules?