#jessa_api

1 messages · Page 1 of 1 (latest)

grim perchBOT
#

👋 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/1293266800209035276

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

shrewd abyss
#

Hello! You should be able to test Interac by using a reader assigned to a Location in test mode with a Canadian address.

indigo tide
#

oh! ok thanks, i'll try it!

shrewd abyss
#

Once you assign a reader to a location in another country it should update to the new configuration for that country and reboot, then Interac should work.

indigo tide
#

Ok, we're getting a different error now. We've switched to a canadian address for the terminal location, and set the app to collect payments in CAD. We're adding 'payment_method_types' =>['card','card_present','interac_present'] to the payment intent.

Now we're getting

card_present_currency_not_supported

The card_present source type with currency cad is not supported in US.

shrewd abyss
#

Are you using a CA Stripe test account?

indigo tide
#

nope, ha.. is that something we can change temporarily? or do i need to create a new account

shrewd abyss
#

No, you'd need to create a new account.

#

You can do that very quickly using the account switcher in the top left of the Dashboard.

#

There's an option at the bottom to create a new account.

indigo tide
#

got it, thanks

#

Something I've always wondered -- how much of the onboarding is required if we're only using the account in test mode?

shrewd abyss
#

None.

#

Test mode is fully functional immediately.

indigo tide
#

thanks

indigo tide
#

Hi -- I've finally got this working using the simulated reader with the Interac test card number 🎉

My remaining issue is this one:

Unlike Visa, Mastercard, and American Express transactions, Interac transactions are authorized and automatically captured in a single step. Make sure that your application doesn’t continue to capture the PaymentIntent. If you attempt to capture an interac_present payment, the Stripe API returns an error.

Our application does indeed capture the payment separately (it is captured in the backend after the frontend sends a request to finalize the purchase).

How can we detect that the payment method was interac and skip the capture step? Or is it best practice to always skip it if the payment intent status is succeeded ?

shrewd abyss
#

Yeah, checking the status on the Payment Intent to see if it needs to be captured (requires_capture) is usually the best approach.

indigo tide
#

ok thanks

grim perchBOT
indigo tide
#

well, until now, if the payment intent is not capturable at the step we expect it to be, we let the error happen and return it to the user.

if we change it to check for requires_capture and only do the capture if so, and we just return success if the status is succeeded, i'm concerned we might be missing some problem that happened with the purchase flow, i.e. we may create a duplicate order because somehow it was submitted twice. is there some way to check for succeeded and interac_present payment method, and return success in that case, and not change our existing flow for other cases?

jolly whale
#

Hello
Taking over from Rubeus here

Have you tested the flow end to end after making changes and validated it? If not, I'd recommend doing that first as that would help understand where the gaps are..

indigo tide
#

sorry, i don't understand the question?

i am trying to add interac_present support to a stripe terminal implementation that has been in production for several years.

Since interac payments can't be captured separately from authorization, that is a different flow than our existing implementation, so I'm trying to find out if I can detect that the payment was specifically made by interac before we skip the capture step.

#

I don't want to affect our pre-exsiting flow

jolly whale
#

Like I don't grasp the part where you say "it was submitted twice" so I'm asking you if you followed Rubeus's recommendation to check the status of the PaymentIntent before attempting to capture the payment.

indigo tide
#

Well, every application can have bugs. We rely on errors being returned at certain points to alert us to unexpected conditions. In our case, a payment intent is created and captured in 2 separate api requests to our backend. It's possible something can happen between those requests.

If a payment intent is succeeded when we expected it not to be captured yet, I don't just want to return success, I want to return an error that the payment intent was already captured.

...except in the case of interac_present -- with this payment method, the payment will be captured when it is authorized, so it's ok that it's captured already when we expect it to be requires_capture.

jolly whale
#

Let's take a step back.. When you create a PaymentIntent, you're setting payment method types to card_present and interac_present right?

When you confirm the PaymentIntent with Card Present payment method, it will move the PaymentIntent to requires_capture status. When you confirm the PaymentIntent with Interac Present payment method, it will move the PaymentIntent to succeeded status..

So you can just rely on the status of the PaymentIntent and assume that if status is succeeded then the payment method was interac. If that makes you feel uncertain, then you can look at the payment method that was used to confirm the PaymentIntent.

You can retrieve the confirmed/captured PaymentIntent on your server-side and expand payment_method property https://docs.stripe.com/api/payment_intents/object#payment_intent_object-payment_method
https://docs.stripe.com/api/expanding_objects

It should tell you what type of payment method was used

indigo tide
#

ah, thank you, that's exactly what i needed! i am concerned about a payment intent already being succeeded when we expect it to be requires_capture, simply because we haven't expected payment methods until now that don't do capture separately.

i may be able to make this flow more watertight and not write a special case for interac, but i'm in an urgent situation right now, so need to just get it done. appreciate it!