I’m testing Interac refunds with the Terminal API in Sandbox. I completed a CAD checkout using the documented Interac test device. GetPayment shows a completed CARD payment with card_brand INTERAC and entry_method EMV.
The part I’m stuck on: card_details.refund_requires_card_presence isn’t in the payment response. I’ve checked GetPayment and ListPayments through the SDK, then made a direct GetPayment request using Square API version 2026-09-16. The field is absent in all three.
The Interac refund guide says this field should be true before creating a Terminal refund, so I haven’t tried to refund the payment yet. Is this field expected to be present for Sandbox Interac payments? If Sandbox doesn’t return it, how should we test the Terminal refund flow, including cancellation, timeout, and offline cases?
I can share the payment and application IDs privately if they would help investigate. Thanks!
Could you check inside card_details of the GetPayment response? I.e. paymentResponse.card_details.refund_requires_card_presence
If it is still not there, we were having some issues in the sandbox environment yesterday. Could you try your process again and see if there is still an issue?
Hi @zacstlouis, thanks for the reply. We checked the exact field inside card_details and retried the process after the Sandbox incident.
The separate Sandbox refund-processing issue appears resolved for new requests: fresh ordinary refunds now transition from PENDING to COMPLETED . Some older refunds created during the incident remain stuck in PENDING, but the Interac issue still reproduces.
Using Square API version 2026-09-16, we created multiple fresh CA$5.65 checkouts with the documented Interac Sandbox checkout device 388b5a08-a77c-48ef-ad2a-4a790e6f2789.
Each resulting Payment reported:
status = COMPLETED
card_details.entry_method = EMV
card_details.card.card_brand = INTERAC
card_details.refund_requires_card_presence was absent from the raw GetPayment JSON—not false or null
We then compared both refund paths using separate, otherwise matching Interac Payments:
The ordinary Refunds API returned HTTP 200. Its PaymentRefund transitioned from PENDING to COMPLETED in about three seconds and had no terminal_refund_id.
CreateTerminalRefund, using the documented successful Interac refund device f72dfb8e-4d65-4e56-aade-ec3fb8d33291, returned HTTP 400 BAD_REQUEST:
Payment does not support card present refunds. Use the Refunds API to refund this payment.
No TerminalRefund object was created.
This suggests the documented Sandbox Interac checkout is producing Payments branded as INTERAC, but the refund backend is classifying them as ordinary-refund eligible rather than card-present-refund eligible. So the issue appears to be more than the Boolean simply being omitted from serialization.
Could you confirm whether the documented Interac checkout device is expected to produce a Payment with refund_requires_card_presence = true that is accepted by CreateTerminalRefund? If not, what is the current supported Sandbox path for testing successful, buyer-canceled, timed-out, and offline Terminal Interac refunds?
We can provide the exact checkout, Payment, ordinary-refund, and timestamp details privately if they would help your team investigate.
Ok, this could be a sandbox issue that needs escalation. In order to escalate, could you send me (can also DM) the checkout id, payment id, refund id, and the application id along with a timestamp?
Hi @zacstlouis, thanks for the reply. Here are the requested details. These are all Sandbox test objects.
Application ID:sandbox-sq0idb-yEjhjUVooNa_mfQ_s_AQFA Square API version:2026-09-16 Amount: CA$5.65 per payment Interac checkout test device:388b5a08-a77c-48ef-ad2a-4a790e6f2789
Recorded diagnostic checkpoints: approximately September 26 at 00:24 UTC for the checkout/field check and 00:32 UTC for the refund comparison. These are checkpoint times, not exact request timestamps.
CreateTerminalRefund returned HTTP 400 BAD_REQUEST:
Payment does not support card present refunds. Use the Refunds API to refund this payment.
Both payments reported COMPLETED, CAD, CARD/INTERAC, and EMV, but the raw GetPayment responses omitted card_details.refund_requires_card_presence.
Also, I couldn’t find a way to DM you. Your profile card showed no Message option, and I couldn’t find private messaging in my account menu. Could you initiate a DM, or suggest another private support channel where we can communicate?
The team is looking into it, but it looks like it is a long-standing sandbox issue. If I get an update I will let you know!
To unblock you I would recommend using the Refund API as you did and not rely on the terminal in Sandbox, or move your testing to production. You can create a free production account to test in and if you process CASH tendered payments you will not be charged.
Hi @zacstlouis, thanks for looking into this and escalating it to the team. Please keep me posted if there are any developments on the Sandbox Interac refund issue. Thanks again!