Clarify Customer Requested Cancellation endpoint success definition

[nickevansuk]

If a call to the PATCH endpoint succeeds, the cancellation has succeeded and the user can be informed. However refunds must only be processed based on the resulting updates to the Orders feed.

• https://openactive.io/open-booking-api/EditorsDraft/1.0CR3/#customer-requested-cancellation

[nathansalter]

I think that we shouldn't specify rules surrounding refunds. Depending on the integration, the payment could be completely handled by the Seller which would make processing refunds for the Broker impossible. e.g. If you're using a Stripe implementation and send a PaymentIntent token in the payment, and it's handled by the Seller.

[nickevansuk]

Not sure I'm following, the above proposal makes the processing of Customer Requested Cancellation and Seller Requested Cancellation consistent... if there are issues with processing refunds feed rather than from the cancellation call, would this not be the same across both?

[nathansalter]

Completely agree, keeping these consistent is a good idea. However what I'm suggesting is to remove the references to refunds in the spec, as this is very much a domain problem for the seller/broker to discuss and set rules about. For example some of our Venues have a 24 hour no refund policy, others have proportional policies, and some don't do refunds but provide credit instead. I think trying to handle these cases where the seller and broker could have separate refund rules is out of the scope of this specification.

[nickevansuk]

Ah sure, so currently the spec only handles the full refund scenario via allowCustomerCancellationFullRefund. No partial refunds or credits.

The 24 hour no refund policy can be handled by latestCancellationBeforeStartDate.

Cancellation via allowCustomerCancellationFullRefund currently updates the totalPaymentDue for the Order.

Is the spec currently being used in production for proportional policies/credits? If so how does that work with totalPaymentDue and allowCustomerCancellationFullRefund?

[nathansalter]

Currently refunds are all handled outside of the spec, in the case of Bookteq/Playfinder/Schools Plus it's handled at either end rather than through Openactive itself.

[nickevansuk]

Sorry so specifically what's the value of totalPaymentDue of the Order following a cancellation with partial refund in these systems? Is it just set to the value that assumes a full refund?

[matdavies]

Sorry to chime in on this thread with what may be a slightly unrelated question, but doesn't the spec specifically state that it IS the broker who is always responsible for taking payments?:

https://openactive.io/open-booking-api/EditorsDraft/#high-level-api-flow

After "3. Book and Pay", the Broker first pre-authorizes the payment for the total order price (if required by the Payment Provider), then confirms the booking with the Booking System using an Order (B on the diagram above), and finally captures the payment. The Broker then generates invoices, and sends the Customer notifications.

Or am I misreading it and in fact it might be possible for the seller to capture the payment (though that would be reliant upon specific payment gateway functionality)

[nickevansuk]

Yep that's right @matdavies, payments are explicitly not included in the spec scope, so it's always the Broker.

(note there is an extension example in the spec for integrated payments, but this is not part of the spec itself)

[matdavies]

Thanks Nick. To confirm though, via negotiations between seller and broker, it may be feasible/permissible for the seller to handle the actual capture of money (and therefore the refunding of money too) via the extension you linked to above?

[nickevansuk]

Ah sorry, the extension isn't intended for use by the Booking System. If Booking Systems required integrated payment gateways that would limit the potential use cases significantly, hence Payment being outside of scope. The extension example is more to show that the Open Booking API can have broader utility than just as a Booking System API - e.g. elements of it could be implemented by the Broker internally between the frontend and backend of a Broker implementation.

[nathansalter]

Sorry so specifically what's the value of totalPaymentDue

We don't actually show totalPaymentDue in the Orders RPDE feeds. It's only used during the booking process for validation.