#Zappysam
lofty lodge
Can you share a request id where you saw this behavior on the client side? Want to check something
tough hollow
req_Dw78RAwDh2YU7G
lofty lodge
Ah that request is using 2019-02-19 API version
tough hollow
Do you know how/where that's set client-side?
lofty lodge
What version of the android sdk are you using?
tough hollow
You mean on the deivces? We just have a bunch of WisePOS E and Verifone P400 (and a handful of M2s) sent directly from Stripe, and then we only use the js librairies and the .NET package
lofty lodge
Oh gotcha gotcha
Are you seeing this issue on both device types?
Or just one of the device types?
tough hollow
Seeing the issue for all BB and P400 devices, which are seemingly making "old" api version requests. For the M2 implementation, we retrieve the payment intent server-side, which is using the "new" api version. I'm looking to consolidate it so that all devices get the payment intent server-side but still trying to understand the issue because I don't want it to all of a sudden change and all client-side payment intent requests start failing!
lofty lodge
Gotcha. Let me check with a colleague
tough hollow
Thank you!!
lofty lodge
Will get back to you
tough hollow
Really appreciate it
lofty lodge
Hm my colleague took a look at that request and it appears that it's using the Terminal Android SDK. Can you describe more about how exactly your integration is working (the entire flow)?
tough hollow
As far as the devices go, we just order them directly from you guys.
For the implementation, we use a combination of client-side and server-side requests. Client-side we use the https://js.stripe.com/terminal/v1/ script for the reader js. Server-side, we use Stripe.net 41.13.0.
For the BBPOS and P400 devices, we follow this documentation: https://stripe.com/docs/terminal/payments/collect-payment?terminal-sdk-platform=js
Creating the payment intent server-side, then collecting the payment client-side using the token that the server returns. We then capture the payment server-side.
Please let me know if you need any more details!
orchid socketBOT
lofty lodge
Hm the request you shared was made with the android sdk. Do you recognize the ip address at the top here? https://dashboard.stripe.com/test/logs/iar_Dw78RAwDh2YU7G
Is that you?
tough hollow
Hmmm - when I navigate to the payment intent it says no such payment intent, so I'm not sure what that is
I'll look for a different request
And you guys don't have your own Android SDK implementation on the devices themselves that we're not in control of?
dim dagger
Hi 👋
I'm stepping in as @lofty lodge needs to head out soon
tough hollow
Sounds good!
dim dagger
For the devices you are using we do not have our own Android SDK directly on them
Our terminal Android SDK would be used on a separate device that would communicate with the actual terminal readers
tough hollow
I'm still looking for requests but the dashboard keeps crashing when I navigate to a payment intent
Here's another request: req_PcAZo39f8jkjrp
It also says "client_type":"ANDROID_SDK" though - I know for a fact that this client is using a BBPOS device which is following the flow I outlined above
dim dagger
Yes unfortunately there is an issue ongoing right now that is degrading the dashboard. We are actively working on it
tough hollow
Here is another request id: req_Ubrs5j5MUFy4gJ
This one says "client_type":"RACCOON"
dim dagger
Okay I'm looking at this one. What is the reader being used here?
tough hollow
This client is using a combination of P400s and BBPOS devices - I'll see if I can narrow it down
The implementation is the same for both though
I can't guarantee it since we don't track it exactly, but based on the data I see on our side I can infer that it's a P400
dim dagger
Well the M2 readers don't work with a JavaScript integration
iOS, Android, or React Native only
tough hollow
That makes sense as to why our implementation is different then! The M2s are working fine as the payment intent request that we're using to retrieve the charge data is server-side and using the expected API version - we have an iOS app to interact with them. We do not have an Android app though
I'm really just trying to understand why our client-side requests for the P400 and BBPOS implementations are using the old API version, getting the charges property and not latest_charge, and how that can be controlled
dim dagger
Gotcha. Okay do you have a request that you know is using the Wise POS E?
tough hollow
Here is one that I am certain uses the Wise POS E: req_cShmFaYhjI6x4z
dim dagger
Great, thanks!
tough hollow
Thank you!
So far, every single request that I've found for various connected accounts using only Wise POS E devices say client_type:"ANDROID_SDK"
dim dagger
Yes I noticed that
Okay so both the Connected Account and Platform have more updated default API versions... 🤔
I think you would need to have a look at the code that is making this API call. I would suspect some API version pinning may be going on here.
tough hollow
The payment intent is in the result of the collectPaymentMethod call outlined here: https://stripe.com/docs/terminal/payments/collect-payment?terminal-sdk-platform=js#collect-payment
Is there a way to pass in the version as an option?
Wait, what you just said....
Our platform version was changed to 2022-11-15, but every connected account is still on 2020-08-27
So every connected account needs to be upgraded manually, and separately from the platform version?
dim dagger
No, and that's not the case.
The Custom Account associated with that request is on 2022-08-01
acct_1LvRIABCOvC7WloO
tough hollow
Right, sorry, this one is 2022-08-10
Ok, so connected accounts stay at the version that they were originally set up as? So new accounts will take on the platform default of 2022-11-15? I think that this all makes sense now if it's controlled by connected account
dim dagger
Okay but that is still not explaining why we are seeing a 2019-02-19 API version on the /confirm request is it?
tough hollow
I sent requests from various connected accounts - perhaps the one where we saw 2019-02-19 has that as the default? I have to look back now
You're right, that doesn't match
dim dagger
Which I why I 'm wondering if the JS integration has the API version pinned somewhere: https://stripe.com/docs/js/initializing#init_stripe_js-options-apiVersion
tough hollow
That is per request? We definitely don't specify an apiVersion anywhere
dim dagger
Not necessarily per request.
tough hollow
Like you think somehow it got cached somewhere?
dim dagger
No, I meant that when Stripe.js gets loaded in your POS
e.g.
stripe = Stripe('pk_XXXX', {apiVersion: '2019-02-19'})
Something like that in the JS somewhere
tough hollow
I just triple checked and we don't do that anywhere, except in a completely separate application for web sales where we use Payment Request Button and we do:
const stripe = Stripe(publicKey, {
apiVersion: '2022-11-15',
stripeAccount: stripeAccountId,
});
dim dagger
Okay this is really quite odd. I think we will need to do some deeper digging on why this is occurring. Could you send an email to our Support team https://support.stripe.com/?contact=true, mention my screen name and include the request ID as well as other details about the convo? That way I can grab the ticket and review it more thoroughly.
tough hollow
Sounds good, I'll write that up shortly. Thanks for your help!
dim dagger
Happy to do it! I hope we can track this down soon
orchid socketBOT
tough hollow
@dim dagger I sent the email to support@stripe.com, mentioning your handle!
dim dagger
Cool let me check
tough hollow
Oh I got an automatic response saying that email isn't actively monitored
dim dagger
How did you create the email?
tough hollow
I just used one that I had on file. I'll re-submit using the form
dim dagger
Okay yeah that'll get the message where it needs to go
tough hollow
Ok, sent again
dim dagger
Okay I've got it. I'll start trying to track this down
tough hollow
Awesome, thank you!
dim dagger
Happy to help 🙂
boreal plover
While you're here - are you 100% sure you're not using the Android SDK? Looking at your recent requests you create Connection Tokens, which you'd only do if you were using our android or ios sdks
tough hollow
The connection token requests are to support the M2 device, which we only support through iOS. This is a different implementation though
We definitely have no Android code of our own
boreal plover
That's definitely odd, because the request you sent is definitely not being confirmed through the JS terminal library
tough hollow
You're talking about req_cShmFaYhjI6x4z ?
boreal plover
yup
tough hollow
Is it collectPaymentMethod or processPayment that calls confirm through the js library? Can I debug and see the client_type being passed in?
boreal plover
It would be processPayment
If you do a one-off test now that you're sure is going through the JS library I can take a look at that after you send over a request ID or PI ID
tough hollow
An example of a confirm using our M2 iOS implementation would be this: req_JyZ829Y7M2CfZK
boreal plover
Do you have one from your JS library?
tough hollow
All the other ones are coming from the JS library - I can provide many more from different production accounts!
Did you look at this one? req_Ubrs5j5MUFy4gJ
This one came from a P400 instead of a Wise POS
boreal plover
okay awesome - that does definitely seem to be coming from the JS library
It's still a mystery why req_cShmFaYhjI6x4z is coming from the Android SDK if you have no Android code at all
But at least we do see that your other calls using JS + iOS look right
tough hollow
Ok, sweet! Seems like a secondary issue here then to figure out.
I can also find Interac requests using the Wise POS E and JS
req_sLlOvehvfECgSH and req_KUR8J85CtL9klL
boreal plover
That's okay, we shouldn't need the Interac requests
tough hollow
Sounds good
boreal plover
Sorry we got sidetracked for a bit there - it was just very confusing to be talking about the JS library while looking at a request that definitely comes from the Android SDK
The main issue is still the API version being pinned, right?
tough hollow
I asked Snufkin this earlier, but there's no way your devices that we order and integrate with use the Android SDK, thus reporting it that way?
Yes, that's correct
boreal plover
I had thought it would be impossible for that to happen it to be reported as coming from the Android SDK (but that may be better to follow up through the email)
For the pinning - I'm fairly sure that's expected with all our terminal integrations. We pin those calls internally to version 2019-02-19 and there's not way to modify it on your end
tough hollow
So then requests and responses are just hard-coded with that version? In my case, the charges object will always exist and latest_charge won't?
boreal plover
Yes, responses from the terminal sdk should always be returning charges and not latest_charge
tough hollow
Ok, so the Platform and Connected account default API Versions don't change that? Can you link me to documentation that explains what the Platform and Connected Account API Versions change other than webhook?
boreal plover
I think this is probably the best resource we have for that: https://stripe.com/docs/upgrades#how-can-i-upgrade-my-api
tough hollow
Got it!
Ok, so to recap, the JS Terminal requests are hard-coded to a certain API Version, and that can't be changed, but that's not specifically documented, correct?
boreal plover
correct!
tough hollow
Sounds good, thank you very much for all your time and help!
boreal plover
👍