Hi Clover Community, I'd like to validate something; We currently implement orders for our e-commerce integration refunds following the same logic Clover uses internally. I'm finding mixed answers about this. (See: https://community.clover.com/questions/13836/can-we-use-clover-orders-api-and-inventory-api-in.html and https://community.clover.com/questions/26939/using-order-api-in-payments-plus-bundle.html)
Clover Asks us to not "Expose" Orders and Items to Payment Plus merchants, somewhere else it uses "Depend". I was under the impression that "exposing the functionality" meant giving them some degree of control over it, viewing orders, etc.
In a specific scenario where;
- A merchant has Register Lite at the time of an order creation
- This merchant doesn't use the Clover inventory at all and just wants to process payments since the Ecommerce Platform provides those features already, minus payment processing.
- Since the merchant has Register Lite, he benefits from having an Order and seeing the items from the Clover Dashboard, even if we actually pass in custom items to the order and not existing Clover items UUIDs.
- We are in the context of an integration with an Ecommerce Platform that already supports all the features independently of Clover. ( Orders, items, partial or full refunds on any charge in the order, items or other fees ) and in this context, we are not synchronizing anything, merely using the UUID of an order / of custom items ( Much like the order with one item that would be created behind the scene ) as a reference to limit the logic to what it should do when it tries to refund.
If the merchant downgrades to Payment Plus, how should a refund be handled if we shouldn't use the orders API? Should we not use the Orders API ( Even if we limit its use so it is the very same way it would be used behind the scenes -- That is, only to be used as a reference for order integrity across multiple partial refunds? )
