You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have refund in the BasePayment model but the refund logic differs from that one can see in the Stripe provider refund method.
I mean in the Payment.refund the payment actually changes its status to REFUNDED only in the full refunds case, but in the StripeProvider.refund it changes anyway (except StripeError).
Suppose the BasePayment is more reasonable but it call provider.refund method anyway.
So I confused and have two questions:
what logic is more appropriate for the general case?
where we should handle our refund business logic as we can't rely on change_status signal for partial refund? Suppose we should rewrite the method in our own Payment model inherited from BasePayment but I would prefer the consistent approach like we handle change_status signal for the general payment processing.
The text was updated successfully, but these errors were encountered:
We have refund in the BasePayment model but the refund logic differs from that one can see in the Stripe provider refund method.
I mean in the Payment.refund the payment actually changes its status to REFUNDED only in the full refunds case, but in the StripeProvider.refund it changes anyway (except StripeError).
Suppose the BasePayment is more reasonable but it call provider.refund method anyway.
So I confused and have two questions:
The text was updated successfully, but these errors were encountered: