Recently introduced Checkout Order and Orders don't contain extensions fields and/or are not compatible with existing extensions.
Checkout order
- This is a POST only endpoint that allows you pay for existing orders, it already has an extensions key (by inheriting the
CheckoutSchema class) but the key is checkout-order instead of checkout. This means plugins relying on pushing data with checkout POST requests will not work as they're waiting at checkout key.
Orders
- This is a GET endpoint that will return an array of Cart-shaped pending orders. It doesn't include an extensions key, so it can't be extended, and existing plugins that extend Cart can't append data to it, meaning it will surface missing information (for things like Subscriptions and such).
Expected solutions
- Add an extensions key
Orders endpoint.
- Add backward compatibility to Checkout Orders endpoint so that it uses whatever is registered in
checkout, but only if nothing is registered in checkout-order. This will probably require some tweaking from our ExtendSchema class.
- Add the same backward compatibility for
Orders endpoint so that it uses whatever is in Cart.
Developers can opt out of this fallback method by registering an empty response to order or checkout-order.
Recently introduced Checkout Order and Orders don't contain extensions fields and/or are not compatible with existing extensions.
Checkout order
CheckoutSchemaclass) but the key ischeckout-orderinstead ofcheckout. This means plugins relying on pushing data with checkout POST requests will not work as they're waiting atcheckoutkey.Orders
Expected solutions
Ordersendpoint.checkout, but only if nothing is registered incheckout-order. This will probably require some tweaking from our ExtendSchema class.Ordersendpoint so that it uses whatever is inCart.Developers can opt out of this fallback method by registering an empty response to
orderorcheckout-order.