Skip to main content

Refund Policy

Cancellation and refund terms can differ by date, so the property-level default policy and the per-date policies are handled separately. Sending the wrong policy overcharges the guest's cancellation fee and leads to complaints.

Two kinds of policy​

KindHow it is provided
Property default policyExactly one entry in the property's refunds field
Per-date policyServed through the GET .../rateplans/{vendor_rateplan_id}/refund_policy lookup API, which the vendor implements

Rules​

  1. Send exactly one default policy in the property's refunds field.
  2. For the policy shown to the guest just before booking, return the per-date policy through the refund_policy lookup API.
  3. When a booking is actually created, return the per-date policy rather than the property-level one.
  4. Set the property default policy to the most conservative of the per-date policies.
  5. The property policy must never produce a larger cancellation fee for the guest than the per-date policy would.
danger

If the property default policy is worse for the guest than the per-date policy — that is, if it charges more — complaints will follow. Always align it with the most conservative per-date policy.

Refund policy on legacy channels​

info

Direct legacy channels (Booking.com, Agoda, Expedia, and so on) follow the cancellation terms configured on each channel, not the shared ONDA and property policy. The rules above apply to Plus channels.

Checklist​

  • Send one default policy in the property's refunds field
  • Serve per-date policies through the refund_policy lookup API
  • Return the per-date policy when a booking is created
  • Set the default policy to the most conservative per-date policy
  • Verify the default policy never charges the guest more than the per-date policy
  • Handle legacy channels according to the terms configured on each channel