#battbot_webhooks
1 messages · Page 1 of 1 (latest)
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- battbot_api, 3 days ago, 37 messages
đź‘‹ Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đź”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1228420994071527505
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
hi
Double checking right now, but I don't think there's a webhook event for this if the customer presents the wrong card. You'll just just see the above error message you mentioned: The card presented during refund is not the same card used for the original purchase.
you are saying they should see this message on the Terminal?
i don't think that's visible on the Terminal
Our customer reflected to us that they just got a generic Payment Failed message on the Reader. And they had no idea why it failed, so they repeated try to tap the card and retrying the refund
req_9SgNXwZJ6mGKcE
where would the end user even know then?
if it doesn't display on the reader and we are not told of the failure
Actually it may be in terminal.reader.action_failed event
The reader is the one that creates the Refund object, so iwe don't even know about the refund id to inquire Stripe about anything. And the PaymentIntent itself has no information about this
can you see if there are more recent such events then?
There's a ton of those events
Like it's sent for every decline, etc
Do you happen to have a more recent example of this?
If not, I can ask a colleague to confirm that you'll get terminal.reader.action_failed event for this scenario
we get alot of terminal.read.action_failed for the intial payment
i'm looking at the webhook logs, we do get terminal.reader.action_failed events, but it seems all the ones I looked at are for the payment part
didn't see any for refunds
Yeah you'd need an example of a refund failing
Like the above one
Pretty sure you'd get the event, but I'm not positive
Let me just ask a colleague
ok
I found a similar webhook:
{
"id": "evt_1Ozm2OJ93KfFVesb8MqzYuPX",
"object": "event",
"api_version": "2020-08-27;terminal_interac_refunds_beta=v1",
"created": 1711744112,
"data": {
"object": {
"id": "tmr_FI7aIgI5i019cV",
"object": "terminal.reader",
"action": {
"failure_code": "invalid_request_error",
"failure_message": "The charge to be refunded and the PaymentMethod provided for the refund must both be interac_present type.",
"refund_payment": {
"amount": 2260,
"payment_intent": "pi_3OzlexJ93KfFVesb0oYqqdc5"
},
"status": "failed",
"type": "refund_payment"
},
"device_deploy_group": "tmddg_EMn26wF75Iv3rj",
"device_sw_version": "2.20.4.0",
"device_type": "bbpos_wisepos_e",
"ip_address": "192.168.0.101",
"label": "Reader 1",
"last_seen_at": 1711744104421,
"livemode": true,
"location": "tml_FI7aIgOZfBh4G4",
"metadata": {
},
"serial_number": "WSC513212024078",
"software": null,
"status": "online"
}
},
"livemode": true,
"pending_webhooks": 1,
"request": {
"id": "req_ZOxqQT7OduAjt6",
"idempotency_key": "1711744108452WSC513212024078d8z62UOf"
},
"type": "terminal.reader.action_failed"
}
in there, it doesn't contain any information about a Refund Object. Is that expected behaviour?
usually I thought we thought we'd get a Refund object id so we can confirm if the Refund is successfull or not
Yeah a refund object won't be created if it's a validation error
Like if they present the wrong card
If they present the right card, then we attempt a refund and one will be created
https://docs.stripe.com/terminal/payments/regional?integration-country=CA#refund-an-interac-payment
A successful refund generates a terminal.reader.action_succeeded event. The reader’s action.status value changes to succeeded, and the action.refund_payment has a refund attribute under it.
A failed refund generates a terminal.reader.action_failed event. The reader’s action.status value changes to failed, and the action.failure_code and action.failure_message properties each have a detailed failure explanation under them. The action.refund_payment property won’t have a refund attribute set under it.
ok thank you