Closed waiting-for-dev closed 1 year ago
We also need to ensure a refund is only performed once on Solidus, as the same webhook event could be received more than once. Because of that, we need to find a way to store the Acquirer Reference Number (ARN) assigned by Stripe to a given refund or, more generally, avoid any webhook being processed twice.
Using the ARN won't work, as it's not something generated at the webhook event creation:
We can't either use the Spree::Refund#transaction_id
, which should store the payment intent id, to uniquely identify a refund, as we can have more than one refund for a given payment (and payment intent).
As long as we don't implement a more creative solution, such as creating another model to store the association between a refund record and a webhook event id, we need to wait for #188 to avoid duplicated refunds.
Notice that there are two ways of generating Solidus refunds: directly or through an RMA (Return Merchandise Authorization). We'll only integrate refunds of the first kind, as there needs to be a more straightforward way to hook into the second system. That could be an optimization for the future. In any case, a refund generated through an RMA will also be created on Stripe through the gateway.
We'll get a
charge.refunded
webhook event whenever:We must update the Solidus counterpart for the first scenario by triggering the refund logic from the Solidus payment system. However, we need to be resilient because of the first scenario. We also need to ensure a refund is only performed once on Solidus, as the same webhook event could be received more than once. Because of that, we need to find a way to store the Acquirer Reference Number (ARN) assigned by Stripe to a given refund or, more generally, avoid any webhook being processed twice.
Partially replaces #160