Breaking change in Commerce 10.2
We at Episerver follow the sematic version rules strictly and we try really hard to avoid breaking changes in non-major releases. We have been doing that well, but there is exception to anything and we, unfortunately, introduced one breaking change in Commerce 10.2.
Previously, DefaultShippingCalculator.GetShippingCost will try to create an instance of IShippingGateway for the configured shipping gateway. In Commerce 10.2, it will try to create an instance of IShippingPlugin for that configured shipping gateway. If you are using the new abstraction APIs, this error might appear:
Unable to cast object of type 'YourWebsite.YourShippingGateway' to type 'Mediachase.Commerce.Orders.IShippingPlugin'.
This is an unintentional change and sadly, it slipped through our tests. The workaround is to change your implementation of IShippingGateway to IShippingPlugin (or implement both, if you are using workflows. If you don't call workflows explicitly, but you are using Commerce Manager to manage order, that still counts). Those two interfaces have very similar signature, the only difference is IShippingGateway.GetRate uses Shipment, while IShippingPlugin.GetRate uses IShipment.
We apologize for this issue - it's a hard lesson learned, and we are doing everything we can to reduce the impact of the issue, and avoid having the same problems in the future.
Thank you for your understanding, and if you have any questions or need further assistance, please feel free to contact our developer support service.
UPDATE: Commerce 10.2.2 which will be released later today (Jan 9th 2017) will fix the issues and you would not have to change your code to make the payment and shipping gateways work. However if you changed your code, you don't have to revert such changes.
We have bug COM-3626 to try to mitigate the effects of this breaking change by adding a fallback to use the old interfaces. It should go into the next release. Converting to use IShippingPlugin/IPaymenPlugin/ISplitPaymentPlugin over the corresponding *Gateway interfaces will still be the recommended way forward though.