Hi, I am looking into integrating buy now pay late...
# support
a
Hi, I am looking into integrating buy now pay later methods such as Klarna into Stripe. We are having issues with the refunds as the refund response from stripe comes back with a status of
pending
(I assume because they need to confirm with the external provider). At the moment we check for a status of succeeded before creating the refund in Solidus. What would be the best way to handle this? I think that we should listen to the
refund.updated
event from Stripe. But should we only create the refund in Solidus once we receive this? Or would it be better to add a column onto
Spree::Refund
for status, set it to pending when created and update when we hear from stripe that it has succeeded? My concern on only creating the refund once we receive this webhook is confusion for customer service because the refund isn't showing for the order in Solidus once requested.
j
We’ve actually done some work in an unreleased extension to add refund statuses for this exact reason (with a different gateway) and @Alistair Norman was considering porting those changes back to Solidus core.
a
Thanks, is there somewhere I can see the extension?
j
Sorry, it's unreleased currently, but hopefully when Alistair is on today he can provide some more info for you.
👍 1
a
In the past we've handled this by basically not saving the refund when it is initially created. We just send the request and then wait for a webhook where we create the refund for real. It's not an ideal solution because, like you said, the refund doesn't show up right away and you just have to check back to see if it shows up eventually. I've done the work to make this change for us internally but I haven't had a chance to port it to core yet. I'm not sure exactly but I'm hoping to have something ready in the coming weeks to make a pull request to Solidus. I'm happy to answer any questions if you're implementing and if you open an issue on Solidus I'll make sure to reference it when I push the PR so you get notified.
a
OK thanks for your help. I will create an issue for it on Solidus
Hi Alistair, are you able to advise how I can ensure that the refund creation is idempotent when listening to the
refund.updated
event? Can I save the refund ID onto the
Spree::Refund
somehow? I am a bit concerned about accidentally saving the refund twice if we receive an updated event for a refund which was already created
a
@Abby Hudson Sorry for the late reply. Yeah you would want to make sure you're checking the refund id when the webhook comes in.
I used transaction id to save the reference so it wouldn't get processed twice.